From Markus.Gramer at kuleuven.be Mon Aug 3 14:19:15 2015 From: Markus.Gramer at kuleuven.be (Markus Gramer) Date: Mon, 3 Aug 2015 12:19:15 +0000 Subject: [Neuroimaging] Change sform and save Message-ID: Hi there, I am new to nibabel (and also python) so maybe I am making an obvious mistake, but I could not find anything in the manual that would help me? I am trying to update the sform in a Nifty1 image and save it with: def update_sform(file_in, file_out, affine_out): img = nib.load(file_in) img_hdr = img.header img_hdr.set_sform(affine_out) nib.save(img,file_out) However, I realised that due to the comparison between current header and affine: np.allclose(self._affine, hdr.get_best_affine()) [spatialimages.py, line 426] The sform in the header is reset to the affine when I am saving the image. Is there a way to directly set the affine? Or any other method that I can use to achieve this? Thanks in advance, Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Aug 3 14:30:30 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Aug 2015 13:30:30 +0100 Subject: [Neuroimaging] Change sform and save In-Reply-To: References: Message-ID: Hi, On Mon, Aug 3, 2015 at 1:19 PM, Markus Gramer wrote: > Hi there, > > I am new to nibabel (and also python) so maybe I am making an obvious > mistake, but I could not find anything in the manual that would help me? > > I am trying to update the sform in a Nifty1 image and save it with: > > def update_sform(file_in, file_out, affine_out): > > img = nib.load(file_in) > > img_hdr = img.header > > img_hdr.set_sform(affine_out) > > nib.save(img,file_out) > > > However, I realised that due to the comparison between current header and > affine: > > > np.allclose(self._affine, hdr.get_best_affine()) [spatialimages.py, line > 426] > > > The sform in the header is reset to the affine when I am saving the image. > Is there a way to directly set the affine? Or any other method that I can > use to achieve this? Sorry - it should be better documented, but I think you want: img.set_sform(affine_out) This sets the affine for the image as well as the sform, Cheers, Matthew From Markus.Gramer at kuleuven.be Mon Aug 3 14:38:45 2015 From: Markus.Gramer at kuleuven.be (Markus Gramer) Date: Mon, 3 Aug 2015 12:38:45 +0000 Subject: [Neuroimaging] Change sform and save In-Reply-To: References: Message-ID: Thanks, for the fast reply! This indeed solves my issue! Cheers, Markus On 03/08/15 14:30, "Neuroimaging on behalf of Matthew Brett" wrote: >Hi, > >On Mon, Aug 3, 2015 at 1:19 PM, Markus Gramer >wrote: >> Hi there, >> >> I am new to nibabel (and also python) so maybe I am making an obvious >> mistake, but I could not find anything in the manual that would help me? >> >> I am trying to update the sform in a Nifty1 image and save it with: >> >> def update_sform(file_in, file_out, affine_out): >> >> img = nib.load(file_in) >> >> img_hdr = img.header >> >> img_hdr.set_sform(affine_out) >> >> nib.save(img,file_out) >> >> >> However, I realised that due to the comparison between current header >>and >> affine: >> >> >> np.allclose(self._affine, hdr.get_best_affine()) [spatialimages.py, line >> 426] >> >> >> The sform in the header is reset to the affine when I am saving the >>image. >> Is there a way to directly set the affine? Or any other method that I >>can >> use to achieve this? > >Sorry - it should be better documented, but I think you want: > >img.set_sform(affine_out) > >This sets the affine for the image as well as the sform, > >Cheers, > >Matthew >_______________________________________________ >Neuroimaging mailing list >Neuroimaging at python.org >https://mail.python.org/mailman/listinfo/neuroimaging From arokem at gmail.com Mon Aug 3 15:11:20 2015 From: arokem at gmail.com (Ariel Rokem) Date: Mon, 3 Aug 2015 06:11:20 -0700 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150725084155.GB87662@phare.normalesup.org> <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> Message-ID: On Wed, Jul 29, 2015 at 8:38 PM, David Moreno-Dominguez wrote: > Doesnt Dipy already do this? (be open source and compute FA images > [and much more] from any dwi dataset) Absolutely - I was being ironic. But I will admit that irony doesn't travel well by email. > On Wed, Jul 29, 2015 at 8:06 PM, Ariel Rokem wrote: > > > > On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux > > wrote: > >> > >> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem wrote: > >> > PS: Vanessa: Nilearn is not only for fMRI. It's for statistical > >> > analysis > >> > of images. It is also used for anatomical images: > >> > > http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html > >> > If we could get a preprocessed, openly downloadable set of images > of > >> > eg > >> > FA, we would do an example with diffusion too. > >> > >> > Completely off-topic, but I can't resist: if only there was an > >> > open-source project that computed FA images from freely available > >> > diffusion MRI data-sets! > >> > >> Well, you're welcome to help us with preprocessing and pitching a > >> relevant prediction problem from this data. I know nothing about > >> diffusion and nothing about the datasets you are talking about. In my > >> experience, writing a relevant example requires understanding the data > >> and the questions. If you, or someone else, gets us to the point where > >> there is a set of nifti images of FA with condition A and condition B, > >> and helps us write the story, than we have an example. > > > > > > Hmm. Interesting idea. I am looking around for something along these > lines. > > I think that there are some freely available data-sets that are already > > preprocessed, so could be used in this way. Let me think about how to go > > about this. > > > >> > >> Ga?l > >> _______________________________________________ > >> Neuroimaging mailing list > >> Neuroimaging at python.org > >> https://mail.python.org/mailman/listinfo/neuroimaging > > > > > > > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 3 15:33:06 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Mon, 3 Aug 2015 06:33:06 -0700 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150725084155.GB87662@phare.normalesup.org> <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> Message-ID: This week we should perhaps vote/decide on a final framework to port the nipy site into? I'm open to giving a go at whatever the group thinks is best :) On Mon, Aug 3, 2015 at 6:11 AM, Ariel Rokem wrote: > > On Wed, Jul 29, 2015 at 8:38 PM, David Moreno-Dominguez < > d.mor.dom at gmail.com> wrote: > >> Doesnt Dipy already do this? (be open source and compute FA images >> [and much more] from any dwi dataset) > > > Absolutely - I was being ironic. > > But I will admit that irony doesn't travel well by email. > > >> On Wed, Jul 29, 2015 at 8:06 PM, Ariel Rokem wrote: >> > >> > On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux >> > wrote: >> >> >> >> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem wrote: >> >> > PS: Vanessa: Nilearn is not only for fMRI. It's for statistical >> >> > analysis >> >> > of images. It is also used for anatomical images: >> >> > >> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html >> >> > If we could get a preprocessed, openly downloadable set of >> images of >> >> > eg >> >> > FA, we would do an example with diffusion too. >> >> >> >> > Completely off-topic, but I can't resist: if only there was an >> >> > open-source project that computed FA images from freely available >> >> > diffusion MRI data-sets! >> >> >> >> Well, you're welcome to help us with preprocessing and pitching a >> >> relevant prediction problem from this data. I know nothing about >> >> diffusion and nothing about the datasets you are talking about. In my >> >> experience, writing a relevant example requires understanding the data >> >> and the questions. If you, or someone else, gets us to the point where >> >> there is a set of nifti images of FA with condition A and condition B, >> >> and helps us write the story, than we have an example. >> > >> > >> > Hmm. Interesting idea. I am looking around for something along these >> lines. >> > I think that there are some freely available data-sets that are already >> > preprocessed, so could be used in this way. Let me think about how to go >> > about this. >> > >> >> >> >> Ga?l >> >> _______________________________________________ >> >> Neuroimaging mailing list >> >> Neuroimaging at python.org >> >> https://mail.python.org/mailman/listinfo/neuroimaging >> > >> > >> > >> > _______________________________________________ >> > Neuroimaging mailing list >> > Neuroimaging at python.org >> > https://mail.python.org/mailman/listinfo/neuroimaging >> > >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 3 15:38:05 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Mon, 3 Aug 2015 06:38:05 -0700 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150725084155.GB87662@phare.normalesup.org> <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> Message-ID: My .02 on flask: The extra step is "freezing." The workflow to push an update will always be something along the lines of: - checkout or clone current flask site - do changes - freeze - push to gh-pages This seems do-able to me, but I sense that others aren't happy about the extra step, and I am open to the idea that other frameworks could do it better, perhaps at the cost of the more "interactive" back end allowed by flask. At the end of the day, it doesn't really matter so much as long as updating / adding content is relatively straight forward and pain free. Looking forward to more discussion on this. On Mon, Aug 3, 2015 at 6:33 AM, vanessa sochat wrote: > This week we should perhaps vote/decide on a final framework to port the > nipy site into? I'm open to giving a go at whatever the group thinks is > best :) > > On Mon, Aug 3, 2015 at 6:11 AM, Ariel Rokem wrote: > >> >> On Wed, Jul 29, 2015 at 8:38 PM, David Moreno-Dominguez < >> d.mor.dom at gmail.com> wrote: >> >>> Doesnt Dipy already do this? (be open source and compute FA images >>> [and much more] from any dwi dataset) >> >> >> Absolutely - I was being ironic. >> >> But I will admit that irony doesn't travel well by email. >> >> >>> On Wed, Jul 29, 2015 at 8:06 PM, Ariel Rokem wrote: >>> > >>> > On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux >>> > wrote: >>> >> >>> >> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem wrote: >>> >> > PS: Vanessa: Nilearn is not only for fMRI. It's for statistical >>> >> > analysis >>> >> > of images. It is also used for anatomical images: >>> >> > >>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html >>> >> > If we could get a preprocessed, openly downloadable set of >>> images of >>> >> > eg >>> >> > FA, we would do an example with diffusion too. >>> >> >>> >> > Completely off-topic, but I can't resist: if only there was an >>> >> > open-source project that computed FA images from freely available >>> >> > diffusion MRI data-sets! >>> >> >>> >> Well, you're welcome to help us with preprocessing and pitching a >>> >> relevant prediction problem from this data. I know nothing about >>> >> diffusion and nothing about the datasets you are talking about. In my >>> >> experience, writing a relevant example requires understanding the data >>> >> and the questions. If you, or someone else, gets us to the point where >>> >> there is a set of nifti images of FA with condition A and condition B, >>> >> and helps us write the story, than we have an example. >>> > >>> > >>> > Hmm. Interesting idea. I am looking around for something along these >>> lines. >>> > I think that there are some freely available data-sets that are already >>> > preprocessed, so could be used in this way. Let me think about how to >>> go >>> > about this. >>> > >>> >> >>> >> Ga?l >>> >> _______________________________________________ >>> >> Neuroimaging mailing list >>> >> Neuroimaging at python.org >>> >> https://mail.python.org/mailman/listinfo/neuroimaging >>> > >>> > >>> > >>> > _______________________________________________ >>> > Neuroimaging mailing list >>> > Neuroimaging at python.org >>> > https://mail.python.org/mailman/listinfo/neuroimaging >>> > >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 3 15:46:58 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Mon, 3 Aug 2015 06:46:58 -0700 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150725084155.GB87662@phare.normalesup.org> <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> Message-ID: If people are as unsure about flask as I am some of the other frameworks, I would suggest that I can write out some proper documentation, and then others can give the workflow a try? I can first figure out how to integrate CircleCI so we could have automatic preview of PRs. Let me know your thoughts. On Mon, Aug 3, 2015 at 6:38 AM, vanessa sochat wrote: > My .02 on flask: > > The extra step is "freezing." The workflow to push an update will always > be something along the lines of: > > - checkout or clone current flask site > - do changes > - freeze > - push to gh-pages > > This seems do-able to me, but I sense that others aren't happy about the > extra step, and I am open to the idea that other frameworks could do it > better, perhaps at the cost of the more "interactive" back end allowed by > flask. At the end of the day, it doesn't really matter so much as long as > updating / adding content is relatively straight forward and pain free. > Looking forward to more discussion on this. > > On Mon, Aug 3, 2015 at 6:33 AM, vanessa sochat > wrote: > >> This week we should perhaps vote/decide on a final framework to port the >> nipy site into? I'm open to giving a go at whatever the group thinks is >> best :) >> >> On Mon, Aug 3, 2015 at 6:11 AM, Ariel Rokem wrote: >> >>> >>> On Wed, Jul 29, 2015 at 8:38 PM, David Moreno-Dominguez < >>> d.mor.dom at gmail.com> wrote: >>> >>>> Doesnt Dipy already do this? (be open source and compute FA images >>>> [and much more] from any dwi dataset) >>> >>> >>> Absolutely - I was being ironic. >>> >>> But I will admit that irony doesn't travel well by email. >>> >>> >>>> On Wed, Jul 29, 2015 at 8:06 PM, Ariel Rokem wrote: >>>> > >>>> > On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux >>>> > wrote: >>>> >> >>>> >> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem wrote: >>>> >> > PS: Vanessa: Nilearn is not only for fMRI. It's for statistical >>>> >> > analysis >>>> >> > of images. It is also used for anatomical images: >>>> >> > >>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html >>>> >> > If we could get a preprocessed, openly downloadable set of >>>> images of >>>> >> > eg >>>> >> > FA, we would do an example with diffusion too. >>>> >> >>>> >> > Completely off-topic, but I can't resist: if only there was an >>>> >> > open-source project that computed FA images from freely available >>>> >> > diffusion MRI data-sets! >>>> >> >>>> >> Well, you're welcome to help us with preprocessing and pitching a >>>> >> relevant prediction problem from this data. I know nothing about >>>> >> diffusion and nothing about the datasets you are talking about. In my >>>> >> experience, writing a relevant example requires understanding the >>>> data >>>> >> and the questions. If you, or someone else, gets us to the point >>>> where >>>> >> there is a set of nifti images of FA with condition A and condition >>>> B, >>>> >> and helps us write the story, than we have an example. >>>> > >>>> > >>>> > Hmm. Interesting idea. I am looking around for something along these >>>> lines. >>>> > I think that there are some freely available data-sets that are >>>> already >>>> > preprocessed, so could be used in this way. Let me think about how to >>>> go >>>> > about this. >>>> > >>>> >> >>>> >> Ga?l >>>> >> _______________________________________________ >>>> >> Neuroimaging mailing list >>>> >> Neuroimaging at python.org >>>> >> https://mail.python.org/mailman/listinfo/neuroimaging >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Neuroimaging mailing list >>>> > Neuroimaging at python.org >>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>> > >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Aug 3 15:56:47 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Aug 2015 14:56:47 +0100 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: Message-ID: Hi, On Fri, Jul 31, 2015 at 6:57 PM, Matthew Brett wrote: > Hi Omar, > > On Fri, Jul 31, 2015 at 6:29 PM, Jesus-Omar Ocegueda-Gonzalez > wrote: >> Hello Python experts!, >> I just wanted to ask if anyone of you could point me out to a good reference >> to learn a good way to manage different python versions and their >> corresponding packages. This is a bit embarrassing, but I guess the >> following story may seem familiar to some people (probably those days when >> you were python newbies): I had python 2.7 with a lot of packages already >> installed, some of them installed with pip, some with easy_install, some >> with apt-get, some built manually from source code... who knows? I just >> sequentially tried each installation way, following instructions I found in >> random internet pages whenever something went wrong, until one of the >> installation instructions suddenly worked, and just moved on. Then, at some >> point, I tried to install Python 3 to reproduce a bug reported to only >> happen there, just to discover that now nothing works, I have no numpy, no >> nibabel, none of the basic packages, so I tried to "re-install" them >> (following instructions from random internet pages when something goes >> wrong... again), see the pattern?. So the root cause is obviously that I >> have no idea of what's going on behind scenes when I use these "mysterious" >> installers, and how they affect my environment, which of them are compatible >> with each other and which are not, etc. >> >> So, to break the pattern, I think this is time to really learn exactly >> what's going on when we "install" packages with different tools, and how to >> correctly manage different versions. Could anyone point me out to a good >> reference to learn these details (e.g. Is there a good way to actually >> remove everything so we can start a totally fresh installation)? >> >> Thank you very much in advance!. >> With warm regards, >> -A frustrated -but motivated- Python user. > > I'm afraid I don't know of a very good reference. > > I think your two options are: > > * start from scratch using virtualenv and pip; > * use conda > > I prefer virtualenv and pip, because want to support standard Python > packaging, and am worried about the effect of handing over Python > packaging to one company. Although conda is open-source, almost all > the work and all the hosting is done by employees of Continuum IO. > > Having said that, I have the impression that conda is a reliable > solution to the problem of having multiple different Python > environments you want to work on. > > If you want to go the virtualenv / pip route, I recommend you start > from scratch. In particular, easy_install had a very nasty trick of > putting installed packages unconditionally at the top of the Python > search path, using `easy-install.pth` files. > > If you're interested to do that, let me know, I'll write up a summary > of what to do. I guess you are on Debian / Ubuntu? Despite deafening silence, I did write up the summary: https://matthew-brett.github.io/pydagogue/installing_on_debian.html Cheers, Matthew From lists at onerussian.com Mon Aug 3 16:17:16 2015 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Aug 2015 10:17:16 -0400 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: Message-ID: <20150803141716.GL28964@onerussian.com> On Mon, 03 Aug 2015, Matthew Brett wrote: > > If you're interested to do that, let me know, I'll write up a summary > > of what to do. I guess you are on Debian / Ubuntu? > Despite deafening silence, I did write up the summary: > https://matthew-brett.github.io/pydagogue/installing_on_debian.html my 1c with the NeuroDebian/Debian developer hat on. If you are into neuroimaging, and just a researcher/user who wants to have work done, I would recommend to stick to using (Neuro)Debian-provided packages as long as they are provided from our repositories: that is the point of having a distribution like Debian, that we are taking care about compatibility between versions of various packages you use and which inter-depend among themselves. And then your python packages live coherently with the rest of the system, so you can manage python and non-python packages with the same commands. If you need more recent versions of neuroimaging (and related) python packages -- that is where NeuroDebian repository comes in. If interested to try -- there is a virtualbox VM, and docker images available. And only then, when I hit the situation that some package is not yet available from (Neuro)Debian, I usually create a virtualenv which complements system-wide collection (virtualenv --system-site-packages) and use its pip to install additional packages ideally by specifying them within requirements.txt (pip install -r requirements.txt) so I could later reproduce the same virtualenv. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From matthew.brett at gmail.com Mon Aug 3 17:31:07 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Aug 2015 16:31:07 +0100 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: <20150803141716.GL28964@onerussian.com> References: <20150803141716.GL28964@onerussian.com> Message-ID: Yo, On Mon, Aug 3, 2015 at 3:17 PM, Yaroslav Halchenko wrote: > > On Mon, 03 Aug 2015, Matthew Brett wrote: > >> > If you're interested to do that, let me know, I'll write up a summary >> > of what to do. I guess you are on Debian / Ubuntu? > >> Despite deafening silence, I did write up the summary: > >> https://matthew-brett.github.io/pydagogue/installing_on_debian.html > > my 1c with the NeuroDebian/Debian developer hat on. > > If you are into neuroimaging, and just a researcher/user who wants to > have work done, I would recommend to stick to using > (Neuro)Debian-provided packages as long as they are provided from our > repositories: that is the point of having a distribution like Debian, > that we are taking care about compatibility between versions of > various packages you use and which inter-depend among themselves. > And then your python packages live coherently with the rest of the > system, so you can manage python and non-python packages with the same > commands. If you need more recent versions of neuroimaging (and > related) python packages -- that is where NeuroDebian repository comes > in. If interested to try -- there is a virtualbox VM, and docker images > available. > > And only then, when I hit the situation that some package is not yet > available from (Neuro)Debian, I usually create a virtualenv which > complements system-wide collection (virtualenv --system-site-packages) > and use its pip to install additional packages ideally by specifying > them within requirements.txt (pip install -r requirements.txt) so I > could later reproduce the same virtualenv. As a matter of interest - how do you set up fresh environments to test in? One of the big advantages of virtualenv for this is you can test a fresh install with no packages other than the stock pip / setuptools. You can also easily junk a set of installs with: rmvirtualenv my-env How do you do that? See you, Matthew From lists at onerussian.com Mon Aug 3 17:49:01 2015 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Aug 2015 11:49:01 -0400 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: <20150803141716.GL28964@onerussian.com> Message-ID: <20150803154901.GN28964@onerussian.com> On Mon, 03 Aug 2015, Matthew Brett wrote: > > And only then, when I hit the situation that some package is not yet > > available from (Neuro)Debian, I usually create a virtualenv which > > complements system-wide collection (virtualenv --system-site-packages) > > and use its pip to install additional packages ideally by specifying > > them within requirements.txt (pip install -r requirements.txt) so I > > could later reproduce the same virtualenv. > As a matter of interest - how do you set up fresh environments to test in? it depends what I am testing. If I am testing Debian package of a module, tests are ran as part of the build process, and that one happens in a clean environment which is created usually as a chroot'ed environment with only build-depends installed (as specified in debian/control). No virtualenv involved. I also have a set of chroots available locally so I could quickly switch to any given release of debian/ubuntu using schroot. then for 'semi-clean/mixed' environments I just use virtualenv (as described, i.e. with some packages coming from the system installation again), and now started to use tox more, which again preinstalls me those virtualenv's > One of the big advantages of virtualenv for this is you can test a > fresh install with no packages other than the stock pip / setuptools. yes -- for fresh packages, use virtualenv/tox. again as overlay on top of system wide installed ones. Why mixing up with system-wide -- because I want to test as when eventually this package would get provided on a debian system, so with those other packages as available from the repository, not what at this given day available from pypi. > You can also easily junk a set of installs with: > rmvirtualenv my-env > How do you do that? not sure on specifics of this question -- "rm -rf my-env"? ;) My virtualenvs aren't usually long-lived. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From matthew.brett at gmail.com Mon Aug 3 17:52:33 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Aug 2015 16:52:33 +0100 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: <20150803154901.GN28964@onerussian.com> References: <20150803141716.GL28964@onerussian.com> <20150803154901.GN28964@onerussian.com> Message-ID: On Mon, Aug 3, 2015 at 4:49 PM, Yaroslav Halchenko wrote: > > On Mon, 03 Aug 2015, Matthew Brett wrote: > >> > And only then, when I hit the situation that some package is not yet >> > available from (Neuro)Debian, I usually create a virtualenv which >> > complements system-wide collection (virtualenv --system-site-packages) >> > and use its pip to install additional packages ideally by specifying >> > them within requirements.txt (pip install -r requirements.txt) so I >> > could later reproduce the same virtualenv. > >> As a matter of interest - how do you set up fresh environments to test in? > > it depends what I am testing. If I am testing Debian package of a > module, tests are ran as part of the build process, and that one happens > in a clean environment which is created usually as a chroot'ed > environment with only build-depends installed (as specified in > debian/control). No virtualenv involved. > > I also have a set of chroots available locally so I could quickly switch > to any given release of debian/ubuntu using schroot. > > then for 'semi-clean/mixed' environments I just use virtualenv (as > described, i.e. with some packages coming from the system installation > again), and now started to use tox more, which again preinstalls > me those virtualenv's > >> One of the big advantages of virtualenv for this is you can test a >> fresh install with no packages other than the stock pip / setuptools. > > yes -- for fresh packages, use virtualenv/tox. > again as overlay on top of system wide installed ones. > > Why mixing up with system-wide -- because I want to test as when > eventually this package would get provided on a debian system, so with > those other packages as available from the repository, not what at this > given day available from pypi. > >> You can also easily junk a set of installs with: > >> rmvirtualenv my-env > >> How do you do that? > > not sure on specifics of this question -- "rm -rf my-env"? ;) My > virtualenvs aren't usually long-lived. Sorry - I only meant that - if I do say apt-get install python-vtk - then I will get that package and all the relevant dependencies, as decided by the packager. Then I will get those packages in all my virtualenvs with ``--system-site-packages``, past and present, which might change their behavior. So I can't easily do evanescent installs of these packages, as I can with the wheels / virtualenvs approach. See you, Matthew From jbpoline at gmail.com Mon Aug 3 18:49:42 2015 From: jbpoline at gmail.com (JB Poline) Date: Mon, 3 Aug 2015 09:49:42 -0700 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: Message-ID: That's a very useful page to me - A quick possible addition : why / when use the --user option ? (and get packages in .local/... ) I also wonder if examples of trouble shooting or install that raised difficulties could be added there in a "use cases" section : by reading how some issues where solved I'm sure I could learn a bit more how to debug install that go wrong. cheers JB On Mon, Aug 3, 2015 at 6:56 AM, Matthew Brett wrote: > Hi, > > On Fri, Jul 31, 2015 at 6:57 PM, Matthew Brett > wrote: > > Hi Omar, > > > > On Fri, Jul 31, 2015 at 6:29 PM, Jesus-Omar Ocegueda-Gonzalez > > wrote: > >> Hello Python experts!, > >> I just wanted to ask if anyone of you could point me out to a good > reference > >> to learn a good way to manage different python versions and their > >> corresponding packages. This is a bit embarrassing, but I guess the > >> following story may seem familiar to some people (probably those days > when > >> you were python newbies): I had python 2.7 with a lot of packages > already > >> installed, some of them installed with pip, some with easy_install, some > >> with apt-get, some built manually from source code... who knows? I just > >> sequentially tried each installation way, following instructions I > found in > >> random internet pages whenever something went wrong, until one of the > >> installation instructions suddenly worked, and just moved on. Then, at > some > >> point, I tried to install Python 3 to reproduce a bug reported to only > >> happen there, just to discover that now nothing works, I have no numpy, > no > >> nibabel, none of the basic packages, so I tried to "re-install" them > >> (following instructions from random internet pages when something goes > >> wrong... again), see the pattern?. So the root cause is obviously that I > >> have no idea of what's going on behind scenes when I use these > "mysterious" > >> installers, and how they affect my environment, which of them are > compatible > >> with each other and which are not, etc. > >> > >> So, to break the pattern, I think this is time to really learn exactly > >> what's going on when we "install" packages with different tools, and > how to > >> correctly manage different versions. Could anyone point me out to a good > >> reference to learn these details (e.g. Is there a good way to actually > >> remove everything so we can start a totally fresh installation)? > >> > >> Thank you very much in advance!. > >> With warm regards, > >> -A frustrated -but motivated- Python user. > > > > I'm afraid I don't know of a very good reference. > > > > I think your two options are: > > > > * start from scratch using virtualenv and pip; > > * use conda > > > > I prefer virtualenv and pip, because want to support standard Python > > packaging, and am worried about the effect of handing over Python > > packaging to one company. Although conda is open-source, almost all > > the work and all the hosting is done by employees of Continuum IO. > > > > Having said that, I have the impression that conda is a reliable > > solution to the problem of having multiple different Python > > environments you want to work on. > > > > If you want to go the virtualenv / pip route, I recommend you start > > from scratch. In particular, easy_install had a very nasty trick of > > putting installed packages unconditionally at the top of the Python > > search path, using `easy-install.pth` files. > > > > If you're interested to do that, let me know, I'll write up a summary > > of what to do. I guess you are on Debian / Ubuntu? > > Despite deafening silence, I did write up the summary: > > https://matthew-brett.github.io/pydagogue/installing_on_debian.html > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.m.welch at gmail.com Mon Aug 3 19:04:35 2015 From: david.m.welch at gmail.com (David Welch) Date: Mon, 03 Aug 2015 12:04:35 -0500 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: Message-ID: The --user option is good for several situations: if you have several accounts on one machine and you don?t want to force everyone to use the same version of a package if you don?t have administrator permission on a machine, then you can install packages in your home account instead of in protected folders (e.g. /System/Frameworks on OS X, /usr/bin on Linux, etc.) Cheers, Dave From: Neuroimaging on behalf of JB Poline Reply-To: , Neuroimaging analysis in Python Date: Monday, August 3, 2015 at 11:49 AM To: Neuroimaging analysis in Python Subject: Re: [Neuroimaging] Technical details managing Python versions and packages. That's a very useful page to me - A quick possible addition : why / when use the --user option ? (and get packages in .local/... ) I also wonder if examples of trouble shooting or install that raised difficulties could be added there in a "use cases" section : by reading how some issues where solved I'm sure I could learn a bit more how to debug install that go wrong. cheers JB On Mon, Aug 3, 2015 at 6:56 AM, Matthew Brett wrote: Hi, On Fri, Jul 31, 2015 at 6:57 PM, Matthew Brett wrote: > Hi Omar, > > On Fri, Jul 31, 2015 at 6:29 PM, Jesus-Omar Ocegueda-Gonzalez > wrote: >> Hello Python experts!, >> I just wanted to ask if anyone of you could point me out to a good reference >> to learn a good way to manage different python versions and their >> corresponding packages. This is a bit embarrassing, but I guess the >> following story may seem familiar to some people (probably those days when >> you were python newbies): I had python 2.7 with a lot of packages already >> installed, some of them installed with pip, some with easy_install, some >> with apt-get, some built manually from source code... who knows? I just >> sequentially tried each installation way, following instructions I found in >> random internet pages whenever something went wrong, until one of the >> installation instructions suddenly worked, and just moved on. Then, at some >> point, I tried to install Python 3 to reproduce a bug reported to only >> happen there, just to discover that now nothing works, I have no numpy, no >> nibabel, none of the basic packages, so I tried to "re-install" them >> (following instructions from random internet pages when something goes >> wrong... again), see the pattern?. So the root cause is obviously that I >> have no idea of what's going on behind scenes when I use these "mysterious" >> installers, and how they affect my environment, which of them are compatible >> with each other and which are not, etc. >> >> So, to break the pattern, I think this is time to really learn exactly >> what's going on when we "install" packages with different tools, and how to >> correctly manage different versions. Could anyone point me out to a good >> reference to learn these details (e.g. Is there a good way to actually >> remove everything so we can start a totally fresh installation)? >> >> Thank you very much in advance!. >> With warm regards, >> -A frustrated -but motivated- Python user. > > I'm afraid I don't know of a very good reference. > > I think your two options are: > > * start from scratch using virtualenv and pip; > * use conda > > I prefer virtualenv and pip, because want to support standard Python > packaging, and am worried about the effect of handing over Python > packaging to one company. Although conda is open-source, almost all > the work and all the hosting is done by employees of Continuum IO. > > Having said that, I have the impression that conda is a reliable > solution to the problem of having multiple different Python > environments you want to work on. > > If you want to go the virtualenv / pip route, I recommend you start > from scratch. In particular, easy_install had a very nasty trick of > putting installed packages unconditionally at the top of the Python > search path, using `easy-install.pth` files. > > If you're interested to do that, let me know, I'll write up a summary > of what to do. I guess you are on Debian / Ubuntu? Despite deafening silence, I did write up the summary: https://matthew-brett.github.io/pydagogue/installing_on_debian.html Cheers, Matthew _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Mon Aug 3 19:14:24 2015 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 3 Aug 2015 19:14:24 +0200 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> Message-ID: <20150803171424.GH3363168@phare.normalesup.org> -1 on flask: it's twisting something that not been built for this purpose. My votes in order of preference (note that my opinion doesn't matter much, as I won't be doing the work): * sphinx: every package of the nipy constellation already uses it * pelican: I have a great experience with it (using purecss that's much lighter than bootstrap, check my personnal website out) * jekyll: seems reasonnably easy to use, but will require most people to learn a new development ecosystem * flask: great project to serve dynamic websites, but not designed for static. Gael On Mon, Aug 03, 2015 at 06:38:05AM -0700, vanessa sochat wrote: > My .02 on flask: > The extra step is "freezing." The workflow to push an update will always be > something along the lines of: > - checkout or clone current flask site > - do changes > - freeze > - push to gh-pages > This seems do-able to me, but I sense that others aren't happy about the extra > step, and I am open to the idea that other frameworks could do it better, > perhaps at the cost of the more "interactive" back end allowed by flask. At the > end of the day, it doesn't really matter so much as long as updating / adding > content is relatively straight forward and pain free. Looking forward to more > discussion on this. > On Mon, Aug 3, 2015 at 6:33 AM, vanessa sochat wrote: > This week we should perhaps vote/decide on a final framework to port the > nipy site into? I'm open to giving a go at whatever the group thinks is > best :) > On Mon, Aug 3, 2015 at 6:11 AM, Ariel Rokem wrote: > On Wed, Jul 29, 2015 at 8:38 PM, David Moreno-Dominguez < > d.mor.dom at gmail.com> wrote: > Doesnt Dipy already do this? (be open source and compute FA images > [and much more] from any dwi dataset) > Absolutely - I was being ironic.? > But I will admit that irony doesn't travel well by email.? > ? > On Wed, Jul 29, 2015 at 8:06 PM, Ariel Rokem > wrote: > > On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux > > wrote: > >> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem wrote: > >> >? ? ?PS: Vanessa: Nilearn is not only for fMRI. It's for > statistical > >> > analysis > >> >? ? ?of images. It is also used for anatomical images: > >> >? ? ?http://nilearn.github.io/auto_examples/decoding/ > plot_oasis_vbm.html > >> >? ? ?If we could get a preprocessed, openly downloadable set of > images of > >> > eg > >> >? ? ?FA, we would do an example with diffusion too. > >> > Completely off-topic, but I can't resist: if only there was an > >> > open-source project that computed FA images from freely > available > >> > diffusion MRI data-sets! > >> Well, you're welcome to help us with preprocessing and pitching > a > >> relevant prediction problem from this data. I know nothing about > >> diffusion and nothing about the datasets you are talking about. > In my > >> experience, writing a relevant example requires understanding > the data > >> and the questions. If you, or someone else, gets us to the point > where > >> there is a set of nifti images of FA with condition A and > condition B, > >> and helps us write the story, than we have an example. > > Hmm. Interesting idea. I am looking around for something along > these lines. > > I think that there are some freely available data-sets that are > already > > preprocessed, so could be used in this way. Let me think about > how to go > > about this. > >> Ga?l > >> _______________________________________________ > >> Neuroimaging mailing list > >> Neuroimaging at python.org > >> https://mail.python.org/mailman/listinfo/neuroimaging > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -- Gael Varoquaux Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.info http://twitter.com/GaelVaroquaux From francois.rousseau at telecom-bretagne.eu Mon Aug 3 19:55:53 2015 From: francois.rousseau at telecom-bretagne.eu (=?utf-8?Q?Fran=C3=A7ois_Rousseau?=) Date: Mon, 3 Aug 2015 19:55:53 +0200 Subject: [Neuroimaging] Reading Dicom files with nibabel Message-ID: <70E13D56-96CC-4EC1-97EB-74FE7BC59A37@telecom-bretagne.eu> Hi everyone, I?d like to read dicom files using nibabel but I don?t understand what is possible to do with it. In the documentation, it says at pydicom is used as a backend and that there is very limited support for DICOM. So far, I use dcm2nii to convert dicom file to nifti files, but it could nice to do this conversion in python. Is it possible using nibabel? If not, which tool do you recommend so far? pydicom? What is the roadmap of nibabel with respect to dicom files? Do you plan to improve support for DICOM or to use instead other packages? Thank you Fran?ois From lists at onerussian.com Mon Aug 3 20:40:30 2015 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Aug 2015 14:40:30 -0400 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: <20150803141716.GL28964@onerussian.com> <20150803154901.GN28964@onerussian.com> Message-ID: <20150803184030.GQ28964@onerussian.com> On Mon, 03 Aug 2015, Matthew Brett wrote: > >> You can also easily junk a set of installs with: > >> rmvirtualenv my-env > >> How do you do that? > > not sure on specifics of this question -- "rm -rf my-env"? ;) My > > virtualenvs aren't usually long-lived. > Sorry - I only meant that - if I do say apt-get install python-vtk - > then I will get that package and all the relevant dependencies, as > decided by the packager. Then I will get those packages in all my > virtualenvs with ``--system-site-packages``, past and present, which > might change their behavior. that is right! and if my package depends on that behavior, and starts to fail -- I better know that! ;) > So I can't easily do evanescent installs > of these packages, as I can with the wheels / virtualenvs approach. noone forbids you to use virtualenv without --system-site-packages if pypi-as-of-today-pristine state is what you want/need. In my case I rarely need/want a sanitarization at this level. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From krzysztof.gorgolewski at gmail.com Mon Aug 3 20:42:37 2015 From: krzysztof.gorgolewski at gmail.com (Chris Filo Gorgolewski) Date: Mon, 3 Aug 2015 11:42:37 -0700 Subject: [Neuroimaging] Reading Dicom files with nibabel In-Reply-To: <70E13D56-96CC-4EC1-97EB-74FE7BC59A37@telecom-bretagne.eu> References: <70E13D56-96CC-4EC1-97EB-74FE7BC59A37@telecom-bretagne.eu> Message-ID: Have a look at this: https://dcmstack.readthedocs.org/en/latest/ PS This would've been an excellent http://neurostars.org question... On Mon, Aug 3, 2015 at 10:55 AM, Fran?ois Rousseau < francois.rousseau at telecom-bretagne.eu> wrote: > Hi everyone, > > I?d like to read dicom files using nibabel but I don?t understand what is > possible to do with it. In the documentation, it says at pydicom is used as > a backend and that there is very limited support for DICOM. > > So far, I use dcm2nii to convert dicom file to nifti files, but it could > nice to do this conversion in python. Is it possible using nibabel? > If not, which tool do you recommend so far? pydicom? > What is the roadmap of nibabel with respect to dicom files? Do you plan to > improve support for DICOM or to use instead other packages? > > Thank you > Fran?ois > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Aug 3 21:39:49 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Aug 2015 20:39:49 +0100 Subject: [Neuroimaging] Reading Dicom files with nibabel In-Reply-To: References: <70E13D56-96CC-4EC1-97EB-74FE7BC59A37@telecom-bretagne.eu> Message-ID: Hi, On Mon, Aug 3, 2015 at 7:42 PM, Chris Filo Gorgolewski wrote: > Have a look at this: https://dcmstack.readthedocs.org/en/latest/ > > PS This would've been an excellent http://neurostars.org question... > > On Mon, Aug 3, 2015 at 10:55 AM, Fran?ois Rousseau > wrote: >> >> Hi everyone, >> >> I?d like to read dicom files using nibabel but I don?t understand what is >> possible to do with it. In the documentation, it says at pydicom is used as >> a backend and that there is very limited support for DICOM. >> >> So far, I use dcm2nii to convert dicom file to nifti files, but it could >> nice to do this conversion in python. Is it possible using nibabel? >> If not, which tool do you recommend so far? pydicom? >> What is the roadmap of nibabel with respect to dicom files? Do you plan to >> improve support for DICOM or to use instead other packages? Chris is right - dcmstack is the current best answer. To expand a bit - we plan to integrate dcmstack and nibabel at some point, but progress is slow, that is mainly my fault. Cheers, Matthew From matthew.brett at gmail.com Mon Aug 3 21:47:11 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Aug 2015 20:47:11 +0100 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: <20150803184030.GQ28964@onerussian.com> References: <20150803141716.GL28964@onerussian.com> <20150803154901.GN28964@onerussian.com> <20150803184030.GQ28964@onerussian.com> Message-ID: On Mon, Aug 3, 2015 at 7:40 PM, Yaroslav Halchenko wrote: > > On Mon, 03 Aug 2015, Matthew Brett wrote: > >> >> You can also easily junk a set of installs with: > >> >> rmvirtualenv my-env > >> >> How do you do that? > >> > not sure on specifics of this question -- "rm -rf my-env"? ;) My >> > virtualenvs aren't usually long-lived. > >> Sorry - I only meant that - if I do say apt-get install python-vtk - >> then I will get that package and all the relevant dependencies, as >> decided by the packager. Then I will get those packages in all my >> virtualenvs with ``--system-site-packages``, past and present, which >> might change their behavior. > > that is right! and if my package depends on that behavior, and starts > to fail -- I better know that! ;) Yes, I can see that you might want to (potentially) disrupt old environments. On the other hand, imagine installing python-vtk for some reason, and then testing another package - A - that does not depend on vtk, but does import vtk. At the moment it works, but it shouldn't, because the user can't rely on vtk being installed on their system. So you fail to detect a missing dependency because of an accident in the order of your installs. But anyway - I do see that these both have advantages. For me, virtualenvs with a well-stocked wheelhouse are a bit like git - once you've got used to them, you come to rely on quickly making a test environment and throwing it away afterwards. From lists at onerussian.com Mon Aug 3 22:26:55 2015 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Aug 2015 16:26:55 -0400 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: <20150803141716.GL28964@onerussian.com> <20150803154901.GN28964@onerussian.com> <20150803184030.GQ28964@onerussian.com> Message-ID: <20150803202655.GS28964@onerussian.com> On Mon, 03 Aug 2015, Matthew Brett wrote: > > that is right! and if my package depends on that behavior, and starts > > to fail -- I better know that! ;) > Yes, I can see that you might want to (potentially) disrupt old environments. > On the other hand, imagine installing python-vtk for some reason, and > then testing another package - A - that does not depend on vtk, but > does import vtk. At the moment it works, but it shouldn't, because > the user can't rely on vtk being installed on their system. So you > fail to detect a missing dependency because of an accident in the > order of your installs. agree. but once again -- my ultimate goal/practice is at the end to create a debian package for those modules/packages. That is usually when I pin point all necessary dependencies 100% exhaustive (since otherwise build in a clean env would fail) and have a sweep through all supported debian/ubuntu environments to see if compatibility is broken with any of the versions of packages they provide/support. And if I am developing the target package, then when I decide to use vtk, I will add it to requirements.txt. > But anyway - I do see that these both have advantages. For me, > virtualenvs with a well-stocked wheelhouse are a bit like git - once > you've got used to them, you come to rely on quickly making a test > environment and throwing it away afterwards. ;) yeah -- those throw away environments are really nice -- with virtualenv, or docker or ... but the original question I thought was more about user-side of the story -- how to maintain a usable user/research environment, especially whenever the desire to install/uninstall/try new stuff is pressing ;) And for that it was my "recipe" -- as much of apt-get as possible + virtualenv+pip (ideally with explicit list in e.g. requirements.txt) when necessary. I would not really recommend system-wide or even --user installs with pip since then you let the wild goose out ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From arokem at gmail.com Mon Aug 3 23:01:59 2015 From: arokem at gmail.com (Ariel Rokem) Date: Mon, 3 Aug 2015 14:01:59 -0700 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: <20150803171424.GH3363168@phare.normalesup.org> References: <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> <20150803171424.GH3363168@phare.normalesup.org> Message-ID: Yeah, I'm also -1 on flask. Seems like you would have to build from scratch a static webpage generator out of a system that really isn't meant to be a static webpage generator, while never needing/using what flask is actually for. My preference in order: * Jekyll - the tool built specifically for serving up github pages. That's basically the negative of the above argument against flask. In contrast to all the other options, this provides continuous integration for building the webpages. Requires zero installation to contribute. * Pelican - also up to the job, but requires that someone build the website locally on their machine every time a change is made. Requires people learn a new system (at least those that aren't already building their own blogs with this), but hey, at least it's written in Python. * Sphinx - has the advantage that it's already being used by all the projects in the eco-system. The advantage of familiarity is balanced by general finickiness, that we have all grown to tolerate. Also, I am not sure what we'd need to do to create a mobile-responsive website, while both Pelican and Jekyll do that out of the box. In my opinion the best solution would be a Jekyll-backed webpage with the layout and design of the page that Vanessa created. Cheers, Ariel On Mon, Aug 3, 2015 at 10:14 AM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > -1 on flask: it's twisting something that not been built for this > purpose. > > My votes in order of preference (note that my opinion doesn't matter > much, as I won't be doing the work): > > * sphinx: every package of the nipy constellation already uses it > * pelican: I have a great experience with it (using purecss that's much > lighter than bootstrap, check my personnal website out) > * jekyll: seems reasonnably easy to use, but will require most people to > learn a new development ecosystem > * flask: great project to serve dynamic websites, but not designed for > static. > > Gael > > On Mon, Aug 03, 2015 at 06:38:05AM -0700, vanessa sochat wrote: > > My .02 on flask: > > > The extra step is "freezing." The workflow to push an update will always > be > > something along the lines of: > > > - checkout or clone current flask site > > - do changes > > - freeze > > - push to gh-pages > > > This seems do-able to me, but I sense that others aren't happy about the > extra > > step, and I am open to the idea that other frameworks could do it better, > > perhaps at the cost of the more "interactive" back end allowed by flask. > At the > > end of the day, it doesn't really matter so much as long as updating / > adding > > content is relatively straight forward and pain free. Looking forward to > more > > discussion on this. > > > On Mon, Aug 3, 2015 at 6:33 AM, vanessa sochat > wrote: > > > This week we should perhaps vote/decide on a final framework to port > the > > nipy site into? I'm open to giving a go at whatever the group thinks > is > > best :) > > > On Mon, Aug 3, 2015 at 6:11 AM, Ariel Rokem > wrote: > > > > On Wed, Jul 29, 2015 at 8:38 PM, David Moreno-Dominguez < > > d.mor.dom at gmail.com> wrote: > > > Doesnt Dipy already do this? (be open source and compute FA > images > > [and much more] from any dwi dataset) > > > > Absolutely - I was being ironic. > > > But I will admit that irony doesn't travel well by email. > > > > > On Wed, Jul 29, 2015 at 8:06 PM, Ariel Rokem < > arokem at gmail.com> > > wrote: > > > > On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux > > > wrote: > > > >> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem > wrote: > > >> > PS: Vanessa: Nilearn is not only for fMRI. It's for > > statistical > > >> > analysis > > >> > of images. It is also used for anatomical images: > > >> > http://nilearn.github.io/auto_examples/decoding/ > > plot_oasis_vbm.html > > >> > If we could get a preprocessed, openly downloadable > set of > > images of > > >> > eg > > >> > FA, we would do an example with diffusion too. > > > >> > Completely off-topic, but I can't resist: if only there > was an > > >> > open-source project that computed FA images from freely > > available > > >> > diffusion MRI data-sets! > > > >> Well, you're welcome to help us with preprocessing and > pitching > > a > > >> relevant prediction problem from this data. I know > nothing about > > >> diffusion and nothing about the datasets you are talking > about. > > In my > > >> experience, writing a relevant example requires > understanding > > the data > > >> and the questions. If you, or someone else, gets us to > the point > > where > > >> there is a set of nifti images of FA with condition A and > > condition B, > > >> and helps us write the story, than we have an example. > > > > > Hmm. Interesting idea. I am looking around for something > along > > these lines. > > > I think that there are some freely available data-sets > that are > > already > > > preprocessed, so could be used in this way. Let me think > about > > how to go > > > about this. > > > > >> Ga?l > > >> _______________________________________________ > > >> Neuroimaging mailing list > > >> Neuroimaging at python.org > > >> https://mail.python.org/mailman/listinfo/neuroimaging > > > > > > _______________________________________________ > > > Neuroimaging mailing list > > > Neuroimaging at python.org > > > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > -- > Gael Varoquaux > Researcher, INRIA Parietal > NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France > Phone: ++ 33-1-69-08-79-68 > http://gael-varoquaux.info http://twitter.com/GaelVaroquaux > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 3 23:04:59 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Mon, 3 Aug 2015 14:04:59 -0700 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> <20150803171424.GH3363168@phare.normalesup.org> Message-ID: I'm also thinking -1 on Flask. The first time I tried Jekyll I was slightly allergic to it, but I'd definitely be excited to give it another go! It is nicely integrated into Github, so perhaps they have thought about the comparison between these frameworks a bit. On Mon, Aug 3, 2015 at 2:01 PM, Ariel Rokem wrote: > Yeah, I'm also -1 on flask. > > Seems like you would have to build from scratch a static webpage generator > out of a system that really isn't meant to be a static webpage generator, > while never needing/using what flask is actually for. > > My preference in order: > > * Jekyll - the tool built specifically for serving up github pages. That's > basically the negative of the above argument against flask. In contrast to > all the other options, this provides continuous integration for building > the webpages. Requires zero installation to contribute. > * Pelican - also up to the job, but requires that someone build the > website locally on their machine every time a change is made. Requires > people learn a new system (at least those that aren't already building > their own blogs with this), but hey, at least it's written in Python. > * Sphinx - has the advantage that it's already being used by all the > projects in the eco-system. The advantage of familiarity is balanced by > general finickiness, that we have all grown to tolerate. Also, I am not > sure what we'd need to do to create a mobile-responsive website, while both > Pelican and Jekyll do that out of the box. > > In my opinion the best solution would be a Jekyll-backed webpage with the > layout and design of the page that Vanessa created. > > Cheers, > > Ariel > > On Mon, Aug 3, 2015 at 10:14 AM, Gael Varoquaux < > gael.varoquaux at normalesup.org> wrote: > >> -1 on flask: it's twisting something that not been built for this >> purpose. >> >> My votes in order of preference (note that my opinion doesn't matter >> much, as I won't be doing the work): >> >> * sphinx: every package of the nipy constellation already uses it >> * pelican: I have a great experience with it (using purecss that's much >> lighter than bootstrap, check my personnal website out) >> * jekyll: seems reasonnably easy to use, but will require most people to >> learn a new development ecosystem >> * flask: great project to serve dynamic websites, but not designed for >> static. >> >> Gael >> >> On Mon, Aug 03, 2015 at 06:38:05AM -0700, vanessa sochat wrote: >> > My .02 on flask: >> >> > The extra step is "freezing." The workflow to push an update will >> always be >> > something along the lines of: >> >> > - checkout or clone current flask site >> > - do changes >> > - freeze >> > - push to gh-pages >> >> > This seems do-able to me, but I sense that others aren't happy about >> the extra >> > step, and I am open to the idea that other frameworks could do it >> better, >> > perhaps at the cost of the more "interactive" back end allowed by >> flask. At the >> > end of the day, it doesn't really matter so much as long as updating / >> adding >> > content is relatively straight forward and pain free. Looking forward >> to more >> > discussion on this. >> >> > On Mon, Aug 3, 2015 at 6:33 AM, vanessa sochat >> wrote: >> >> > This week we should perhaps vote/decide on a final framework to >> port the >> > nipy site into? I'm open to giving a go at whatever the group >> thinks is >> > best :) >> >> > On Mon, Aug 3, 2015 at 6:11 AM, Ariel Rokem >> wrote: >> >> >> > On Wed, Jul 29, 2015 at 8:38 PM, David Moreno-Dominguez < >> > d.mor.dom at gmail.com> wrote: >> >> > Doesnt Dipy already do this? (be open source and compute FA >> images >> > [and much more] from any dwi dataset) >> >> >> > Absolutely - I was being ironic. >> >> > But I will admit that irony doesn't travel well by email. >> > >> >> > On Wed, Jul 29, 2015 at 8:06 PM, Ariel Rokem < >> arokem at gmail.com> >> > wrote: >> >> > > On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux >> > > wrote: >> >> > >> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem >> wrote: >> > >> > PS: Vanessa: Nilearn is not only for fMRI. It's for >> > statistical >> > >> > analysis >> > >> > of images. It is also used for anatomical images: >> > >> > http://nilearn.github.io/auto_examples/decoding/ >> > plot_oasis_vbm.html >> > >> > If we could get a preprocessed, openly >> downloadable set of >> > images of >> > >> > eg >> > >> > FA, we would do an example with diffusion too. >> >> > >> > Completely off-topic, but I can't resist: if only >> there was an >> > >> > open-source project that computed FA images from freely >> > available >> > >> > diffusion MRI data-sets! >> >> > >> Well, you're welcome to help us with preprocessing and >> pitching >> > a >> > >> relevant prediction problem from this data. I know >> nothing about >> > >> diffusion and nothing about the datasets you are talking >> about. >> > In my >> > >> experience, writing a relevant example requires >> understanding >> > the data >> > >> and the questions. If you, or someone else, gets us to >> the point >> > where >> > >> there is a set of nifti images of FA with condition A and >> > condition B, >> > >> and helps us write the story, than we have an example. >> >> >> > > Hmm. Interesting idea. I am looking around for something >> along >> > these lines. >> > > I think that there are some freely available data-sets >> that are >> > already >> > > preprocessed, so could be used in this way. Let me think >> about >> > how to go >> > > about this. >> >> >> > >> Ga?l >> > >> _______________________________________________ >> > >> Neuroimaging mailing list >> > >> Neuroimaging at python.org >> > >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> >> >> > > _______________________________________________ >> > > Neuroimaging mailing list >> > > Neuroimaging at python.org >> > > https://mail.python.org/mailman/listinfo/neuroimaging >> >> > _______________________________________________ >> > Neuroimaging mailing list >> > Neuroimaging at python.org >> > https://mail.python.org/mailman/listinfo/neuroimaging >> >> >> >> > _______________________________________________ >> > Neuroimaging mailing list >> > Neuroimaging at python.org >> > https://mail.python.org/mailman/listinfo/neuroimaging >> -- >> Gael Varoquaux >> Researcher, INRIA Parietal >> NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France >> Phone: ++ 33-1-69-08-79-68 >> http://gael-varoquaux.info >> http://twitter.com/GaelVaroquaux >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Mon Aug 3 23:08:00 2015 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 3 Aug 2015 23:08:00 +0200 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> <20150803171424.GH3363168@phare.normalesup.org> Message-ID: <20150803210800.GJ2853615@phare.normalesup.org> On Mon, Aug 03, 2015 at 02:01:59PM -0700, Ariel Rokem wrote: > * Sphinx - has the advantage that it's already being used by all the projects > in the eco-system. The advantage of familiarity is balanced by general > finickiness, that we have all grown to tolerate. Also, I am not sure what we'd > need to do to create a mobile-responsive website, while both Pelican and Jekyll > do that out of the box.? Nilearn's website is mobile responsive. In a basic way, granted, but it's labeled as mobile friendly by google and looks good on a mobile phone. It's built with sphinx and no crazy CSS framework. It's actually really simple to do simple CSS rules to build mobile-friend website. You may argue that people don't know how to do them, but in my experience using complex framework without understanding CSS doesn't solve the problem. Ga?l From vsochat at stanford.edu Mon Aug 3 23:10:42 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Mon, 3 Aug 2015 14:10:42 -0700 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: <20150803210800.GJ2853615@phare.normalesup.org> References: <20150727052501.GB550510@phare.normalesup.org> <20150727174426.GW705713@phare.normalesup.org> <20150803171424.GH3363168@phare.normalesup.org> <20150803210800.GJ2853615@phare.normalesup.org> Message-ID: Yeah, I've never thought about how to make a website mobile friendly, so I definitely fall in that category. But don't worry, I'm not old fart-enough so I can't learn things still :_) On Mon, Aug 3, 2015 at 2:08 PM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > On Mon, Aug 03, 2015 at 02:01:59PM -0700, Ariel Rokem wrote: > > * Sphinx - has the advantage that it's already being used by all the > projects > > in the eco-system. The advantage of familiarity is balanced by general > > finickiness, that we have all grown to tolerate. Also, I am not sure > what we'd > > need to do to create a mobile-responsive website, while both Pelican and > Jekyll > > do that out of the box. > > Nilearn's website is mobile responsive. In a basic way, granted, but it's > labeled as mobile friendly by google and looks good on a mobile phone. > It's built with sphinx and no crazy CSS framework. > > It's actually really simple to do simple CSS rules to build mobile-friend > website. You may argue that people don't know how to do them, but in my > experience using complex framework without understanding CSS doesn't > solve the problem. > > Ga?l > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Aug 3 23:10:44 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Aug 2015 22:10:44 +0100 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: Message-ID: On Mon, Aug 3, 2015 at 5:49 PM, JB Poline wrote: > That's a very useful page to me - > A quick possible addition : why / when use the --user option ? (and get > packages in .local/... ) I personally don't use --user very often, just because I have got used to starting a new virtualenv whenever I do something. For example, if I am working on dipy I might do: mkvirtualenv dipy-work pip install -r requirements.txt This takes a few seconds on my machine because the relevant wheels are built and cached. > I also wonder if examples of trouble shooting or install that raised > difficulties could be added there in a "use cases" section : by reading how > some issues where solved I'm sure I could learn a bit more how to debug > install that go wrong. How about raising an Issue on that repo when you run into trouble, and we can try and add something useful on solving the problem? https://github.com/matthew-brett/pydagogue/issues I'll add something at the bottom of the page. See you, Matthew From gael.varoquaux at normalesup.org Mon Aug 3 23:16:19 2015 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 3 Aug 2015 23:16:19 +0200 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150727174426.GW705713@phare.normalesup.org> <20150803171424.GH3363168@phare.normalesup.org> <20150803210800.GJ2853615@phare.normalesup.org> Message-ID: <20150803211619.GK2853615@phare.normalesup.org> On Mon, Aug 03, 2015 at 02:10:42PM -0700, vanessa sochat wrote: > Yeah, I've never thought about how to make a website mobile friendly, so I > definitely fall in that category.? It's really simple: @media css selector. You just need to use a little bit of this, and make sure that things adapt. You can have a look at the nilearn css. G From moloney at ohsu.edu Mon Aug 3 23:34:27 2015 From: moloney at ohsu.edu (Brendan Moloney) Date: Mon, 3 Aug 2015 21:34:27 +0000 Subject: [Neuroimaging] Reading Dicom files with nibabel In-Reply-To: References: <70E13D56-96CC-4EC1-97EB-74FE7BC59A37@telecom-bretagne.eu> , Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF88657AE27@EXMB09.ohsu.edu> Hi, > Chris is right - dcmstack is the current best answer. > > To expand a bit - we plan to integrate dcmstack and nibabel at some > point, but progress is slow, that is mainly my fault. Well I think most of the blame is on me... But yes, we are still working (slowly) towards some integration. I actually have a little bit of time here and there to work on this now (and hopefully much more in the near future). I have a PR that is about 90% complete for doing additional meta data extraction from private sub-headers (just Siemens currently but the approach is generic): https://github.com/nipy/nibabel/pull/290 That PR is actually extracting much more meta data than dcmstack does currently, so that is why it is taking a while. A nice side benefit is that this will let us read Siemens raw measurement (k-space) files. After that I want to start a PR for the actual DICOM -> Nifti conversion, which should be somewhat straight forward as this will look more similar to the code already in dcmstack. Eventually we need some meta data anonymization. Satra suggested support for CTP anonymization profiles and I agree that is a good way to go. I just want to allow it to be modified also in a pythonic manner (i.e. don't require people go and edit XML profiles). The last step would be storing extracted meta data in a Nifti header extension: https://github.com/nipy/nibabel/wiki/json-header-extension But it sounds like you are mostly interested in plain DICOM to Nifti conversion (step 2), which may actually get integrated in the not-to- distant future. Thanks, Brendan From jbpoline at gmail.com Tue Aug 4 00:06:42 2015 From: jbpoline at gmail.com (JB Poline) Date: Mon, 3 Aug 2015 15:06:42 -0700 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: Message-ID: On Mon, Aug 3, 2015 at 2:10 PM, Matthew Brett wrote: > On Mon, Aug 3, 2015 at 5:49 PM, JB Poline wrote: > > That's a very useful page to me - > > A quick possible addition : why / when use the --user option ? (and get > > packages in .local/... ) > > I personally don't use --user very often, just because I have got used > to starting a new virtualenv whenever I do something. For example, > if I am working on dipy I might do: > > mkvirtualenv dipy-work > pip install -r requirements.txt > > This takes a few seconds on my machine because the relevant wheels are > built and cached. > Looks like this would be a nice little addition to your explanations > > > I also wonder if examples of trouble shooting or install that raised > > difficulties could be added there in a "use cases" section : by reading > how > > some issues where solved I'm sure I could learn a bit more how to debug > > install that go wrong. > > How about raising an Issue on that repo when you run into trouble, and > we can try and add something useful on solving the problem? > > https://github.com/matthew-brett/pydagogue/issues > > I'll add something at the bottom of the page. > ok - will do when I run into trouble (so probably often and soon) see ya JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.gorgolewski at gmail.com Tue Aug 4 04:01:54 2015 From: krzysztof.gorgolewski at gmail.com (Chris Filo Gorgolewski) Date: Mon, 3 Aug 2015 19:01:54 -0700 Subject: [Neuroimaging] Brain Imaging Data Structure - call for feedback Message-ID: Dear neuroimaging community, Most of our daily work involves data - acquiring, organizing, cleaning, analyzing, understanding, and explaining data. MRI scanners produce a lot of complicated outputs with rich metadata needed for further analysis. In addition all of the external measures of behaviour and individual differences contribute to the complexity of acquired data. It is easy to get lost in this chaos especially for early scientists new to the field. How we store, organize, and describe neuropsychological data has been an individual issue. Each researcher had their own way of describing data. Such approach can be problematic when one dataset needs to be used by more than one person. Imagine a situation when as a PI you want your postdoc to reanalyze an old dataset acquired by a long gone PhD student just to discover that bits are missing and the rest is an unreadable Excel spreadsheet. We want to solve this problem. For the past couple of months we have been working on a specification describing how to organize and describe neuropsychological data obtained from fMRI (task and rest), structural, and diffusion experiments. Our goal was to make it easy to adopt and mirroring practices people already follow, but at the same time friendly for developers. The new standard is called Brain Imaging Data Structure (BIDS - http://bids.neuroimaging.io/) and it's based on folders, NIFTI, JSON and tabular files. It does not require any software (such as a database). It's intended to capture raw data, but it's easy to extend with derivatives. This is how a BIDS dataset looks like: https://55b6842373553c2422bd99ac533b084533ea6cb7.googledrive.com/host/0B2JWN60ZLkgkQm9ZazZCWS1VNVE/ds114/ Here's the full spec: http://bids.neuroimaging.io/bids_spec0.4.pdf Having a common formalized way of organizing and describing data have advantages beyond sharing across members of the same lab. Workflow developers can build tools that will be able to preprocess your data with very little user input. It will be also easier import such formatted dataset into databases (XNAT, COINS, Scitran, NiDB, openfmri etc.) and share it with wider public. We already started writing tools (and OpenfMRI2BIDS converter: https://github.com/INCF/openfmri2bids and BIDS validator: https://github.com/Squishymedia/bids-validator) and we hope that mayor pipeline engines (LONI, AA, C-PAC, REST, PSOM, Nipype etc.) will adopt BIDS. We have also prepared many example dataset showcasing the new standard: https://55b6842373553c2422bd99ac533b084533ea6cb7.googledrive.com/host/0B2JWN60ZLkgkQm9ZazZCWS1VNVE/ (they are all task based fMRI, but I will soon add some resting state as well). We would love to hear your feedback. Would you recommend this for your lab? Does it cover the types of studies you do? Either reply to this email or comment on the current working draft: https://docs.google.com/document/d/1HFUkAEE-pB-angVcYe6pf_-fVf4sCpOHKesUvfb8Grc/edit?usp=sharing Best, Chris Gorgolewski and the INCF Data Sharing Task Force -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrudascas at gmail.com Tue Aug 4 22:14:33 2015 From: jrudascas at gmail.com (Jorge Rudas) Date: Tue, 4 Aug 2015 15:14:33 -0500 Subject: [Neuroimaging] Tractography normalization Message-ID: Hi everyone Any suggestions for to spatial normalization of tractographys?. I want compare tractographys at population level. regards, *Jorge Rudas* *National University of Colombia* -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Tue Aug 4 22:55:58 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Tue, 4 Aug 2015 16:55:58 -0400 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Hi Jorge, This is a very active research area in DIPY. There are currently two ways: a) You can register FA images together using our image registration functions and then apply the deformation fields to the tractographies. b) Segment bundles from the tractographies (manually or automatically) and register them directly using the SLR. Paper here http://www.ncbi.nlm.nih.gov/pubmed/25987367 Cheers, Eleftherios On Tue, Aug 4, 2015 at 4:14 PM, Jorge Rudas wrote: > Hi everyone > > Any suggestions for to spatial normalization of tractographys?. I want > compare tractographys at population level. > > regards, > > *Jorge Rudas* > > *National University of Colombia* > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrudascas at gmail.com Wed Aug 5 01:21:10 2015 From: jrudascas at gmail.com (Jorge Rudas) Date: Tue, 4 Aug 2015 18:21:10 -0500 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Thanks for your answer Eleftherios One questions more... When you say "then apply the deformation fields to the tractographies", what exactly does this mean ? Regards *Jorge Rudas* 2015-08-04 15:55 GMT-05:00 Eleftherios Garyfallidis : > Hi Jorge, > > This is a very active research area in DIPY. There are currently two ways: > > a) You can register FA images together using our image registration > functions and then apply the deformation fields to the tractographies. > > b) Segment bundles from the tractographies (manually or automatically) and > register them directly using the SLR. Paper here > > http://www.ncbi.nlm.nih.gov/pubmed/25987367 > > Cheers, > Eleftherios > > > > On Tue, Aug 4, 2015 at 4:14 PM, Jorge Rudas wrote: > >> Hi everyone >> >> Any suggestions for to spatial normalization of tractographys?. I want >> compare tractographys at population level. >> >> regards, >> >> *Jorge Rudas* >> >> *National University of Colombia* >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Wed Aug 5 03:25:54 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Tue, 4 Aug 2015 21:25:54 -0400 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Hello, On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: > Thanks for your answer Eleftherios > > One questions more... > > Be happy to ask as many questions as you need until everything is clear. I am sure you will need feedback from us to perform such an analysis. That is because although we are currently working on making easy workflows, right now you will need write your own scripts combining different DIPY tutorials of the development version. Of course I am more than happy to help you with this. > When you say "then apply the deformation fields to the tractographies", > what exactly does this mean ? > > You will generate streamlines and FA maps in the native space of every subject. Then you can for example register the FAs to an FA template. After you have performed this registrations you will also have saved the deformation fields which were applied to the FAs so that they can be registered to the FA template. Because the tractographies were in the same space (native) as the FAs the same deformation fields can be used to warp them to the FA template space and in that way your tractographies will also be normalized. Cheers, Eleftherios p.s. As an FA template I recommend using the IIT atlas. > Regards > > > *Jorge Rudas* > > > 2015-08-04 15:55 GMT-05:00 Eleftherios Garyfallidis < > garyfallidis at gmail.com>: > >> Hi Jorge, >> >> This is a very active research area in DIPY. There are currently two ways: >> >> a) You can register FA images together using our image registration >> functions and then apply the deformation fields to the tractographies. >> >> b) Segment bundles from the tractographies (manually or automatically) >> and register them directly using the SLR. Paper here >> >> http://www.ncbi.nlm.nih.gov/pubmed/25987367 >> >> Cheers, >> Eleftherios >> >> >> >> On Tue, Aug 4, 2015 at 4:14 PM, Jorge Rudas wrote: >> >>> Hi everyone >>> >>> Any suggestions for to spatial normalization of tractographys?. I want >>> compare tractographys at population level. >>> >>> regards, >>> >>> *Jorge Rudas* >>> >>> *National University of Colombia* >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbpoline at gmail.com Wed Aug 5 03:42:33 2015 From: jbpoline at gmail.com (JB Poline) Date: Tue, 4 Aug 2015 18:42:33 -0700 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Hi, I was curious about the IIT license: does anyone understand " (2) You may not alter, transform, adapt or build upon the information, images or data; " so : "build upon the information" is a bit vague : I guess you cannot create an atlas or anything from it, you have to use it as it is ? That seems bad - but may be I missed something ? cheers JB On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hello, > > On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: > >> Thanks for your answer Eleftherios >> >> One questions more... >> >> Be happy to ask as many questions as you need until everything is clear. > I am sure you will need > feedback from us to perform such an analysis. That is because although we > are currently working on making > easy workflows, right now you will need write your own scripts combining > different DIPY tutorials of the > development version. > > Of course I am more than happy to help you with this. > > >> When you say "then apply the deformation fields to the tractographies", >> what exactly does this mean ? >> >> You will generate streamlines and FA maps in the native space of every > subject. Then you can for example register > the FAs to an FA template. After you have performed this registrations you > will also have saved the deformation fields > which were applied to the FAs so that they can be registered to the FA > template. Because the tractographies were > in the same space (native) as the FAs the same deformation fields can be > used to warp them to the FA template space > and in that way your tractographies will also be normalized. > > Cheers, > Eleftherios > > p.s. As an FA template I recommend using the IIT atlas. > > >> Regards >> >> >> *Jorge Rudas* >> >> >> 2015-08-04 15:55 GMT-05:00 Eleftherios Garyfallidis < >> garyfallidis at gmail.com>: >> >>> Hi Jorge, >>> >>> This is a very active research area in DIPY. There are currently two >>> ways: >>> >>> a) You can register FA images together using our image registration >>> functions and then apply the deformation fields to the tractographies. >>> >>> b) Segment bundles from the tractographies (manually or automatically) >>> and register them directly using the SLR. Paper here >>> >>> http://www.ncbi.nlm.nih.gov/pubmed/25987367 >>> >>> Cheers, >>> Eleftherios >>> >>> >>> >>> On Tue, Aug 4, 2015 at 4:14 PM, Jorge Rudas wrote: >>> >>>> Hi everyone >>>> >>>> Any suggestions for to spatial normalization of tractographys?. I want >>>> compare tractographys at population level. >>>> >>>> regards, >>>> >>>> *Jorge Rudas* >>>> >>>> *National University of Colombia* >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Wed Aug 5 03:54:47 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Tue, 4 Aug 2015 21:54:47 -0400 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Hi JB, I am not familiar with the restrictions of the license. I think that Konstantinos is the best person to answer this question. I am cc'ing him. You may want to continue this discussion in a different thread as it is a bit off topic. Cheers, Eleftherios On Tue, Aug 4, 2015 at 9:42 PM, JB Poline wrote: > Hi, > > I was curious about the IIT license: does anyone understand > > " > (2) You may not alter, transform, adapt or build upon the information, > images or data; > " > > so : "build upon the information" is a bit vague : I guess you cannot > create an atlas or anything from it, you have to use it as it is ? That > seems bad - but may be I missed something ? > > cheers > > JB > > > > On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> Hello, >> >> On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: >> >>> Thanks for your answer Eleftherios >>> >>> One questions more... >>> >>> Be happy to ask as many questions as you need until everything is clear. >> I am sure you will need >> feedback from us to perform such an analysis. That is because although we >> are currently working on making >> easy workflows, right now you will need write your own scripts combining >> different DIPY tutorials of the >> development version. >> >> Of course I am more than happy to help you with this. >> >> >>> When you say "then apply the deformation fields to the tractographies", >>> what exactly does this mean ? >>> >>> You will generate streamlines and FA maps in the native space of every >> subject. Then you can for example register >> the FAs to an FA template. After you have performed this registrations >> you will also have saved the deformation fields >> which were applied to the FAs so that they can be registered to the FA >> template. Because the tractographies were >> in the same space (native) as the FAs the same deformation fields can be >> used to warp them to the FA template space >> and in that way your tractographies will also be normalized. >> >> Cheers, >> Eleftherios >> >> p.s. As an FA template I recommend using the IIT atlas. >> >> >>> Regards >>> >>> >>> *Jorge Rudas* >>> >>> >>> 2015-08-04 15:55 GMT-05:00 Eleftherios Garyfallidis < >>> garyfallidis at gmail.com>: >>> >>>> Hi Jorge, >>>> >>>> This is a very active research area in DIPY. There are currently two >>>> ways: >>>> >>>> a) You can register FA images together using our image registration >>>> functions and then apply the deformation fields to the tractographies. >>>> >>>> b) Segment bundles from the tractographies (manually or automatically) >>>> and register them directly using the SLR. Paper here >>>> >>>> http://www.ncbi.nlm.nih.gov/pubmed/25987367 >>>> >>>> Cheers, >>>> Eleftherios >>>> >>>> >>>> >>>> On Tue, Aug 4, 2015 at 4:14 PM, Jorge Rudas >>>> wrote: >>>> >>>>> Hi everyone >>>>> >>>>> Any suggestions for to spatial normalization of tractographys?. I want >>>>> compare tractographys at population level. >>>>> >>>>> regards, >>>>> >>>>> *Jorge Rudas* >>>>> >>>>> *National University of Colombia* >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.alexandre at gmail.com Wed Aug 5 10:26:46 2015 From: abraham.alexandre at gmail.com (Alexandre ABRAHAM) Date: Wed, 5 Aug 2015 10:26:46 +0200 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: <20150803211619.GK2853615@phare.normalesup.org> References: <20150727174426.GW705713@phare.normalesup.org> <20150803171424.GH3363168@phare.normalesup.org> <20150803210800.GJ2853615@phare.normalesup.org> <20150803211619.GK2853615@phare.normalesup.org> Message-ID: FYI, nilearn stats about devices. ? On Mon, Aug 3, 2015 at 11:16 PM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > On Mon, Aug 03, 2015 at 02:10:42PM -0700, vanessa sochat wrote: > > Yeah, I've never thought about how to make a website mobile friendly, so > I > > definitely fall in that category. > > It's really simple: @media css selector. You just need to use a little > bit of this, and make sure that things adapt. You can have a look at the > nilearn css. > > G > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nilearn_devices.png Type: image/png Size: 20568 bytes Desc: not available URL: From arfanakis at iit.edu Wed Aug 5 08:23:15 2015 From: arfanakis at iit.edu (Konstantinos Arfanakis) Date: Wed, 5 Aug 2015 09:23:15 +0300 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: <540B96B0-AFEE-41E4-A655-0B48594F4DAF@iit.edu> Hi JB, It would help me answer your question if you could give me a very general description of what you are planning to generate and how would that be used. Regards, Konstantinos > On Aug 5, 2015, at 4:54 AM, Eleftherios Garyfallidis wrote: > > Hi JB, > > I am not familiar with the restrictions of the license. I think that Konstantinos is the best person to answer this question. I am cc'ing him. > > You may want to continue this discussion in a different thread as it is a bit off topic. > > Cheers, > Eleftherios > >> On Tue, Aug 4, 2015 at 9:42 PM, JB Poline wrote: >> Hi, >> >> I was curious about the IIT license: does anyone understand >> >> " >> (2) You may not alter, transform, adapt or build upon the information, images or data; >> " >> so : "build upon the information" is a bit vague : I guess you cannot create an atlas or anything from it, you have to use it as it is ? That seems bad - but may be I missed something ? >> >> cheers >> >> JB >> >> >> >> >>> On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis wrote: >>> Hello, >>> >>>> On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: >>>> Thanks for your answer Eleftherios >>>> >>>> One questions more... >>> >>> Be happy to ask as many questions as you need until everything is clear. I am sure you will need >>> feedback from us to perform such an analysis. That is because although we are currently working on making >>> easy workflows, right now you will need write your own scripts combining different DIPY tutorials of the >>> development version. >>> >>> Of course I am more than happy to help you with this. >>> >>>> When you say "then apply the deformation fields to the tractographies", what exactly does this mean ? >>> >>> You will generate streamlines and FA maps in the native space of every subject. Then you can for example register >>> the FAs to an FA template. After you have performed this registrations you will also have saved the deformation fields >>> which were applied to the FAs so that they can be registered to the FA template. Because the tractographies were >>> in the same space (native) as the FAs the same deformation fields can be used to warp them to the FA template space >>> and in that way your tractographies will also be normalized. >>> >>> Cheers, >>> Eleftherios >>> >>> p.s. As an FA template I recommend using the IIT atlas. >>> >>>> Regards >>>> >>>> >>>> Jorge Rudas >>>> >>>> >>>> 2015-08-04 15:55 GMT-05:00 Eleftherios Garyfallidis : >>>>> Hi Jorge, >>>>> >>>>> This is a very active research area in DIPY. There are currently two ways: >>>>> >>>>> a) You can register FA images together using our image registration functions and then apply the deformation fields to the tractographies. >>>>> >>>>> b) Segment bundles from the tractographies (manually or automatically) and register them directly using the SLR. Paper here >>>>> >>>>> http://www.ncbi.nlm.nih.gov/pubmed/25987367 >>>>> >>>>> Cheers, >>>>> Eleftherios >>>>> >>>>> >>>>> >>>>>> On Tue, Aug 4, 2015 at 4:14 PM, Jorge Rudas wrote: >>>>>> Hi everyone >>>>>> >>>>>> Any suggestions for to spatial normalization of tractographys?. I want compare tractographys at population level. >>>>>> >>>>>> regards, >>>>>> >>>>>> Jorge Rudas >>>>>> National University of Colombia >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwaskom at stanford.edu Wed Aug 5 18:09:43 2015 From: mwaskom at stanford.edu (Michael Waskom) Date: Wed, 5 Aug 2015 09:09:43 -0700 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: Message-ID: This cheat-sheet looks like it might be somewhat helpful: http://conda.pydata.org/docs/_downloads/conda-pip-virtualenv-translator.html On Mon, Aug 3, 2015 at 3:06 PM, JB Poline wrote: > > > On Mon, Aug 3, 2015 at 2:10 PM, Matthew Brett > wrote: > >> On Mon, Aug 3, 2015 at 5:49 PM, JB Poline wrote: >> > That's a very useful page to me - >> > A quick possible addition : why / when use the --user option ? (and get >> > packages in .local/... ) >> >> I personally don't use --user very often, just because I have got used >> to starting a new virtualenv whenever I do something. For example, >> if I am working on dipy I might do: >> >> mkvirtualenv dipy-work >> pip install -r requirements.txt >> >> This takes a few seconds on my machine because the relevant wheels are >> built and cached. >> > > Looks like this would be a nice little addition to your explanations > > >> >> > I also wonder if examples of trouble shooting or install that raised >> > difficulties could be added there in a "use cases" section : by reading >> how >> > some issues where solved I'm sure I could learn a bit more how to debug >> > install that go wrong. >> >> How about raising an Issue on that repo when you run into trouble, and >> we can try and add something useful on solving the problem? >> >> https://github.com/matthew-brett/pydagogue/issues >> >> I'll add something at the bottom of the page. >> > > > ok - will do when I run into trouble (so probably often and soon) > see ya > JB > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Wed Aug 5 18:10:39 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 5 Aug 2015 12:10:39 -0400 Subject: [Neuroimaging] Technical details managing Python versions and packages. In-Reply-To: References: Message-ID: hi folks, on the note of slightly more general package management. for our most recent cluster we have switched to a project specific versioning system with modulefiles. each project creates its own environment (not just python but across other tools as well). for python, most of our cluster users use miniconda/anaconda for their environments and it has worked really well. particularly, when they need to install other non-python dependencies that conda folks have already built. each project can maintain or update their stack themselves. unlike personal computers or the cloud, on our cluster we need simultaneous access to multiple versions of packages and libraries and we cannot run docker (requires uid==0 privileges since the kernels we run have no namespace support). so traditional packaging solutions simply don't work. modulefiles and lmod is what TACC uses to support packages across their userbase, and for us following that model got us up and running relatively quickly. further, we are able to share such packaging across local institutions co-located in a central cluster computing facility. setting up openstack was not possible because of GPU needs. we also allow running vm's with vagrant, where people can use more traditional environments with package management. however, GPU passthroughs are still not clean. we encourage users to do their own testing. this project offers an alternative cross-platform solution to creating certain software stacks. https://hashdist.github.io/ i would love to hear if there are other solutions that can provide user/group-level software install in an HPC setting. we do need support for access to hardware such as GPUs and these solutions have to be usable within queuing systems. cheers, satra On Mon, Aug 3, 2015 at 6:06 PM, JB Poline wrote: > > > On Mon, Aug 3, 2015 at 2:10 PM, Matthew Brett > wrote: > >> On Mon, Aug 3, 2015 at 5:49 PM, JB Poline wrote: >> > That's a very useful page to me - >> > A quick possible addition : why / when use the --user option ? (and get >> > packages in .local/... ) >> >> I personally don't use --user very often, just because I have got used >> to starting a new virtualenv whenever I do something. For example, >> if I am working on dipy I might do: >> >> mkvirtualenv dipy-work >> pip install -r requirements.txt >> >> This takes a few seconds on my machine because the relevant wheels are >> built and cached. >> > > Looks like this would be a nice little addition to your explanations > > >> >> > I also wonder if examples of trouble shooting or install that raised >> > difficulties could be added there in a "use cases" section : by reading >> how >> > some issues where solved I'm sure I could learn a bit more how to debug >> > install that go wrong. >> >> How about raising an Issue on that repo when you run into trouble, and >> we can try and add something useful on solving the problem? >> >> https://github.com/matthew-brett/pydagogue/issues >> >> I'll add something at the bottom of the page. >> > > > ok - will do when I run into trouble (so probably often and soon) > see ya > JB > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwaskom at stanford.edu Fri Aug 7 01:30:34 2015 From: mwaskom at stanford.edu (Michael Waskom) Date: Thu, 6 Aug 2015 16:30:34 -0700 Subject: [Neuroimaging] [ANN] PySurfer 0.6 Message-ID: Hello everyone, We are pleased to announce the 0.6 release of PySurfer , a Python library for visualizing MRI and MEG data. Changes in this version include: - Simplified the selection of parameters that customize the visualization - Enhanced plotting of Freesurfer morphometry overlays (thickness, curvature, etc.) - Enhanced plotting of statistical overlays using contour maps - Improved support for scripted animation of the brain visualization See the release notes for more details about these changes. For information on installation, documentation, and the example gallery, you can visit our website (http://pysurfer.github.com/). We hope you will find it useful in your research! Michael Waskom, Eric Larson, Christian Brodbeck, and the rest of the Nipy team -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Fri Aug 7 09:18:40 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 7 Aug 2015 08:18:40 +0100 Subject: [Neuroimaging] [ANN] PySurfer 0.6 In-Reply-To: References: Message-ID: On Fri, Aug 7, 2015 at 12:30 AM, Michael Waskom wrote: > Hello everyone, > > We are pleased to announce the 0.6 release of PySurfer, a Python library for > visualizing MRI and MEG data. > > Changes in this version include: > > - Simplified the selection of parameters that customize the visualization > - Enhanced plotting of Freesurfer morphometry overlays (thickness, > curvature, etc.) > - Enhanced plotting of statistical overlays using contour maps > - Improved support for scripted animation of the brain visualization > > See the release notes for more details about these changes. > > For information on installation, documentation, and the example gallery, you > can visit our website (http://pysurfer.github.com/). > > We hope you will find it useful in your research! > > Michael Waskom, Eric Larson, Christian Brodbeck, and the rest of the Nipy > team Congratulations - and many thanks, Matthew From mwaskom at stanford.edu Fri Aug 7 17:19:07 2015 From: mwaskom at stanford.edu (Michael Waskom) Date: Fri, 7 Aug 2015 08:19:07 -0700 Subject: [Neuroimaging] [pysurfer] making background brain more transparent In-Reply-To: References: Message-ID: Hi Kristie, Just wanted to follow up on this. I assume you figured it out yourself, but in case anyone finds this thread while searching, we've released 0.6 and the documentation has two relevant examples: http://pysurfer.github.io/examples/plot_label_foci.html (shows how to pass custom parameters to the binarized curvature) http://pysurfer.github.io/examples/plot_probabilistic_label.html (shows how to use a continuous map of curvature) Best, Michael On Fri, Jul 31, 2015 at 10:19 AM, Kirstie Whitaker wrote: > Ah yes - very good point - I hadn't thought about the "see through" effect > of changing the alpha parameter. > > I'll grab the development version and see if there are any parameters that > my boss likes better than the classic ;) > > Thanks Michael and Vanessa for the suggestions! > > Kx > > On 31 July 2015 at 18:15, Michael Waskom wrote: > >> Hi Kristie, >> >> If you decrease the alpha value of the anatomy mesh, you'll be able to >> see through it. While this can be useful for "glass brain" type volume >> visualizations, it's probably not going to give you the effect you want for >> showing surface-based ROIs, as it will just be hard to tell what you're >> looking at (in my experience). For that reason, alpha isn't exposed as a >> parameter. I would say though that the development version of pysurfer lets >> you pass custom parameters for the colormap used to show the curvature (in >> binary or continuous values) so you could play around with that to see if >> you can find something that deemphasizes the anatomy. You can also plot >> with curv=False, of course, but that makes it harder to understand where >> the ROIs are. >> >> Hope that helps, >> Michael >> >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Kirstie Whitaker, PhD > Research Associate > > Department of Psychiatry > University of Cambridge > > *Mailing Address* > Brain Mapping Unit > Department of Psychiatry > Sir William Hardy Building > Downing Street > Cambridge CB2 3EB > > *Phone: *+44 7583 535 307 > *Website:* www.kirstiewhitaker.com > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sat Aug 8 00:44:06 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Fri, 7 Aug 2015 15:44:06 -0700 Subject: [Neuroimaging] nisl In-Reply-To: References: Message-ID: ah, just found this: https://github.com/nilearn/nilearn/issues/83 "Let's take our time (people might have stupid things like bookmarks)..." especially those journals :) On Fri, Aug 7, 2015 at 3:42 PM, vanessa sochat wrote: > To the cohort on this NISL team: > > https://github.com/nisl > > I found this repo/site linked in a paper from 2011 > - > is something supposed to be there? > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sat Aug 8 00:42:16 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Fri, 7 Aug 2015 15:42:16 -0700 Subject: [Neuroimaging] nisl Message-ID: To the cohort on this NISL team: https://github.com/nisl I found this repo/site linked in a paper from 2011 - is something supposed to be there? -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.soyyo at gmail.com Fri Aug 7 17:42:14 2015 From: tristan.soyyo at gmail.com (Tristan Soyyo) Date: Fri, 07 Aug 2015 17:42:14 +0200 Subject: [Neuroimaging] [nipype 0.10.0] bug in the nipype.workflows.dmri.fsl.utils file Message-ID: <55C4D1D6.3080000@gmail.com> Hello, I think there is a problem in the 0.10.0 version of nipype in the file nipype.workflows.dmri.fsl.utils in the hmc_split function. Line 251 : volid = [ref_num] Best regards. Tristan O:-) -- Tristan Moreau (PhD) Institut du Cerveau et de la Moelle Epini?re. Paris. ARAMIS : Algorithms, models and methods for images and signals of the human brain lab: http://www.aramislab.fr twitter : https://twitter.com/Tristan2Tzara skype : tzara_tristan From pellman.john at gmail.com Sat Aug 8 18:52:49 2015 From: pellman.john at gmail.com (John Pellman) Date: Sat, 8 Aug 2015 12:52:49 -0400 Subject: [Neuroimaging] [nipype 0.10.0] bug in the nipype.workflows.dmri.fsl.utils file In-Reply-To: <55C4D1D6.3080000@gmail.com> References: <55C4D1D6.3080000@gmail.com> Message-ID: Hi, I just wanted to point out that you're much more likely to get a response to bug reports if you post them on the Github issue tracker rather than here. 2015-08-07 11:42 GMT-04:00 Tristan Soyyo : > Hello, > > I think there is a problem in the 0.10.0 version of nipype in the file > nipype.workflows.dmri.fsl.utils in the hmc_split function. > > Line 251 : > volid = [ref_num] > > Best regards. > > Tristan O:-) > > -- > > Tristan Moreau (PhD) > > Institut du Cerveau et de la Moelle Epini?re. Paris. > ARAMIS : Algorithms, models and methods for images and signals of the > human brain > lab: http://www.aramislab.fr > twitter : https://twitter.com/Tristan2Tzara > skype : tzara_tristan > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 10 02:58:33 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sun, 9 Aug 2015 17:58:33 -0700 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150727174426.GW705713@phare.normalesup.org> <20150803171424.GH3363168@phare.normalesup.org> <20150803210800.GJ2853615@phare.normalesup.org> <20150803211619.GK2853615@phare.normalesup.org> Message-ID: Hi everyone, Just a quick note to let you know that the un-flasking of the site is looking good! I decided to go with Github's choice, jekyll, and I'm rather enjoying figuring out the framework. It supports data files that allowed me to generate the menus, d3, and (soon) the front page content dynamically. I didn't finish today, but did most of the hard stuffs. Will keep you updated. Best, Vanessa On Wed, Aug 5, 2015 at 1:26 AM, Alexandre ABRAHAM < abraham.alexandre at gmail.com> wrote: > FYI, nilearn stats about devices. > > > ? > > On Mon, Aug 3, 2015 at 11:16 PM, Gael Varoquaux < > gael.varoquaux at normalesup.org> wrote: > >> On Mon, Aug 03, 2015 at 02:10:42PM -0700, vanessa sochat wrote: >> > Yeah, I've never thought about how to make a website mobile friendly, >> so I >> > definitely fall in that category. >> >> It's really simple: @media css selector. You just need to use a little >> bit of this, and make sure that things adapt. You can have a look at the >> nilearn css. >> >> G >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Aug 10 10:16:55 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 10 Aug 2015 09:16:55 +0100 Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete remake In-Reply-To: References: <20150727174426.GW705713@phare.normalesup.org> <20150803171424.GH3363168@phare.normalesup.org> <20150803210800.GJ2853615@phare.normalesup.org> <20150803211619.GK2853615@phare.normalesup.org> Message-ID: Hi, On Mon, Aug 10, 2015 at 1:58 AM, vanessa sochat wrote: > > Hi everyone, > > Just a quick note to let you know that the un-flasking of the site is looking good! I decided to go with Github's choice, jekyll, and I'm rather enjoying figuring out the framework. It supports data files that allowed me to generate the menus, d3, and (soon) the front page content dynamically. > > I didn't finish today, but did most of the hard stuffs. Will keep you updated. That's good news - thanks very much for doing this. Cheers, Matthew From katiesurrence at gmail.com Mon Aug 10 19:26:01 2015 From: katiesurrence at gmail.com (Katie Surrence) Date: Mon, 10 Aug 2015 13:26:01 -0400 Subject: [Neuroimaging] FmriRealign4d: TypeError: __init__() takes at least 4 arguments (7 given) Message-ID: Dear Python neuroimagers, I'm brand new to NiPype, so excuse the very basic question. I am trying to use the FmriRealign4d algorithm. Based on the example here I wrote the following to try to slice time correct/realign a single run: _____________________________ from nipype.interfaces.nipy.preprocess import FmriRealign4d import os pth = "/media/truecrypt1/SocCog/tmp1/run1L2" infile = os.path.join(pth, '4D.nii') realigner = FmriRealign4d() realigner.inputs.in_file = [infile] realigner.inputs.tr = 2.2 realigner.inputs.slice_order = range(0, 36, 2) + range(1, 35, 2) realigner.inputs.time_interp = True res = realigner.run() _________________________________ (I added the explicit definition of time_interp because I got an error when I didn't.) Here's the new error: _________________________________________ /usr/local/lib/python2.7/dist- packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/base.py:376: UserWarning: Input slice_order requires inputs: time_interp warn(msg) Traceback (most recent call last): File "/home/katie/ks_scripts/python_scripts/pimriscripts/real4d.py", line 17, in res = realigner.run() File "/usr/local/lib/python2.7/dist-packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/base.py", line 946, in run runtime = self._run_interface(runtime) File "/usr/local/lib/python2.7/dist-packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/nipy/preprocess.py", line 162, in _run_interface start=self.inputs.start) TypeError: __init__() takes at least 4 arguments (7 given) Interface FmriRealign4d failed to run. Process finished with exit code 1 _______________________________________+ I tried following the error in the debugger and it's going so deep into such a complicated code base it seems very unlikely I'd be able to figure it out. Does anyone have any idea how to make this run? I know it's highly possible I'm doing something very obvious wrong. Thanks very much for your help. Best, Katie -- Katie Surrence, M.S. Research Coordinator Social Cognition Laboratory New York State Psychiatric Institute -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.gorgolewski at gmail.com Mon Aug 10 19:31:53 2015 From: krzysztof.gorgolewski at gmail.com (Chris Filo Gorgolewski) Date: Mon, 10 Aug 2015 10:31:53 -0700 Subject: [Neuroimaging] FmriRealign4d: TypeError: __init__() takes at least 4 arguments (7 given) In-Reply-To: References: Message-ID: Hi, Do you get the same error with the most up to date version of Nipype (0.10)? Best, Chris PS please use neurostars.org for user support next time. On Mon, Aug 10, 2015 at 10:26 AM, Katie Surrence wrote: > Dear Python neuroimagers, > > I'm brand new to NiPype, so excuse the very basic question. > > I am trying to use the FmriRealign4d algorithm. > > Based on the example here > > I wrote the following to try to slice time correct/realign a single run: > > _____________________________ > > from nipype.interfaces.nipy.preprocess import FmriRealign4d > import os > > pth = "/media/truecrypt1/SocCog/tmp1/run1L2" > > infile = os.path.join(pth, '4D.nii') > > realigner = FmriRealign4d() > realigner.inputs.in_file = [infile] > realigner.inputs.tr = 2.2 > realigner.inputs.slice_order = range(0, 36, 2) + range(1, 35, 2) > realigner.inputs.time_interp = True > res = realigner.run() > > > _________________________________ > > > (I added the explicit definition of time_interp because I got an error > when I didn't.) > > Here's the new error: > > _________________________________________ > > /usr/local/lib/python2.7/dist- > packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/base.py:376: > UserWarning: Input slice_order requires inputs: time_interp > warn(msg) > Traceback (most recent call last): > File "/home/katie/ks_scripts/python_scripts/pimriscripts/real4d.py", > line 17, in > res = realigner.run() > File > "/usr/local/lib/python2.7/dist-packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/base.py", > line 946, in run > runtime = self._run_interface(runtime) > File > "/usr/local/lib/python2.7/dist-packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/nipy/preprocess.py", > line 162, in _run_interface > start=self.inputs.start) > TypeError: __init__() takes at least 4 arguments (7 given) > Interface FmriRealign4d failed to run. > > Process finished with exit code 1 > > _______________________________________+ > > > I tried following the error in the debugger and it's going so deep into > such a complicated code base it seems very unlikely I'd be able to figure > it out. Does anyone have any idea how to make this run? I know it's > highly possible I'm doing something very obvious wrong. > > Thanks very much for your help. > > Best, > Katie > > -- > Katie Surrence, M.S. > Research Coordinator > Social Cognition Laboratory > New York State Psychiatric Institute > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katiesurrence at gmail.com Mon Aug 10 19:47:30 2015 From: katiesurrence at gmail.com (Katie Surrence) Date: Mon, 10 Aug 2015 13:47:30 -0400 Subject: [Neuroimaging] FmriRealign4d: TypeError: __init__() takes at least 4 arguments (7 given) In-Reply-To: References: Message-ID: Thanks for the heads up! Just upgrading nipype didn't work but I found a page full of packages I was supposed to have (this one: http://miykael.github.io/nipype-beginner-s-guide/installation.html) and I upgraded all of them and now it works! Sorry I wrote to the wrong list. Thanks again, Katie On Mon, Aug 10, 2015 at 1:31 PM, Chris Filo Gorgolewski < krzysztof.gorgolewski at gmail.com> wrote: > Hi, > Do you get the same error with the most up to date version of Nipype > (0.10)? > > Best, > Chris > > PS please use neurostars.org for user support next time. > > On Mon, Aug 10, 2015 at 10:26 AM, Katie Surrence > wrote: > >> Dear Python neuroimagers, >> >> I'm brand new to NiPype, so excuse the very basic question. >> >> I am trying to use the FmriRealign4d algorithm. >> >> Based on the example here >> >> I wrote the following to try to slice time correct/realign a single run: >> >> _____________________________ >> >> from nipype.interfaces.nipy.preprocess import FmriRealign4d >> import os >> >> pth = "/media/truecrypt1/SocCog/tmp1/run1L2" >> >> infile = os.path.join(pth, '4D.nii') >> >> realigner = FmriRealign4d() >> realigner.inputs.in_file = [infile] >> realigner.inputs.tr = 2.2 >> realigner.inputs.slice_order = range(0, 36, 2) + range(1, 35, 2) >> realigner.inputs.time_interp = True >> res = realigner.run() >> >> >> _________________________________ >> >> >> (I added the explicit definition of time_interp because I got an error >> when I didn't.) >> >> Here's the new error: >> >> _________________________________________ >> >> /usr/local/lib/python2.7/dist- >> packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/base.py:376: >> UserWarning: Input slice_order requires inputs: time_interp >> warn(msg) >> Traceback (most recent call last): >> File "/home/katie/ks_scripts/python_scripts/pimriscripts/real4d.py", >> line 17, in >> res = realigner.run() >> File >> "/usr/local/lib/python2.7/dist-packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/base.py", >> line 946, in run >> runtime = self._run_interface(runtime) >> File >> "/usr/local/lib/python2.7/dist-packages/nipype-0.9.2-py2.7.egg/nipype/interfaces/nipy/preprocess.py", >> line 162, in _run_interface >> start=self.inputs.start) >> TypeError: __init__() takes at least 4 arguments (7 given) >> Interface FmriRealign4d failed to run. >> >> Process finished with exit code 1 >> >> _______________________________________+ >> >> >> I tried following the error in the debugger and it's going so deep into >> such a complicated code base it seems very unlikely I'd be able to figure >> it out. Does anyone have any idea how to make this run? I know it's >> highly possible I'm doing something very obvious wrong. >> >> Thanks very much for your help. >> >> Best, >> Katie >> >> -- >> Katie Surrence, M.S. >> Research Coordinator >> Social Cognition Laboratory >> New York State Psychiatric Institute >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Katie Surrence, M.S. Research Coordinator Social Cognition Laboratory New York State Psychiatric Institute -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 13 01:10:11 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 12 Aug 2015 16:10:11 -0700 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Hi Eleftherios, Just considered this one today: On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hello, > > On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: > >> Thanks for your answer Eleftherios >> >> One questions more... >> >> Be happy to ask as many questions as you need until everything is clear. > I am sure you will need > feedback from us to perform such an analysis. That is because although we > are currently working on making > easy workflows, right now you will need write your own scripts combining > different DIPY tutorials of the > development version. > > Of course I am more than happy to help you with this. > > >> When you say "then apply the deformation fields to the tractographies", >> what exactly does this mean ? >> >> You will generate streamlines and FA maps in the native space of every > subject. Then you can for example register > the FAs to an FA template. After you have performed this registrations you > will also have saved the deformation fields > which were applied to the FAs so that they can be registered to the FA > template. Because the tractographies were > in the same space (native) as the FAs the same deformation fields can be > used to warp them to the FA template space > and in that way your tractographies will also be normalized. > Do we have an implementation of functions that take a non-linear transform and streamlines and warp the streamlines through this transform? Or should we implement something like this? As it is now, the DiffeomorphicMapping.transform method (and the functions that get called under the hood there) take a 3D or 2D image as input, but it should be fairly straightforward also enable these functions to take lists of streamlines and operate on these instead. Is this something that already works? Cheers, Ariel -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Thu Aug 13 01:33:49 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 12 Aug 2015 19:33:49 -0400 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Hi Ariel, Very good point. We don't have such a transform method that can take both streamlines and images. Certainly Omar had a similar function in some previous version of his PR where you could apply the transformations into points/streamlines. I am sure he will be happy to put those back (if they are not already). They can be useful for many things. I am not sure it is necessary to have the same transform method operating both with images and streamlines at the same time for now. As a first step I would make a function and put it in dipy.tracking.streamline where if you have a diffeomorphic map you can apply that to the streamlines. It could be an extension of transform_streamlines which works with an affine matrix. After we test this one then we can try to include it to the transform method of the Diffeomorphic Map. But we need both versions. Because some times people register the images first and then much later they want to apply the fields to the streamlines. Having such an easy API to do these things that were so messy before is SO EXCITING! :D So yeah it should be trivial with the current API. If Omar is busy with his PhD thesis we can go ahead and do it ourselves. Cheers, Eleftherios On Wed, Aug 12, 2015 at 7:10 PM, Ariel Rokem wrote: > Hi Eleftherios, > > Just considered this one today: > > On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> Hello, >> >> On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: >> >>> Thanks for your answer Eleftherios >>> >>> One questions more... >>> >>> Be happy to ask as many questions as you need until everything is clear. >> I am sure you will need >> feedback from us to perform such an analysis. That is because although we >> are currently working on making >> easy workflows, right now you will need write your own scripts combining >> different DIPY tutorials of the >> development version. >> >> Of course I am more than happy to help you with this. >> >> >>> When you say "then apply the deformation fields to the tractographies", >>> what exactly does this mean ? >>> >>> You will generate streamlines and FA maps in the native space of every >> subject. Then you can for example register >> the FAs to an FA template. After you have performed this registrations >> you will also have saved the deformation fields >> which were applied to the FAs so that they can be registered to the FA >> template. Because the tractographies were >> in the same space (native) as the FAs the same deformation fields can be >> used to warp them to the FA template space >> and in that way your tractographies will also be normalized. >> > > Do we have an implementation of functions that take a non-linear transform > and streamlines and warp the streamlines through this transform? Or should > we implement something like this? As it is now, the > DiffeomorphicMapping.transform method (and the functions that get called > under the hood there) take a 3D or 2D image as input, but it should be > fairly straightforward also enable these functions to take lists of > streamlines and operate on these instead. Is this something that already > works? > > Cheers, > > Ariel > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbpoline at gmail.com Thu Aug 13 01:59:52 2015 From: jbpoline at gmail.com (JB Poline) Date: Wed, 12 Aug 2015 16:59:52 -0700 Subject: [Neuroimaging] Tractography normalization In-Reply-To: <540B96B0-AFEE-41E4-A655-0B48594F4DAF@iit.edu> References: <540B96B0-AFEE-41E4-A655-0B48594F4DAF@iit.edu> Message-ID: Hi Konstantinos, Say I want to derive a new atlas from IIT. Can I redistribute my derived atlas freely ? cheers JB On Tue, Aug 4, 2015 at 11:23 PM, Konstantinos Arfanakis wrote: > Hi JB, > > It would help me answer your question if you could give me a very general > description of what you are planning to generate and how would that be used. > > Regards, > Konstantinos > > > > On Aug 5, 2015, at 4:54 AM, Eleftherios Garyfallidis > wrote: > > Hi JB, > > I am not familiar with the restrictions of the license. I think that > Konstantinos is the best person to answer this question. I am cc'ing him. > > You may want to continue this discussion in a different thread as it is a > bit off topic. > > Cheers, > Eleftherios > > On Tue, Aug 4, 2015 at 9:42 PM, JB Poline wrote: >> >> Hi, >> >> I was curious about the IIT license: does anyone understand >> >> " >> (2) You may not alter, transform, adapt or build upon the information, >> images or data; >> " >> >> so : "build upon the information" is a bit vague : I guess you cannot >> create an atlas or anything from it, you have to use it as it is ? That >> seems bad - but may be I missed something ? >> >> cheers >> >> JB >> >> >> >> On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis >> wrote: >>> >>> Hello, >>> >>> On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: >>>> >>>> Thanks for your answer Eleftherios >>>> >>>> One questions more... >>>> >>> Be happy to ask as many questions as you need until everything is clear. >>> I am sure you will need >>> feedback from us to perform such an analysis. That is because although we >>> are currently working on making >>> easy workflows, right now you will need write your own scripts combining >>> different DIPY tutorials of the >>> development version. >>> >>> Of course I am more than happy to help you with this. >>> >>>> >>>> When you say "then apply the deformation fields to the tractographies", >>>> what exactly does this mean ? >>>> >>> You will generate streamlines and FA maps in the native space of every >>> subject. Then you can for example register >>> the FAs to an FA template. After you have performed this registrations >>> you will also have saved the deformation fields >>> which were applied to the FAs so that they can be registered to the FA >>> template. Because the tractographies were >>> in the same space (native) as the FAs the same deformation fields can be >>> used to warp them to the FA template space >>> and in that way your tractographies will also be normalized. >>> >>> Cheers, >>> Eleftherios >>> >>> p.s. As an FA template I recommend using the IIT atlas. >>> >>>> >>>> Regards >>>> >>>> >>>> Jorge Rudas >>>> >>>> >>>> 2015-08-04 15:55 GMT-05:00 Eleftherios Garyfallidis >>>> : >>>>> >>>>> Hi Jorge, >>>>> >>>>> This is a very active research area in DIPY. There are currently two >>>>> ways: >>>>> >>>>> a) You can register FA images together using our image registration >>>>> functions and then apply the deformation fields to the tractographies. >>>>> >>>>> b) Segment bundles from the tractographies (manually or automatically) >>>>> and register them directly using the SLR. Paper here >>>>> >>>>> http://www.ncbi.nlm.nih.gov/pubmed/25987367 >>>>> >>>>> Cheers, >>>>> Eleftherios >>>>> >>>>> >>>>> >>>>> On Tue, Aug 4, 2015 at 4:14 PM, Jorge Rudas >>>>> wrote: >>>>>> >>>>>> Hi everyone >>>>>> >>>>>> Any suggestions for to spatial normalization of tractographys?. I want >>>>>> compare tractographys at population level. >>>>>> >>>>>> regards, >>>>>> >>>>>> Jorge Rudas >>>>>> National University of Colombia >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > From arokem at gmail.com Thu Aug 13 02:31:21 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 12 Aug 2015 17:31:21 -0700 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: What do you think about the following: On Wed, Aug 12, 2015 at 4:33 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hi Ariel, > > Very good point. > > We don't have such a transform method that can take both streamlines and > images. > > Certainly Omar had a similar function in some previous version of his PR > where you could apply the transformations into points/streamlines. > > I am sure he will be happy to put those back (if they are not already). > They can be useful for many things. > > I am not sure it is necessary to have the same transform method operating > both with images and streamlines at the same time for now. > > As a first step I would make a function and put it in > dipy.tracking.streamline where if you have a diffeomorphic map you can apply > that to the streamlines. It could be an extension of transform_streamlines > which works with an affine matrix. > How about refactoring this function so that if it gets a matrix, it does what it currently does, and if it gets a (x,y,z,3) array, it uses this as a warp field on the points? We can implement an `apply_warp_field` function that does that part of the function. We'd have to assume that the streamlines are already in register with the warp field, so we might end up sometimes doing something like: transform_streamlines(transform_streamlines(transform_streamlines(sl, affine), warp_field), np.linalg.inv(affine)) :-) > After we test this one then we can try to include it to the transform > method of the Diffeomorphic Map. > > But we need both versions. Because some times people register the images > first and then much later they want to apply the fields to the > streamlines. > > Having such an easy API to do these things that were so messy before is SO > EXCITING! :D > > So yeah it should be trivial with the current API. If Omar is busy with > his PhD thesis we can go ahead and do it ourselves. > > Cheers, > Eleftherios > > > On Wed, Aug 12, 2015 at 7:10 PM, Ariel Rokem wrote: > >> Hi Eleftherios, >> >> Just considered this one today: >> >> On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis < >> garyfallidis at gmail.com> wrote: >> >>> Hello, >>> >>> On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: >>> >>>> Thanks for your answer Eleftherios >>>> >>>> One questions more... >>>> >>>> Be happy to ask as many questions as you need until everything is >>> clear. I am sure you will need >>> feedback from us to perform such an analysis. That is because although >>> we are currently working on making >>> easy workflows, right now you will need write your own scripts >>> combining different DIPY tutorials of the >>> development version. >>> >>> Of course I am more than happy to help you with this. >>> >>> >>>> When you say "then apply the deformation fields to the tractographies", >>>> what exactly does this mean ? >>>> >>>> You will generate streamlines and FA maps in the native space of every >>> subject. Then you can for example register >>> the FAs to an FA template. After you have performed this registrations >>> you will also have saved the deformation fields >>> which were applied to the FAs so that they can be registered to the FA >>> template. Because the tractographies were >>> in the same space (native) as the FAs the same deformation fields can be >>> used to warp them to the FA template space >>> and in that way your tractographies will also be normalized. >>> >> >> Do we have an implementation of functions that take a non-linear >> transform and streamlines and warp the streamlines through this transform? >> Or should we implement something like this? As it is now, the >> DiffeomorphicMapping.transform method (and the functions that get called >> under the hood there) take a 3D or 2D image as input, but it should be >> fairly straightforward also enable these functions to take lists of >> streamlines and operate on these instead. Is this something that already >> works? >> >> Cheers, >> >> Ariel >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.cipollini at gmail.com Thu Aug 13 02:36:51 2015 From: ben.cipollini at gmail.com (Ben Cipollini) Date: Wed, 12 Aug 2015 17:36:51 -0700 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Maybe pass a list of matrices, rather than recursive calls? On Aug 12, 2015 5:31 PM, "Ariel Rokem" wrote: > What do you think about the following: > > On Wed, Aug 12, 2015 at 4:33 PM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> Hi Ariel, >> >> Very good point. >> >> We don't have such a transform method that can take both streamlines and >> images. >> >> Certainly Omar had a similar function in some previous version of his PR >> where you could apply the transformations into points/streamlines. >> >> I am sure he will be happy to put those back (if they are not already). >> They can be useful for many things. >> >> I am not sure it is necessary to have the same transform method operating >> both with images and streamlines at the same time for now. >> >> As a first step I would make a function and put it in >> dipy.tracking.streamline where if you have a diffeomorphic map you can apply >> that to the streamlines. It could be an extension of >> transform_streamlines which works with an affine matrix. >> > > > How about refactoring this function so that if it gets a matrix, it does > what it currently does, and if it gets a (x,y,z,3) array, it uses this as a > warp field on the points? We can implement an `apply_warp_field` function > that does that part of the function. > > We'd have to assume that the streamlines are already in register with the > warp field, so we might end up sometimes doing something like: > > transform_streamlines(transform_streamlines(transform_streamlines(sl, > affine), warp_field), np.linalg.inv(affine)) > > :-) > > > >> After we test this one then we can try to include it to the transform >> method of the Diffeomorphic Map. >> >> But we need both versions. Because some times people register the images >> first and then much later they want to apply the fields to the >> streamlines. >> >> Having such an easy API to do these things that were so messy before is >> SO EXCITING! :D >> >> So yeah it should be trivial with the current API. If Omar is busy with >> his PhD thesis we can go ahead and do it ourselves. >> >> Cheers, >> Eleftherios >> >> >> On Wed, Aug 12, 2015 at 7:10 PM, Ariel Rokem wrote: >> >>> Hi Eleftherios, >>> >>> Just considered this one today: >>> >>> On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis < >>> garyfallidis at gmail.com> wrote: >>> >>>> Hello, >>>> >>>> On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas >>>> wrote: >>>> >>>>> Thanks for your answer Eleftherios >>>>> >>>>> One questions more... >>>>> >>>>> Be happy to ask as many questions as you need until everything is >>>> clear. I am sure you will need >>>> feedback from us to perform such an analysis. That is because although >>>> we are currently working on making >>>> easy workflows, right now you will need write your own scripts >>>> combining different DIPY tutorials of the >>>> development version. >>>> >>>> Of course I am more than happy to help you with this. >>>> >>>> >>>>> When you say "then apply the deformation fields to the tractographies", >>>>> what exactly does this mean ? >>>>> >>>>> You will generate streamlines and FA maps in the native space of every >>>> subject. Then you can for example register >>>> the FAs to an FA template. After you have performed this registrations >>>> you will also have saved the deformation fields >>>> which were applied to the FAs so that they can be registered to the FA >>>> template. Because the tractographies were >>>> in the same space (native) as the FAs the same deformation fields can >>>> be used to warp them to the FA template space >>>> and in that way your tractographies will also be normalized. >>>> >>> >>> Do we have an implementation of functions that take a non-linear >>> transform and streamlines and warp the streamlines through this transform? >>> Or should we implement something like this? As it is now, the >>> DiffeomorphicMapping.transform method (and the functions that get called >>> under the hood there) take a 3D or 2D image as input, but it should be >>> fairly straightforward also enable these functions to take lists of >>> streamlines and operate on these instead. Is this something that already >>> works? >>> >>> Cheers, >>> >>> Ariel >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.eklund at liu.se Thu Aug 13 14:33:31 2015 From: anders.eklund at liu.se (Anders Eklund) Date: Thu, 13 Aug 2015 12:33:31 +0000 Subject: [Neuroimaging] [nipype] Detecting OpenCL devices Message-ID: <0D019718FD434B40866268B9AB17E71859F33E@MB3-2010.ad.liu.se> Hello, I'm working on adding BROCCOLI functions to the nipype interface. I have managed to run a BROCCOLI function through nipype, but I discovered that all my OpenCL devices are not available (for those of you unfamiliar with BROCCOLI, it is a software for fMRI analysis, it is written in OpenCL (open computing language), which makes it possible to run the same code in parallel on CPUs, AMD GPUs and Nvidia GPUs, see https://github.com/wanderine/BROCCOLI). I have a C function called GetOpenCL info, which prints information about all OpenCL devices on a machine. If I call it using subprocess it looks like this, detecting an Intel CPU and an AMD GPU >>> import subprocess >>> subprocess.call("GetOpenCLInfo") Device info --------------------------------------------- Platform number: 0 --------------------------------------------- Platform vendor: Intel(R) Corporation Platform name: Intel(R) OpenCL Platform extentions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 Platform profile: FULL_PROFILE --------------------------------------------- --------------------------------------------- Device number: 0 --------------------------------------------- Device vendor: Intel(R) Corporation Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz Hardware version: OpenCL 1.2 (Build 8) Software version: 1.2.0.8 OpenCL C version: OpenCL C 1.2 Device extensions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 Global memory size in MB: 32054 Size of largest memory object in MB: 8013 Global memory cache size in KB: 256 Local memory size in KB: 32 Constant memory size in KB: 128 Parallel compute units: 8 Clock frequency in MHz: 4000 Max number of threads per block: 8192 Max number of threads in each dimension: 8192 8192 8192 --------------------------------------------- Platform number: 1 --------------------------------------------- Platform vendor: Advanced Micro Devices, Inc. Platform name: AMD Accelerated Parallel Processing Platform extentions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices cl_amd_hsa Platform profile: FULL_PROFILE --------------------------------------------- --------------------------------------------- Device number: 0 --------------------------------------------- Device vendor: Advanced Micro Devices, Inc. Device name: Hawaii Hardware version: OpenCL 1.2 AMD-APP (1445.5) Software version: 1445.5 (VM) OpenCL C version: OpenCL C 1.2 Device extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event Global memory size in MB: 3072 Size of largest memory object in MB: 1024 Global memory cache size in KB: 16 Local memory size in KB: 32 Constant memory size in KB: 64 Parallel compute units: 44 Clock frequency in MHz: 1030 Max number of threads per block: 256 Max number of threads in each dimension: 256 256 256 --------------------------------------------- Device number: 1 --------------------------------------------- Device vendor: GenuineIntel Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz Hardware version: OpenCL 1.2 AMD-APP (1445.5) Software version: 1445.5 (sse2,avx) OpenCL C version: OpenCL C 1.2 Device extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_amd_svm cl_khr_gl_event Global memory size in MB: 32054 Size of largest memory object in MB: 8013 Global memory cache size in KB: 32 Local memory size in KB: 32 Constant memory size in KB: 64 Parallel compute units: 8 Clock frequency in MHz: 4001 Max number of threads per block: 1024 Max number of threads in each dimension: 1024 1024 1024 However, if I call the same function through nipype (using exactly the same GetOpenCL function), it looks like this, i.e. not detecting the AMD GPU. I'm a total beginner in Python, so can anyone tell me what the difference is between subprocess and how nipype actually calls the functions? >>> import nipype >>> import nipype.interfaces.broccoli as broccoli >>> info = broccoli.GetOpenCLInfo() >>> info.run() 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Device info 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform number: 0 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform vendor: Intel(R) Corporation 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform name: Intel(R) OpenCL 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform extentions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform profile: FULL_PROFILE 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Device number: 0 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Device vendor: Intel(R) Corporation 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Hardware version: OpenCL 1.2 (Build 8) 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Software version: 1.2.0.8 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:OpenCL C version: OpenCL C 1.2 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device extensions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Global memory size in MB: 32054 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Size of largest memory object in MB: 8013 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Global memory cache size in KB: 256 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Local memory size in KB: 32 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Constant memory size in KB: 128 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Parallel compute units: 8 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Clock frequency in MHz: 4000 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Max number of threads per block: 8192 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Max number of threads in each dimension: 8192 8192 8192 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform number: 1 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform vendor: Advanced Micro Devices, Inc. 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform name: AMD Accelerated Parallel Processing 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform extentions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices cl_amd_hsa 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform profile: FULL_PROFILE 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device number: 0 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device vendor: GenuineIntel 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Hardware version: OpenCL 1.2 AMD-APP (1445.5) 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Software version: 1445.5 (sse2,avx) 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:OpenCL C version: OpenCL C 1.2 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_amd_svm cl_khr_gl_event 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Global memory size in MB: 32054 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Size of largest memory object in MB: 8013 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Global memory cache size in KB: 32 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Local memory size in KB: 32 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Constant memory size in KB: 64 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Parallel compute units: 8 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Clock frequency in MHz: 4001 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Max number of threads per block: 1024 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Max number of threads in each dimension: 1024 1024 1024 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomaroceguedag at gmail.com Thu Aug 13 17:06:30 2015 From: jomaroceguedag at gmail.com (Jesus-Omar Ocegueda-Gonzalez) Date: Thu, 13 Aug 2015 10:06:30 -0500 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Hi guys!, =) Ariel, in you example: > >> transform_streamlines(transform_streamlines(transform_streamlines(sl, >> affine), warp_field), np.linalg.inv(affine)) >> >> in what coordinate system are the streamlines `sl` originally? are they in the subject's image (voxel units) or in the subject's physical space (mm. units)? I just would like to know what would be a typical use case for this. -- "Cada quien es due?o de lo que calla y esclavo de lo que dice" -Proverbio chino. "We all are owners of what we keep silent and slaves of what we say" -Chinese proverb. http://www.cimat.mx/~omar -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Thu Aug 13 17:12:34 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Thu, 13 Aug 2015 11:12:34 -0400 Subject: [Neuroimaging] [nipype] Detecting OpenCL devices In-Reply-To: <0D019718FD434B40866268B9AB17E71859F33E@MB3-2010.ad.liu.se> References: <0D019718FD434B40866268B9AB17E71859F33E@MB3-2010.ad.liu.se> Message-ID: hi anders, that is a little strange. perhaps you could mimic the nipype call. https://github.com/nipy/nipype/blob/master/nipype/interfaces/base.py#L1211 i suspect it may have something to do with either environment variables or shell=True cheers, satra On Thu, Aug 13, 2015 at 8:33 AM, Anders Eklund wrote: > Hello, > > I'm working on adding BROCCOLI functions to the nipype interface. I have > managed to run a BROCCOLI function through nipype, but I discovered that > all my OpenCL devices are not available (for those of you unfamiliar with > BROCCOLI, it is a software for fMRI analysis, it is written in OpenCL (open > computing language), which makes it possible to run the same code in > parallel on CPUs, AMD GPUs and Nvidia GPUs, see > https://github.com/wanderine/BROCCOLI). > > I have a C function called GetOpenCL info, which prints information about > all OpenCL devices on a machine. If I call it using subprocess it looks > like this, detecting an Intel CPU and an AMD GPU > > > >>> import subprocess > >>> subprocess.call("GetOpenCLInfo") > > Device info > > --------------------------------------------- > Platform number: 0 > --------------------------------------------- > Platform vendor: Intel(R) Corporation > Platform name: Intel(R) OpenCL > Platform extentions: cl_khr_icd cl_khr_global_int32_base_atomics > cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics > cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store > cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images > cl_khr_3d_image_writes cl_khr_fp64 > Platform profile: FULL_PROFILE > --------------------------------------------- > > --------------------------------------------- > Device number: 0 > --------------------------------------------- > Device vendor: Intel(R) Corporation > Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz > Hardware version: OpenCL 1.2 (Build 8) > Software version: 1.2.0.8 > OpenCL C version: OpenCL C 1.2 > Device extensions: cl_khr_icd cl_khr_global_int32_base_atomics > cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics > cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store > cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images > cl_khr_3d_image_writes cl_khr_fp64 > Global memory size in MB: 32054 > Size of largest memory object in MB: 8013 > Global memory cache size in KB: 256 > Local memory size in KB: 32 > Constant memory size in KB: 128 > Parallel compute units: 8 > Clock frequency in MHz: 4000 > Max number of threads per block: 8192 > Max number of threads in each dimension: 8192 8192 8192 > > --------------------------------------------- > Platform number: 1 > --------------------------------------------- > Platform vendor: Advanced Micro Devices, Inc. > Platform name: AMD Accelerated Parallel Processing > Platform extentions: cl_khr_icd cl_amd_event_callback > cl_amd_offline_devices cl_amd_hsa > Platform profile: FULL_PROFILE > --------------------------------------------- > > --------------------------------------------- > Device number: 0 > --------------------------------------------- > Device vendor: Advanced Micro Devices, Inc. > Device name: Hawaii > Hardware version: OpenCL 1.2 AMD-APP (1445.5) > Software version: 1445.5 (VM) > OpenCL C version: OpenCL C 1.2 > Device extensions: cl_khr_fp64 cl_amd_fp64 > cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics > cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics > cl_khr_int64_base_atomics cl_khr_int64_extended_atomics > cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing > cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 > cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt > cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event > Global memory size in MB: 3072 > Size of largest memory object in MB: 1024 > Global memory cache size in KB: 16 > Local memory size in KB: 32 > Constant memory size in KB: 64 > Parallel compute units: 44 > Clock frequency in MHz: 1030 > Max number of threads per block: 256 > Max number of threads in each dimension: 256 256 256 > > --------------------------------------------- > Device number: 1 > --------------------------------------------- > Device vendor: GenuineIntel > Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz > Hardware version: OpenCL 1.2 AMD-APP (1445.5) > Software version: 1445.5 (sse2,avx) > OpenCL C version: OpenCL C 1.2 > Device extensions: cl_khr_fp64 cl_amd_fp64 > cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics > cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics > cl_khr_int64_base_atomics cl_khr_int64_extended_atomics > cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing > cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 > cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir > cl_amd_svm cl_khr_gl_event > Global memory size in MB: 32054 > Size of largest memory object in MB: 8013 > Global memory cache size in KB: 32 > Local memory size in KB: 32 > Constant memory size in KB: 64 > Parallel compute units: 8 > Clock frequency in MHz: 4001 > Max number of threads per block: 1024 > Max number of threads in each dimension: 1024 1024 1024 > > > > > > > > However, if I call the same function through nipype (using exactly the > same GetOpenCL function), it looks like this, i.e. not detecting the AMD > GPU. I'm a total beginner in Python, so can anyone tell me what the > difference is between subprocess and how nipype actually calls the > functions? > > > > >>> import nipype > >>> import nipype.interfaces.broccoli as broccoli > >>> info = broccoli.GetOpenCLInfo() > >>> info.run() > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131: > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device info > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131: > 150813-14:27:24,780 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform number: 0 > 150813-14:27:24,780 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform vendor: Intel(R) > Corporation > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform name: Intel(R) OpenCL > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform extentions: cl_khr_icd > cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics > cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics > cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread > cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform profile: FULL_PROFILE > 150813-14:27:24,780 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131: > 150813-14:27:24,780 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device number: 0 > 150813-14:27:24,780 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device vendor: Intel(R) Corporation > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device name: Intel(R) Core(TM) > i7-4790K CPU @ 4.00GHz > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Hardware version: OpenCL 1.2 (Build > 8) > 150813-14:27:24,780 interface INFO: > stdout 2015-08-13T14:27:24.780131:Software version: 1.2.0.8 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:OpenCL C version: OpenCL C 1.2 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device extensions: cl_khr_icd > cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics > cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics > cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread > cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Global memory size in MB: 32054 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Size of largest memory object in > MB: 8013 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Global memory cache size in KB: 256 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Local memory size in KB: 32 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Constant memory size in KB: 128 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Parallel compute units: 8 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Clock frequency in MHz: 4000 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Max number of threads per block: > 8192 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Max number of threads in each > dimension: 8192 8192 8192 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131: > 150813-14:27:24,781 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform number: 1 > 150813-14:27:24,781 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform vendor: Advanced Micro > Devices, Inc. > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform name: AMD Accelerated > Parallel Processing > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform extentions: cl_khr_icd > cl_amd_event_callback cl_amd_offline_devices cl_amd_hsa > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Platform profile: FULL_PROFILE > 150813-14:27:24,781 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131: > 150813-14:27:24,781 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device number: 0 > 150813-14:27:24,781 interface INFO: > stdout > 2015-08-13T14:27:24.780131:--------------------------------------------- > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device vendor: GenuineIntel > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device name: Intel(R) Core(TM) > i7-4790K CPU @ 4.00GHz > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Hardware version: OpenCL 1.2 > AMD-APP (1445.5) > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Software version: 1445.5 (sse2,avx) > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:OpenCL C version: OpenCL C 1.2 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Device extensions: cl_khr_fp64 > cl_amd_fp64 cl_khr_global_int32_base_atomics > cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics > cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics > cl_khr_int64_extended_atomics cl_khr_3d_image_writes > cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission > cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops > cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_amd_svm cl_khr_gl_event > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Global memory size in MB: 32054 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Size of largest memory object in > MB: 8013 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Global memory cache size in KB: 32 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Local memory size in KB: 32 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Constant memory size in KB: 64 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Parallel compute units: 8 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Clock frequency in MHz: 4001 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Max number of threads per block: > 1024 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131:Max number of threads in each > dimension: 1024 1024 1024 > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131: > 150813-14:27:24,781 interface INFO: > stdout 2015-08-13T14:27:24.780131: > > > > > > > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 13 17:24:19 2015 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 13 Aug 2015 08:24:19 -0700 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: On Thu, Aug 13, 2015 at 8:06 AM, Jesus-Omar Ocegueda-Gonzalez < jomaroceguedag at gmail.com> wrote: > Hi guys!, =) > Ariel, in you example: > >> >>> transform_streamlines(transform_streamlines(transform_streamlines(sl, >>> affine), warp_field), np.linalg.inv(affine)) >>> >>> > in what coordinate system are the streamlines `sl` originally? are they in > the subject's image (voxel units) or in the subject's physical space (mm. > units)? I just would like to know what would be a typical use case for this. > Streamlines are often saved in the subject's physical space (in mm). For example, see these notebooks: https://github.com/arokem/AFQ-notebooks/blob/master/DTI-tracking.ipynb https://github.com/arokem/AFQ-notebooks/blob/master/AFQ-registration-callosum.ipynb Here, only a linear transform is applied to the streamlines, because we are warping a callosum ROI into the subject's mean B0 space, but we might want to go in the opposite direction as well, warping the streamlines to the original ROI space. By the way - do you have any insight as to why the callosum ROI in the latter notebook ends up with holes in it, when it is warped with the SyN warp field? > > -- > "Cada quien es due?o de lo que calla y esclavo de lo que dice" > -Proverbio chino. > "We all are owners of what we keep silent and slaves of what we say" > -Chinese proverb. > > http://www.cimat.mx/~omar > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomaroceguedag at gmail.com Thu Aug 13 18:40:52 2015 From: jomaroceguedag at gmail.com (Jesus-Omar Ocegueda-Gonzalez) Date: Thu, 13 Aug 2015 11:40:52 -0500 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: Nice examples!, thanks! =D The 'apparent' holes within the ROI maybe normal artifacts of the nearest neighbor interpolation (we are looking at just one slice, so I'm not sure if there are callosum labels in front and behind too). If it is an isolated hole within the warped ROI, and the original ROI had no holes, then I need to investigate what happened because the topology must not change. Unfortunately, I cannot run the full example because I don't have the 'tools' module. On Thu, Aug 13, 2015 at 10:24 AM, Ariel Rokem wrote: > > On Thu, Aug 13, 2015 at 8:06 AM, Jesus-Omar Ocegueda-Gonzalez < > jomaroceguedag at gmail.com> wrote: > >> Hi guys!, =) >> Ariel, in you example: >> >>> >>>> transform_streamlines(transform_streamlines(transform_streamlines(sl, >>>> affine), warp_field), np.linalg.inv(affine)) >>>> >>>> >> in what coordinate system are the streamlines `sl` originally? are they >> in the subject's image (voxel units) or in the subject's physical space >> (mm. units)? I just would like to know what would be a typical use case for >> this. >> > > Streamlines are often saved in the subject's physical space (in mm). For > example, see these notebooks: > > https://github.com/arokem/AFQ-notebooks/blob/master/DTI-tracking.ipynb > > https://github.com/arokem/AFQ-notebooks/blob/master/AFQ-registration-callosum.ipynb > > Here, only a linear transform is applied to the streamlines, because we > are warping a callosum ROI into the subject's mean B0 space, but we might > want to go in the opposite direction as well, warping the streamlines to > the original ROI space. > > By the way - do you have any insight as to why the callosum ROI in the > latter notebook ends up with holes in it, when it is warped with the SyN > warp field? > > > >> >> -- >> "Cada quien es due?o de lo que calla y esclavo de lo que dice" >> -Proverbio chino. >> "We all are owners of what we keep silent and slaves of what we say" >> -Chinese proverb. >> >> http://www.cimat.mx/~omar >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- "Cada quien es due?o de lo que calla y esclavo de lo que dice" -Proverbio chino. "We all are owners of what we keep silent and slaves of what we say" -Chinese proverb. http://www.cimat.mx/~omar -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 13 19:44:29 2015 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 13 Aug 2015 10:44:29 -0700 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: Message-ID: On Thu, Aug 13, 2015 at 9:40 AM, Jesus-Omar Ocegueda-Gonzalez < jomaroceguedag at gmail.com> wrote: > Nice examples!, thanks! =D > > The 'apparent' holes within the ROI maybe normal artifacts of the nearest > neighbor interpolation (we are looking at just one slice, so I'm not sure > if there are callosum labels in front and behind too). If it is an isolated > hole within the warped ROI, and the original ROI had no holes, then I need > to investigate what happened because the topology must not change. > Unfortunately, I cannot run the full example because I don't have the > 'tools' module. > One of those figures is a sum-projection through the volume. There really is a hole in the ROI (I also looked at it in 3D). The 'tools' module is a one-function file in that repository: https://github.com/arokem/AFQ-notebooks/blob/master/tools.py > > On Thu, Aug 13, 2015 at 10:24 AM, Ariel Rokem wrote: > >> >> On Thu, Aug 13, 2015 at 8:06 AM, Jesus-Omar Ocegueda-Gonzalez < >> jomaroceguedag at gmail.com> wrote: >> >>> Hi guys!, =) >>> Ariel, in you example: >>> >>>> >>>>> transform_streamlines(transform_streamlines(transform_streamlines(sl, >>>>> affine), warp_field), np.linalg.inv(affine)) >>>>> >>>>> >>> in what coordinate system are the streamlines `sl` originally? are they >>> in the subject's image (voxel units) or in the subject's physical space >>> (mm. units)? I just would like to know what would be a typical use case for >>> this. >>> >> >> Streamlines are often saved in the subject's physical space (in mm). For >> example, see these notebooks: >> >> https://github.com/arokem/AFQ-notebooks/blob/master/DTI-tracking.ipynb >> >> https://github.com/arokem/AFQ-notebooks/blob/master/AFQ-registration-callosum.ipynb >> >> Here, only a linear transform is applied to the streamlines, because we >> are warping a callosum ROI into the subject's mean B0 space, but we might >> want to go in the opposite direction as well, warping the streamlines to >> the original ROI space. >> >> By the way - do you have any insight as to why the callosum ROI in the >> latter notebook ends up with holes in it, when it is warped with the SyN >> warp field? >> >> >> >>> >>> -- >>> "Cada quien es due?o de lo que calla y esclavo de lo que dice" >>> -Proverbio chino. >>> "We all are owners of what we keep silent and slaves of what we say" >>> -Chinese proverb. >>> >>> http://www.cimat.mx/~omar >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > "Cada quien es due?o de lo que calla y esclavo de lo que dice" > -Proverbio chino. > "We all are owners of what we keep silent and slaves of what we say" > -Chinese proverb. > > http://www.cimat.mx/~omar > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.eklund at liu.se Fri Aug 14 10:38:48 2015 From: anders.eklund at liu.se (Anders Eklund) Date: Fri, 14 Aug 2015 08:38:48 +0000 Subject: [Neuroimaging] [nipype] Detecting OpenCL devices In-Reply-To: References: <0D019718FD434B40866268B9AB17E71859F33E@MB3-2010.ad.liu.se>, Message-ID: <0D019718FD434B40866268B9AB17E7185A589A@MB1-2010.ad.liu.se> Hi Satra, I tested on another machine with an Nvidia GPU and then everything works as expected, strange. I have wrapped one BROCCOLI function so far. Since I'm a beginner in Python, I'm not sure if I have done everything correctly (I started by copying the wrappers for FSL). Should I make a pull request for that function first, and let you look at it, before I continue with the other functions? - Anders ________________________________ Fr?n: Neuroimaging [neuroimaging-bounces+anders.eklund=liu.se at python.org] f?r Satrajit Ghosh [satra at mit.edu] Skickat: den 13 augusti 2015 17:12 Till: Neuroimaging analysis in Python ?mne: Re: [Neuroimaging] [nipype] Detecting OpenCL devices hi anders, that is a little strange. perhaps you could mimic the nipype call. https://github.com/nipy/nipype/blob/master/nipype/interfaces/base.py#L1211 i suspect it may have something to do with either environment variables or shell=True cheers, satra On Thu, Aug 13, 2015 at 8:33 AM, Anders Eklund > wrote: Hello, I'm working on adding BROCCOLI functions to the nipype interface. I have managed to run a BROCCOLI function through nipype, but I discovered that all my OpenCL devices are not available (for those of you unfamiliar with BROCCOLI, it is a software for fMRI analysis, it is written in OpenCL (open computing language), which makes it possible to run the same code in parallel on CPUs, AMD GPUs and Nvidia GPUs, see https://github.com/wanderine/BROCCOLI). I have a C function called GetOpenCL info, which prints information about all OpenCL devices on a machine. If I call it using subprocess it looks like this, detecting an Intel CPU and an AMD GPU >>> import subprocess >>> subprocess.call("GetOpenCLInfo") Device info --------------------------------------------- Platform number: 0 --------------------------------------------- Platform vendor: Intel(R) Corporation Platform name: Intel(R) OpenCL Platform extentions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 Platform profile: FULL_PROFILE --------------------------------------------- --------------------------------------------- Device number: 0 --------------------------------------------- Device vendor: Intel(R) Corporation Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz Hardware version: OpenCL 1.2 (Build 8) Software version: 1.2.0.8 OpenCL C version: OpenCL C 1.2 Device extensions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 Global memory size in MB: 32054 Size of largest memory object in MB: 8013 Global memory cache size in KB: 256 Local memory size in KB: 32 Constant memory size in KB: 128 Parallel compute units: 8 Clock frequency in MHz: 4000 Max number of threads per block: 8192 Max number of threads in each dimension: 8192 8192 8192 --------------------------------------------- Platform number: 1 --------------------------------------------- Platform vendor: Advanced Micro Devices, Inc. Platform name: AMD Accelerated Parallel Processing Platform extentions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices cl_amd_hsa Platform profile: FULL_PROFILE --------------------------------------------- --------------------------------------------- Device number: 0 --------------------------------------------- Device vendor: Advanced Micro Devices, Inc. Device name: Hawaii Hardware version: OpenCL 1.2 AMD-APP (1445.5) Software version: 1445.5 (VM) OpenCL C version: OpenCL C 1.2 Device extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event Global memory size in MB: 3072 Size of largest memory object in MB: 1024 Global memory cache size in KB: 16 Local memory size in KB: 32 Constant memory size in KB: 64 Parallel compute units: 44 Clock frequency in MHz: 1030 Max number of threads per block: 256 Max number of threads in each dimension: 256 256 256 --------------------------------------------- Device number: 1 --------------------------------------------- Device vendor: GenuineIntel Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz Hardware version: OpenCL 1.2 AMD-APP (1445.5) Software version: 1445.5 (sse2,avx) OpenCL C version: OpenCL C 1.2 Device extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_amd_svm cl_khr_gl_event Global memory size in MB: 32054 Size of largest memory object in MB: 8013 Global memory cache size in KB: 32 Local memory size in KB: 32 Constant memory size in KB: 64 Parallel compute units: 8 Clock frequency in MHz: 4001 Max number of threads per block: 1024 Max number of threads in each dimension: 1024 1024 1024 However, if I call the same function through nipype (using exactly the same GetOpenCL function), it looks like this, i.e. not detecting the AMD GPU. I'm a total beginner in Python, so can anyone tell me what the difference is between subprocess and how nipype actually calls the functions? >>> import nipype >>> import nipype.interfaces.broccoli as broccoli >>> info = broccoli.GetOpenCLInfo() >>> info.run() 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Device info 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform number: 0 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform vendor: Intel(R) Corporation 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform name: Intel(R) OpenCL 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform extentions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform profile: FULL_PROFILE 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Device number: 0 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Device vendor: Intel(R) Corporation 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Hardware version: OpenCL 1.2 (Build 8) 150813-14:27:24,780 interface INFO: stdout 2015-08-13T14:27:24.780131:Software version: 1.2.0.8 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:OpenCL C version: OpenCL C 1.2 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device extensions: cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Global memory size in MB: 32054 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Size of largest memory object in MB: 8013 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Global memory cache size in KB: 256 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Local memory size in KB: 32 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Constant memory size in KB: 128 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Parallel compute units: 8 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Clock frequency in MHz: 4000 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Max number of threads per block: 8192 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Max number of threads in each dimension: 8192 8192 8192 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform number: 1 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform vendor: Advanced Micro Devices, Inc. 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform name: AMD Accelerated Parallel Processing 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform extentions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices cl_amd_hsa 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Platform profile: FULL_PROFILE 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device number: 0 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:--------------------------------------------- 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device vendor: GenuineIntel 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Hardware version: OpenCL 1.2 AMD-APP (1445.5) 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Software version: 1445.5 (sse2,avx) 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:OpenCL C version: OpenCL C 1.2 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Device extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_amd_svm cl_khr_gl_event 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Global memory size in MB: 32054 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Size of largest memory object in MB: 8013 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Global memory cache size in KB: 32 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Local memory size in KB: 32 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Constant memory size in KB: 64 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Parallel compute units: 8 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Clock frequency in MHz: 4001 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Max number of threads per block: 1024 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131:Max number of threads in each dimension: 1024 1024 1024 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131: 150813-14:27:24,781 interface INFO: stdout 2015-08-13T14:27:24.780131: _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Fri Aug 14 15:37:35 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Fri, 14 Aug 2015 09:37:35 -0400 Subject: [Neuroimaging] [nipype] Detecting OpenCL devices In-Reply-To: <0D019718FD434B40866268B9AB17E7185A589A@MB1-2010.ad.liu.se> References: <0D019718FD434B40866268B9AB17E71859F33E@MB3-2010.ad.liu.se> <0D019718FD434B40866268B9AB17E7185A589A@MB1-2010.ad.liu.se> Message-ID: > > I tested on another machine with an Nvidia GPU and then everything works > as expected, strange. > great! > I have wrapped one BROCCOLI function so far. Since I'm a beginner in > Python, I'm not sure if I have done everything correctly (I started by > copying the wrappers for FSL). Should I make a pull request for that > function first, and let you look at it, before I continue with the other > functions? > yes, please do send a pull-request, and we can discuss issues and changes on the PR. cheers, satra > *Fr?n:* Neuroimaging [neuroimaging-bounces+anders.eklund=liu.se at python.org] > f?r Satrajit Ghosh [satra at mit.edu] > *Skickat:* den 13 augusti 2015 17:12 > *Till:* Neuroimaging analysis in Python > *?mne:* Re: [Neuroimaging] [nipype] Detecting OpenCL devices > > hi anders, > > that is a little strange. perhaps you could mimic the nipype call. > > https://github.com/nipy/nipype/blob/master/nipype/interfaces/base.py#L1211 > > i suspect it may have something to do with either environment variables or > shell=True > > cheers, > > satra > > On Thu, Aug 13, 2015 at 8:33 AM, Anders Eklund > wrote: > >> Hello, >> >> I'm working on adding BROCCOLI functions to the nipype interface. I have >> managed to run a BROCCOLI function through nipype, but I discovered that >> all my OpenCL devices are not available (for those of you unfamiliar with >> BROCCOLI, it is a software for fMRI analysis, it is written in OpenCL (open >> computing language), which makes it possible to run the same code in >> parallel on CPUs, AMD GPUs and Nvidia GPUs, see >> https://github.com/wanderine/BROCCOLI). >> >> I have a C function called GetOpenCL info, which prints information about >> all OpenCL devices on a machine. If I call it using subprocess it looks >> like this, detecting an Intel CPU and an AMD GPU >> >> >> >>> import subprocess >> >>> subprocess.call("GetOpenCLInfo") >> >> Device info >> >> --------------------------------------------- >> Platform number: 0 >> --------------------------------------------- >> Platform vendor: Intel(R) Corporation >> Platform name: Intel(R) OpenCL >> Platform extentions: cl_khr_icd cl_khr_global_int32_base_atomics >> cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics >> cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store >> cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images >> cl_khr_3d_image_writes cl_khr_fp64 >> Platform profile: FULL_PROFILE >> --------------------------------------------- >> >> --------------------------------------------- >> Device number: 0 >> --------------------------------------------- >> Device vendor: Intel(R) Corporation >> Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz >> Hardware version: OpenCL 1.2 (Build 8) >> Software version: 1.2.0.8 >> OpenCL C version: OpenCL C 1.2 >> Device extensions: cl_khr_icd cl_khr_global_int32_base_atomics >> cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics >> cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store >> cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images >> cl_khr_3d_image_writes cl_khr_fp64 >> Global memory size in MB: 32054 >> Size of largest memory object in MB: 8013 >> Global memory cache size in KB: 256 >> Local memory size in KB: 32 >> Constant memory size in KB: 128 >> Parallel compute units: 8 >> Clock frequency in MHz: 4000 >> Max number of threads per block: 8192 >> Max number of threads in each dimension: 8192 8192 8192 >> >> --------------------------------------------- >> Platform number: 1 >> --------------------------------------------- >> Platform vendor: Advanced Micro Devices, Inc. >> Platform name: AMD Accelerated Parallel Processing >> Platform extentions: cl_khr_icd cl_amd_event_callback >> cl_amd_offline_devices cl_amd_hsa >> Platform profile: FULL_PROFILE >> --------------------------------------------- >> >> --------------------------------------------- >> Device number: 0 >> --------------------------------------------- >> Device vendor: Advanced Micro Devices, Inc. >> Device name: Hawaii >> Hardware version: OpenCL 1.2 AMD-APP (1445.5) >> Software version: 1445.5 (VM) >> OpenCL C version: OpenCL C 1.2 >> Device extensions: cl_khr_fp64 cl_amd_fp64 >> cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics >> cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics >> cl_khr_int64_base_atomics cl_khr_int64_extended_atomics >> cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing >> cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 >> cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt >> cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event >> Global memory size in MB: 3072 >> Size of largest memory object in MB: 1024 >> Global memory cache size in KB: 16 >> Local memory size in KB: 32 >> Constant memory size in KB: 64 >> Parallel compute units: 44 >> Clock frequency in MHz: 1030 >> Max number of threads per block: 256 >> Max number of threads in each dimension: 256 256 256 >> >> --------------------------------------------- >> Device number: 1 >> --------------------------------------------- >> Device vendor: GenuineIntel >> Device name: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz >> Hardware version: OpenCL 1.2 AMD-APP (1445.5) >> Software version: 1445.5 (sse2,avx) >> OpenCL C version: OpenCL C 1.2 >> Device extensions: cl_khr_fp64 cl_amd_fp64 >> cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics >> cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics >> cl_khr_int64_base_atomics cl_khr_int64_extended_atomics >> cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing >> cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 >> cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir >> cl_amd_svm cl_khr_gl_event >> Global memory size in MB: 32054 >> Size of largest memory object in MB: 8013 >> Global memory cache size in KB: 32 >> Local memory size in KB: 32 >> Constant memory size in KB: 64 >> Parallel compute units: 8 >> Clock frequency in MHz: 4001 >> Max number of threads per block: 1024 >> Max number of threads in each dimension: 1024 1024 1024 >> >> >> >> >> >> >> >> However, if I call the same function through nipype (using exactly the >> same GetOpenCL function), it looks like this, i.e. not detecting the AMD >> GPU. I'm a total beginner in Python, so can anyone tell me what the >> difference is between subprocess and how nipype actually calls the >> functions? >> >> >> >> >>> import nipype >> >>> import nipype.interfaces.broccoli as broccoli >> >>> info = broccoli.GetOpenCLInfo() >> >>> info.run() >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131: >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device info >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131: >> 150813-14:27:24,780 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform number: 0 >> 150813-14:27:24,780 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform vendor: Intel(R) >> Corporation >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform name: Intel(R) OpenCL >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform extentions: cl_khr_icd >> cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics >> cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics >> cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread >> cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform profile: FULL_PROFILE >> 150813-14:27:24,780 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131: >> 150813-14:27:24,780 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device number: 0 >> 150813-14:27:24,780 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device vendor: Intel(R) Corporation >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device name: Intel(R) Core(TM) >> i7-4790K CPU @ 4.00GHz >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Hardware version: OpenCL 1.2 >> (Build 8) >> 150813-14:27:24,780 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Software version: 1.2.0.8 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:OpenCL C version: OpenCL C 1.2 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device extensions: cl_khr_icd >> cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics >> cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics >> cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread >> cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Global memory size in MB: 32054 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Size of largest memory object in >> MB: 8013 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Global memory cache size in KB: 256 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Local memory size in KB: 32 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Constant memory size in KB: 128 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Parallel compute units: 8 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Clock frequency in MHz: 4000 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Max number of threads per block: >> 8192 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Max number of threads in each >> dimension: 8192 8192 8192 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131: >> 150813-14:27:24,781 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform number: 1 >> 150813-14:27:24,781 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform vendor: Advanced Micro >> Devices, Inc. >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform name: AMD Accelerated >> Parallel Processing >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform extentions: cl_khr_icd >> cl_amd_event_callback cl_amd_offline_devices cl_amd_hsa >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Platform profile: FULL_PROFILE >> 150813-14:27:24,781 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131: >> 150813-14:27:24,781 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device number: 0 >> 150813-14:27:24,781 interface INFO: >> stdout >> 2015-08-13T14:27:24.780131:--------------------------------------------- >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device vendor: GenuineIntel >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device name: Intel(R) Core(TM) >> i7-4790K CPU @ 4.00GHz >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Hardware version: OpenCL 1.2 >> AMD-APP (1445.5) >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Software version: 1445.5 (sse2,avx) >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:OpenCL C version: OpenCL C 1.2 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Device extensions: cl_khr_fp64 >> cl_amd_fp64 cl_khr_global_int32_base_atomics >> cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics >> cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics >> cl_khr_int64_extended_atomics cl_khr_3d_image_writes >> cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission >> cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops >> cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_amd_svm cl_khr_gl_event >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Global memory size in MB: 32054 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Size of largest memory object in >> MB: 8013 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Global memory cache size in KB: 32 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Local memory size in KB: 32 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Constant memory size in KB: 64 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Parallel compute units: 8 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Clock frequency in MHz: 4001 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Max number of threads per block: >> 1024 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131:Max number of threads in each >> dimension: 1024 1024 1024 >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131: >> 150813-14:27:24,781 interface INFO: >> stdout 2015-08-13T14:27:24.780131: >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pellman.john at gmail.com Fri Aug 14 16:01:33 2015 From: pellman.john at gmail.com (John Pellman) Date: Fri, 14 Aug 2015 10:01:33 -0400 Subject: [Neuroimaging] Inventory of wrapped commands in nipype? Message-ID: Out of curiosity, is there a document out there that notes which commands for AFNI,FSL,etc have been wrapped into Nipype and which have not? I know that there are quite a few AFNI commands that can't be used with nipype just yet (e.g., 3dToutcount), and it might be useful to know which ones are and aren't available (and also, if they won't be wrapped and why). Best, John Pellman -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Fri Aug 14 17:17:43 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Fri, 14 Aug 2015 11:17:43 -0400 Subject: [Neuroimaging] Inventory of wrapped commands in nipype? In-Reply-To: References: Message-ID: hi john, Out of curiosity, is there a document out there that notes which commands > for AFNI,FSL,etc have been wrapped into Nipype and which have not? > there is no explicit function to list this, but the following example command will generate the info if you are in the nipype/nipype source directory: $ grep -r "_cmd = " interfaces/afni/ > I know that there are quite a few AFNI commands that can't be used with > nipype just yet (e.g., 3dToutcount), and it might be useful to know which > ones are and aren't available (and also, if they won't be wrapped and why). > wrapping has always been a function of user need/contribution. for example, freesurfer has over 700 binaries - not all are useful or needed. so anytime something is missing we ask that people contribute it if they need a wrapper for it. we are also moving towards a system where software providers themselves expose the binary using a standard architecture (e.g., slicer, brainstools use XML, cbrain has something called boutiques, and then there is recent effort towards a common workflow language specification), and then these get automatically wrapped for nipype. cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Fri Aug 14 17:27:32 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Fri, 14 Aug 2015 08:27:32 -0700 Subject: [Neuroimaging] Inventory of wrapped commands in nipype? In-Reply-To: References: Message-ID: Would the documentation-generating scripts allow snippets of Python code to list the wrapped functions/binaries for each project (or indicate that all are wrapped, if automatic)? I'm guessing nipype uses Sphinx; I don't know the system, but I guess this wouldn't be too hard. Seems extremely useful to me. If possible and not too tough, I'd be happy to open a github issue and look at contributing it. On Fri, Aug 14, 2015 at 8:17 AM, Satrajit Ghosh wrote: > hi john, > > Out of curiosity, is there a document out there that notes which commands >> for AFNI,FSL,etc have been wrapped into Nipype and which have not? >> > > there is no explicit function to list this, but the following example > command will generate the info if you are in the nipype/nipype source > directory: > > $ grep -r "_cmd = " interfaces/afni/ > >> I know that there are quite a few AFNI commands that can't be used with >> nipype just yet (e.g., 3dToutcount), and it might be useful to know which >> ones are and aren't available (and also, if they won't be wrapped and why). >> > > wrapping has always been a function of user need/contribution. for > example, freesurfer has over 700 binaries - not all are useful or needed. > so anytime something is missing we ask that people contribute it if they > need a wrapper for it. we are also moving towards a system where software > providers themselves expose the binary using a standard architecture (e.g., > slicer, brainstools use XML, cbrain has something called boutiques, and > then there is recent effort towards a common workflow language > specification), and then these get automatically wrapped for nipype. > > cheers, > > satra > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Fri Aug 14 17:36:07 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Fri, 14 Aug 2015 11:36:07 -0400 Subject: [Neuroimaging] Inventory of wrapped commands in nipype? In-Reply-To: References: Message-ID: hi ben, an issue + contribution would be much welcome! it wouldn't be too hard to do this, as we already have scripts that traverse all interfaces. in fact it would be nice to even create a reverse mapping from underlying command to nipype interface(s) name (in some cases there is a many nipype interfaces to single command mapping - e.g., fslmaths). cheers, satra On Fri, Aug 14, 2015 at 11:27 AM, Ben Cipollini wrote: > Would the documentation-generating scripts allow snippets of Python code > to list the wrapped functions/binaries for each project (or indicate that > all are wrapped, if automatic)? > > I'm guessing nipype uses Sphinx; I don't know the system, but I guess this > wouldn't be too hard. Seems extremely useful to me. > > If possible and not too tough, I'd be happy to open a github issue and > look at contributing it. > > On Fri, Aug 14, 2015 at 8:17 AM, Satrajit Ghosh wrote: > >> hi john, >> >> Out of curiosity, is there a document out there that notes which commands >>> for AFNI,FSL,etc have been wrapped into Nipype and which have not? >>> >> >> there is no explicit function to list this, but the following example >> command will generate the info if you are in the nipype/nipype source >> directory: >> >> $ grep -r "_cmd = " interfaces/afni/ >> >>> I know that there are quite a few AFNI commands that can't be used with >>> nipype just yet (e.g., 3dToutcount), and it might be useful to know which >>> ones are and aren't available (and also, if they won't be wrapped and why). >>> >> >> wrapping has always been a function of user need/contribution. for >> example, freesurfer has over 700 binaries - not all are useful or needed. >> so anytime something is missing we ask that people contribute it if they >> need a wrapper for it. we are also moving towards a system where software >> providers themselves expose the binary using a standard architecture (e.g., >> slicer, brainstools use XML, cbrain has something called boutiques, and >> then there is recent effort towards a common workflow language >> specification), and then these get automatically wrapped for nipype. >> >> cheers, >> >> satra >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Fri Aug 14 17:54:36 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Fri, 14 Aug 2015 08:54:36 -0700 Subject: [Neuroimaging] Inventory of wrapped commands in nipype? In-Reply-To: References: Message-ID: Keep me in the loop on this! I'm interested in the functions that different programs have - in case it's useful I created a data structure for FSL , and am just starting one for SPM (right now it's just a list). Nipype / nilearn etc are much more dynamic, so it would good to generate something like this programatically. On Fri, Aug 14, 2015 at 8:36 AM, Satrajit Ghosh wrote: > hi ben, > > an issue + contribution would be much welcome! > > it wouldn't be too hard to do this, as we already have scripts that > traverse all interfaces. in fact it would be nice to even create a reverse > mapping from underlying command to nipype interface(s) name (in some cases > there is a many nipype interfaces to single command mapping - e.g., > fslmaths). > > cheers, > > satra > > On Fri, Aug 14, 2015 at 11:27 AM, Ben Cipollini wrote: > >> Would the documentation-generating scripts allow snippets of Python code >> to list the wrapped functions/binaries for each project (or indicate that >> all are wrapped, if automatic)? >> >> I'm guessing nipype uses Sphinx; I don't know the system, but I guess >> this wouldn't be too hard. Seems extremely useful to me. >> >> If possible and not too tough, I'd be happy to open a github issue and >> look at contributing it. >> >> On Fri, Aug 14, 2015 at 8:17 AM, Satrajit Ghosh wrote: >> >>> hi john, >>> >>> Out of curiosity, is there a document out there that notes which >>>> commands for AFNI,FSL,etc have been wrapped into Nipype and which have >>>> not? >>>> >>> >>> there is no explicit function to list this, but the following example >>> command will generate the info if you are in the nipype/nipype source >>> directory: >>> >>> $ grep -r "_cmd = " interfaces/afni/ >>> >>>> I know that there are quite a few AFNI commands that can't be used with >>>> nipype just yet (e.g., 3dToutcount), and it might be useful to know which >>>> ones are and aren't available (and also, if they won't be wrapped and why). >>>> >>> >>> wrapping has always been a function of user need/contribution. for >>> example, freesurfer has over 700 binaries - not all are useful or needed. >>> so anytime something is missing we ask that people contribute it if they >>> need a wrapper for it. we are also moving towards a system where software >>> providers themselves expose the binary using a standard architecture (e.g., >>> slicer, brainstools use XML, cbrain has something called boutiques, and >>> then there is recent effort towards a common workflow language >>> specification), and then these get automatically wrapped for nipype. >>> >>> cheers, >>> >>> satra >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Fri Aug 14 18:32:02 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Fri, 14 Aug 2015 09:32:02 -0700 Subject: [Neuroimaging] Inventory of wrapped commands in nipype? In-Reply-To: References: Message-ID: https://github.com/nipy/nipype/issues/1186 Feel free to add comments or contribute! On Fri, Aug 14, 2015 at 8:54 AM, vanessa sochat wrote: > Keep me in the loop on this! I'm interested in the functions that > different programs have - in case it's useful I created a data structure > for FSL , > and am just starting one for SPM > (right > now it's just a list). Nipype / nilearn etc are much more dynamic, so it > would good to generate something like this programatically. > > On Fri, Aug 14, 2015 at 8:36 AM, Satrajit Ghosh wrote: > >> hi ben, >> >> an issue + contribution would be much welcome! >> >> it wouldn't be too hard to do this, as we already have scripts that >> traverse all interfaces. in fact it would be nice to even create a reverse >> mapping from underlying command to nipype interface(s) name (in some cases >> there is a many nipype interfaces to single command mapping - e.g., >> fslmaths). >> >> cheers, >> >> satra >> >> On Fri, Aug 14, 2015 at 11:27 AM, Ben Cipollini >> wrote: >> >>> Would the documentation-generating scripts allow snippets of Python code >>> to list the wrapped functions/binaries for each project (or indicate that >>> all are wrapped, if automatic)? >>> >>> I'm guessing nipype uses Sphinx; I don't know the system, but I guess >>> this wouldn't be too hard. Seems extremely useful to me. >>> >>> If possible and not too tough, I'd be happy to open a github issue and >>> look at contributing it. >>> >>> On Fri, Aug 14, 2015 at 8:17 AM, Satrajit Ghosh wrote: >>> >>>> hi john, >>>> >>>> Out of curiosity, is there a document out there that notes which >>>>> commands for AFNI,FSL,etc have been wrapped into Nipype and which have >>>>> not? >>>>> >>>> >>>> there is no explicit function to list this, but the following example >>>> command will generate the info if you are in the nipype/nipype source >>>> directory: >>>> >>>> $ grep -r "_cmd = " interfaces/afni/ >>>> >>>>> I know that there are quite a few AFNI commands that can't be used >>>>> with nipype just yet (e.g., 3dToutcount), and it might be useful to know >>>>> which ones are and aren't available (and also, if they won't be wrapped and >>>>> why). >>>>> >>>> >>>> wrapping has always been a function of user need/contribution. for >>>> example, freesurfer has over 700 binaries - not all are useful or needed. >>>> so anytime something is missing we ask that people contribute it if they >>>> need a wrapper for it. we are also moving towards a system where software >>>> providers themselves expose the binary using a standard architecture (e.g., >>>> slicer, brainstools use XML, cbrain has something called boutiques, and >>>> then there is recent effort towards a common workflow language >>>> specification), and then these get automatically wrapped for nipype. >>>> >>>> cheers, >>>> >>>> satra >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 17 00:18:03 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sun, 16 Aug 2015 15:18:03 -0700 Subject: [Neuroimaging] Website Update Message-ID: Hi Everyone, Here is an update to the site. I've ported it into jekyll , and tested the template on iphone and computer (seems reasonable). I've also gotten it to render the artifacts on circle.ci , so we could preview PRs (Click "artifact" and then find home.html ). However, I've run into a bug with regard to absolute vs. relative paths - when you click the demo link above, the "posts" not being at the base url means they will not be linked or render correctly (for example, here is a link to a post on circle, and you won't see styling because the css/js links are broken) The site works perfectly given that we aren't serving it at a relative path, eg: jekyll serve --baseurl="/" And the challenge is finding a solution that will render locally, on github pages, and circle.ci, and what we need, I think, is some kind of liquid syntax that will detect when we are in a subfolder and render appropriately. I've been messing around with it for 7 hours today and can't figure it out, and I need to ask for help. Could someone else take a look? Likely someone with more experience than me with Jekyll could figure this out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would be to figure out this bug, get it onto a (test) github pages, tweak the details of the content, make proper documentation, and then release to official github pages. Best, Vanessa -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 17 06:46:05 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sun, 16 Aug 2015 21:46:05 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: I'm not completely convinced that an interactive sidebar-thing is really that useful, but it does work nicely on mobile. And for the structure of the actual pages for each package, something simple with smaller font and a clean sidebar with a link tree would be easiest to navigate, akin to sphinx. We possibly will try all these packages only to converge onto the simplest form and functionality (something like sphinx?) That would be terribly funny and pathetic at the same time, but at least we can be confident about robustly investigating options! I'm interested to hear what others think, of course on Monday. I'll keep thinking about this. On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat wrote: > Hi Everyone, > > Here is an update to the site. I've ported it into jekyll > , and tested the template on iphone > and computer (seems reasonable). I've also gotten it to render the > artifacts on circle.ci , so > we could preview PRs (Click "artifact" and then find home.html > ). > However, I've run into a bug with regard to absolute vs. relative paths - > when you click the demo link above, the "posts" not being at the base url > means they will not be linked or render correctly (for example, here is a > link > > to a post on circle, and you won't see styling because the css/js links are > broken) > > The site works perfectly given that we aren't serving it at a relative > path, eg: > > jekyll serve --baseurl="/" > > And the challenge is finding a solution that will render locally, on > github pages, and circle.ci, and what we need, I think, is some kind of > liquid syntax that will detect when we are in a subfolder and render > appropriately. I've been messing around with it for 7 hours today and can't > figure it out, and I need to ask for help. Could someone else take a look? > Likely someone with more experience than me with Jekyll could figure this > out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would > be to figure out this bug, get it onto a (test) github pages, tweak the > details of the content, make proper documentation, and then release to > official github pages. > > Best, > > Vanessa > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.alexandre at gmail.com Mon Aug 17 11:23:49 2015 From: abraham.alexandre at gmail.com (Alexandre ABRAHAM) Date: Mon, 17 Aug 2015 11:23:49 +0200 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Hi Vanessa, This looks good, maybe a little dry, but good. However, I don't get the small balls at the top right, what do they represent? Alex. On Mon, Aug 17, 2015 at 6:46 AM, vanessa sochat wrote: > I'm not completely convinced that an interactive sidebar-thing is really > that useful, but it does work nicely on mobile. And for the structure of > the actual pages for each package, something simple with smaller font and a > clean sidebar with a link tree would be easiest to navigate, akin to > sphinx. We possibly will try all these packages only to converge onto the > simplest form and functionality (something like sphinx?) That would be > terribly funny and pathetic at the same time, but at least we can be > confident about robustly investigating options! I'm interested to hear what > others think, of course on Monday. I'll keep thinking about this. > > On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat > wrote: > >> Hi Everyone, >> >> Here is an update to the site. I've ported it into jekyll >> , and tested the template on >> iphone and computer (seems reasonable). I've also gotten it to render the >> artifacts on circle.ci , >> so we could preview PRs (Click "artifact" and then find home.html >> ). >> However, I've run into a bug with regard to absolute vs. relative paths - >> when you click the demo link above, the "posts" not being at the base url >> means they will not be linked or render correctly (for example, here is >> a link >> >> to a post on circle, and you won't see styling because the css/js links are >> broken) >> >> The site works perfectly given that we aren't serving it at a relative >> path, eg: >> >> jekyll serve --baseurl="/" >> >> And the challenge is finding a solution that will render locally, on >> github pages, and circle.ci, and what we need, I think, is some kind of >> liquid syntax that will detect when we are in a subfolder and render >> appropriately. I've been messing around with it for 7 hours today and can't >> figure it out, and I need to ask for help. Could someone else take a look? >> Likely someone with more experience than me with Jekyll could figure this >> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >> be to figure out this bug, get it onto a (test) github pages, tweak the >> details of the content, make proper documentation, and then release to >> official github pages. >> >> Best, >> >> Vanessa >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 17 13:10:09 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Mon, 17 Aug 2015 04:10:09 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Those are the snakey thoughts! It's just a fun detail - when you mouse over they correspond to the packages, and you can click on them, and the graphic is produced dynamically from the data. Do you see the snake logo? On Mon, Aug 17, 2015 at 2:23 AM, Alexandre ABRAHAM < abraham.alexandre at gmail.com> wrote: > Hi Vanessa, > > This looks good, maybe a little dry, but good. However, I don't get the > small balls at the top right, what do they represent? > > Alex. > > On Mon, Aug 17, 2015 at 6:46 AM, vanessa sochat > wrote: > >> I'm not completely convinced that an interactive sidebar-thing is really >> that useful, but it does work nicely on mobile. And for the structure of >> the actual pages for each package, something simple with smaller font and a >> clean sidebar with a link tree would be easiest to navigate, akin to >> sphinx. We possibly will try all these packages only to converge onto the >> simplest form and functionality (something like sphinx?) That would be >> terribly funny and pathetic at the same time, but at least we can be >> confident about robustly investigating options! I'm interested to hear what >> others think, of course on Monday. I'll keep thinking about this. >> >> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >> wrote: >> >>> Hi Everyone, >>> >>> Here is an update to the site. I've ported it into jekyll >>> , and tested the template on >>> iphone and computer (seems reasonable). I've also gotten it to render the >>> artifacts on circle.ci , >>> so we could preview PRs (Click "artifact" and then find home.html >>> ). >>> However, I've run into a bug with regard to absolute vs. relative paths - >>> when you click the demo link above, the "posts" not being at the base url >>> means they will not be linked or render correctly (for example, here is >>> a link >>> >>> to a post on circle, and you won't see styling because the css/js links are >>> broken) >>> >>> The site works perfectly given that we aren't serving it at a relative >>> path, eg: >>> >>> jekyll serve --baseurl="/" >>> >>> And the challenge is finding a solution that will render locally, on >>> github pages, and circle.ci, and what we need, I think, is some kind of >>> liquid syntax that will detect when we are in a subfolder and render >>> appropriately. I've been messing around with it for 7 hours today and can't >>> figure it out, and I need to ask for help. Could someone else take a look? >>> Likely someone with more experience than me with Jekyll could figure this >>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>> be to figure out this bug, get it onto a (test) github pages, tweak the >>> details of the content, make proper documentation, and then release to >>> official github pages. >>> >>> Best, >>> >>> Vanessa >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.alexandre at gmail.com Mon Aug 17 13:56:17 2015 From: abraham.alexandre at gmail.com (Alexandre ABRAHAM) Date: Mon, 17 Aug 2015 13:56:17 +0200 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: > Those are the snakey thoughts! > Oh, OK. > It's just a fun detail - when you mouse over they correspond to the > packages, and you can click on them, and the graphic is produced > dynamically from the data. > Yes, I've seen that. But I guess that ball sizes and colors are random? Something like a wordcloud seems more useful to me. > Do you see the snake logo? > BTW, the rendering is weird on a big screen: the balls are really far from the snake. > > On Mon, Aug 17, 2015 at 2:23 AM, Alexandre ABRAHAM < > abraham.alexandre at gmail.com> wrote: > >> Hi Vanessa, >> >> This looks good, maybe a little dry, but good. However, I don't get the >> small balls at the top right, what do they represent? >> >> Alex. >> >> On Mon, Aug 17, 2015 at 6:46 AM, vanessa sochat >> wrote: >> >>> I'm not completely convinced that an interactive sidebar-thing is really >>> that useful, but it does work nicely on mobile. And for the structure of >>> the actual pages for each package, something simple with smaller font and a >>> clean sidebar with a link tree would be easiest to navigate, akin to >>> sphinx. We possibly will try all these packages only to converge onto the >>> simplest form and functionality (something like sphinx?) That would be >>> terribly funny and pathetic at the same time, but at least we can be >>> confident about robustly investigating options! I'm interested to hear what >>> others think, of course on Monday. I'll keep thinking about this. >>> >>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>> wrote: >>> >>>> Hi Everyone, >>>> >>>> Here is an update to the site. I've ported it into jekyll >>>> , and tested the template on >>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>> artifacts on circle.ci , >>>> so we could preview PRs (Click "artifact" and then find home.html >>>> ). >>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>> when you click the demo link above, the "posts" not being at the base url >>>> means they will not be linked or render correctly (for example, here >>>> is a link >>>> >>>> to a post on circle, and you won't see styling because the css/js links are >>>> broken) >>>> >>>> The site works perfectly given that we aren't serving it at a relative >>>> path, eg: >>>> >>>> jekyll serve --baseurl="/" >>>> >>>> And the challenge is finding a solution that will render locally, on >>>> github pages, and circle.ci, and what we need, I think, is some kind >>>> of liquid syntax that will detect when we are in a subfolder and render >>>> appropriately. I've been messing around with it for 7 hours today and can't >>>> figure it out, and I need to ask for help. Could someone else take a look? >>>> Likely someone with more experience than me with Jekyll could figure this >>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>> details of the content, make proper documentation, and then release to >>>> official github pages. >>>> >>>> Best, >>>> >>>> Vanessa >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 17 16:02:34 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Mon, 17 Aug 2015 07:02:34 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Getting the packages to render dynamically in multiple places from data objects and the design itself, whether we are in flask, jekyll, or something else, is non-trivial, however we must first focus on our implementation strategy - namely that it satisfies: - preview via continuous integration - easy development workflow - deployment to github pages With the current, we are close, and the issue at hand is rendering paths on pages that are not at the root. I had originally created a design with core pages in subfolders as "index.html" (having "nipy.org/blog/index.html seems to be the only way to achieve a url like "nipy.org/blog"), however this ran into this formatting issue. I had several ideas: - *using special templates for subfolders:* was my first go, but generating everything in two seemed redundant and annoying to need to update both things. That said, it would work, and I could possibly consolidate elements of the main design into one layout, and then just vary the includes depending on the level of the page. - *Ideal: *would be liquid syntax, a statement that can detect if we are in a subdirectory. I had a pretty simple solution that would work for a small set of pages, but of course ran into trouble with the blog subpages. For this reason I moved the main pages back to the root. - *Build custom script: *A solution I thought of this morning would be to get the baseurl working for local development and jekyll deployment, and then write a quick script to be run after build to find and fix whatever absolute paths would break when being rendered on circle. That would go after this . Looking forward to getting input on this! There are definitely solutions, and I'm hoping someone might have an idea to satisfy the second bullet. Don't worry about details of the design for now, the infrastructure is what must be figured out. On Mon, Aug 17, 2015 at 4:56 AM, Alexandre ABRAHAM < abraham.alexandre at gmail.com> wrote: > > Those are the snakey thoughts! >> > > Oh, OK. > > >> It's just a fun detail - when you mouse over they correspond to the >> packages, and you can click on them, and the graphic is produced >> dynamically from the data. >> > > Yes, I've seen that. But I guess that ball sizes and colors are random? > Something like a wordcloud seems more useful to me. > > >> Do you see the snake logo? >> > > BTW, the rendering is weird on a big screen: the balls are really far from > the snake. > > > >> >> On Mon, Aug 17, 2015 at 2:23 AM, Alexandre ABRAHAM < >> abraham.alexandre at gmail.com> wrote: >> >>> Hi Vanessa, >>> >>> This looks good, maybe a little dry, but good. However, I don't get the >>> small balls at the top right, what do they represent? >>> >>> Alex. >>> >>> On Mon, Aug 17, 2015 at 6:46 AM, vanessa sochat >>> wrote: >>> >>>> I'm not completely convinced that an interactive sidebar-thing is >>>> really that useful, but it does work nicely on mobile. And for the >>>> structure of the actual pages for each package, something simple with >>>> smaller font and a clean sidebar with a link tree would be easiest to >>>> navigate, akin to sphinx. We possibly will try all these packages only to >>>> converge onto the simplest form and functionality (something like sphinx?) >>>> That would be terribly funny and pathetic at the same time, but at least we >>>> can be confident about robustly investigating options! I'm interested to >>>> hear what others think, of course on Monday. I'll keep thinking about this. >>>> >>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>>> wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> Here is an update to the site. I've ported it into jekyll >>>>> , and tested the template on >>>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>>> artifacts on circle.ci , >>>>> so we could preview PRs (Click "artifact" and then find home.html >>>>> ). >>>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>>> when you click the demo link above, the "posts" not being at the base url >>>>> means they will not be linked or render correctly (for example, here >>>>> is a link >>>>> >>>>> to a post on circle, and you won't see styling because the css/js links are >>>>> broken) >>>>> >>>>> The site works perfectly given that we aren't serving it at a relative >>>>> path, eg: >>>>> >>>>> jekyll serve --baseurl="/" >>>>> >>>>> And the challenge is finding a solution that will render locally, on >>>>> github pages, and circle.ci, and what we need, I think, is some kind >>>>> of liquid syntax that will detect when we are in a subfolder and render >>>>> appropriately. I've been messing around with it for 7 hours today and can't >>>>> figure it out, and I need to ask for help. Could someone else take a look? >>>>> Likely someone with more experience than me with Jekyll could figure this >>>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>>> details of the content, make proper documentation, and then release to >>>>> official github pages. >>>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Mon Aug 17 08:34:19 2015 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Sun, 16 Aug 2015 23:34:19 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: <87y4ha1l04.fsf@berkeley.edu> Hi Vanessa On 2015-08-16 15:18:03, vanessa sochat wrote: > Here is an update to the site. I've ported it into jekyll That looks good! A small change that may be useful on the frontpage is to use two columns an decrease the amount of white-space in the boxes. That way, you may be able to fit most projects in on one glance. St?fan From vsochat at stanford.edu Mon Aug 17 15:15:04 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Mon, 17 Aug 2015 06:15:04 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: ah far from the snake is not ideal... see what it looks like for me (small screen) attached. On Mon, Aug 17, 2015 at 4:56 AM, Alexandre ABRAHAM < abraham.alexandre at gmail.com> wrote: > > Those are the snakey thoughts! >> > > Oh, OK. > > >> It's just a fun detail - when you mouse over they correspond to the >> packages, and you can click on them, and the graphic is produced >> dynamically from the data. >> > > Yes, I've seen that. But I guess that ball sizes and colors are random? > Something like a wordcloud seems more useful to me. > > >> Do you see the snake logo? >> > > BTW, the rendering is weird on a big screen: the balls are really far from > the snake. > > > >> >> On Mon, Aug 17, 2015 at 2:23 AM, Alexandre ABRAHAM < >> abraham.alexandre at gmail.com> wrote: >> >>> Hi Vanessa, >>> >>> This looks good, maybe a little dry, but good. However, I don't get the >>> small balls at the top right, what do they represent? >>> >>> Alex. >>> >>> On Mon, Aug 17, 2015 at 6:46 AM, vanessa sochat >>> wrote: >>> >>>> I'm not completely convinced that an interactive sidebar-thing is >>>> really that useful, but it does work nicely on mobile. And for the >>>> structure of the actual pages for each package, something simple with >>>> smaller font and a clean sidebar with a link tree would be easiest to >>>> navigate, akin to sphinx. We possibly will try all these packages only to >>>> converge onto the simplest form and functionality (something like sphinx?) >>>> That would be terribly funny and pathetic at the same time, but at least we >>>> can be confident about robustly investigating options! I'm interested to >>>> hear what others think, of course on Monday. I'll keep thinking about this. >>>> >>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>>> wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> Here is an update to the site. I've ported it into jekyll >>>>> , and tested the template on >>>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>>> artifacts on circle.ci , >>>>> so we could preview PRs (Click "artifact" and then find home.html >>>>> ). >>>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>>> when you click the demo link above, the "posts" not being at the base url >>>>> means they will not be linked or render correctly (for example, here >>>>> is a link >>>>> >>>>> to a post on circle, and you won't see styling because the css/js links are >>>>> broken) >>>>> >>>>> The site works perfectly given that we aren't serving it at a relative >>>>> path, eg: >>>>> >>>>> jekyll serve --baseurl="/" >>>>> >>>>> And the challenge is finding a solution that will render locally, on >>>>> github pages, and circle.ci, and what we need, I think, is some kind >>>>> of liquid syntax that will detect when we are in a subfolder and render >>>>> appropriately. I've been messing around with it for 7 hours today and can't >>>>> figure it out, and I need to ask for help. Could someone else take a look? >>>>> Likely someone with more experience than me with Jekyll could figure this >>>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>>> details of the content, make proper documentation, and then release to >>>>> official github pages. >>>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: thoughts.png Type: image/png Size: 31630 bytes Desc: not available URL: From arfanakis at iit.edu Sun Aug 16 14:19:33 2015 From: arfanakis at iit.edu (Konstantinos Arfanakis) Date: Sun, 16 Aug 2015 15:19:33 +0300 Subject: [Neuroimaging] Tractography normalization In-Reply-To: References: <540B96B0-AFEE-41E4-A655-0B48594F4DAF@iit.edu> Message-ID: <6C8117ED-031B-4B9A-9C4D-3C650827F93F@iit.edu> Hi JB, I know my answer to your question, but let me first bring your question to our general counsel who wrote the text for the license. Regards, Konstantinos > On Aug 13, 2015, at 2:59 AM, JB Poline wrote: > > Hi Konstantinos, > > Say I want to derive a new atlas from IIT. Can I redistribute my > derived atlas freely ? > > cheers > JB > > On Tue, Aug 4, 2015 at 11:23 PM, Konstantinos Arfanakis > wrote: >> Hi JB, >> >> It would help me answer your question if you could give me a very general >> description of what you are planning to generate and how would that be used. >> >> Regards, >> Konstantinos >> >> >> >> On Aug 5, 2015, at 4:54 AM, Eleftherios Garyfallidis >> wrote: >> >> Hi JB, >> >> I am not familiar with the restrictions of the license. I think that >> Konstantinos is the best person to answer this question. I am cc'ing him. >> >> You may want to continue this discussion in a different thread as it is a >> bit off topic. >> >> Cheers, >> Eleftherios >> >>> On Tue, Aug 4, 2015 at 9:42 PM, JB Poline wrote: >>> >>> Hi, >>> >>> I was curious about the IIT license: does anyone understand >>> >>> " >>> (2) You may not alter, transform, adapt or build upon the information, >>> images or data; >>> " >>> >>> so : "build upon the information" is a bit vague : I guess you cannot >>> create an atlas or anything from it, you have to use it as it is ? That >>> seems bad - but may be I missed something ? >>> >>> cheers >>> >>> JB >>> >>> >>> >>> On Tue, Aug 4, 2015 at 6:25 PM, Eleftherios Garyfallidis >>> wrote: >>>> >>>> Hello, >>>> >>>>> On Tue, Aug 4, 2015 at 7:21 PM, Jorge Rudas wrote: >>>>> >>>>> Thanks for your answer Eleftherios >>>>> >>>>> One questions more... >>>> Be happy to ask as many questions as you need until everything is clear. >>>> I am sure you will need >>>> feedback from us to perform such an analysis. That is because although we >>>> are currently working on making >>>> easy workflows, right now you will need write your own scripts combining >>>> different DIPY tutorials of the >>>> development version. >>>> >>>> Of course I am more than happy to help you with this. >>>> >>>>> >>>>> When you say "then apply the deformation fields to the tractographies", >>>>> what exactly does this mean ? >>>> You will generate streamlines and FA maps in the native space of every >>>> subject. Then you can for example register >>>> the FAs to an FA template. After you have performed this registrations >>>> you will also have saved the deformation fields >>>> which were applied to the FAs so that they can be registered to the FA >>>> template. Because the tractographies were >>>> in the same space (native) as the FAs the same deformation fields can be >>>> used to warp them to the FA template space >>>> and in that way your tractographies will also be normalized. >>>> >>>> Cheers, >>>> Eleftherios >>>> >>>> p.s. As an FA template I recommend using the IIT atlas. >>>> >>>>> >>>>> Regards >>>>> >>>>> >>>>> Jorge Rudas >>>>> >>>>> >>>>> 2015-08-04 15:55 GMT-05:00 Eleftherios Garyfallidis >>>>> : >>>>>> >>>>>> Hi Jorge, >>>>>> >>>>>> This is a very active research area in DIPY. There are currently two >>>>>> ways: >>>>>> >>>>>> a) You can register FA images together using our image registration >>>>>> functions and then apply the deformation fields to the tractographies. >>>>>> >>>>>> b) Segment bundles from the tractographies (manually or automatically) >>>>>> and register them directly using the SLR. Paper here >>>>>> >>>>>> http://www.ncbi.nlm.nih.gov/pubmed/25987367 >>>>>> >>>>>> Cheers, >>>>>> Eleftherios >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 4, 2015 at 4:14 PM, Jorge Rudas >>>>>> wrote: >>>>>>> >>>>>>> Hi everyone >>>>>>> >>>>>>> Any suggestions for to spatial normalization of tractographys?. I want >>>>>>> compare tractographys at population level. >>>>>>> >>>>>>> regards, >>>>>>> >>>>>>> Jorge Rudas >>>>>>> National University of Colombia >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >> From Gael.GORET at cea.fr Thu Aug 20 15:31:28 2015 From: Gael.GORET at cea.fr (GORET Gael 246279) Date: Thu, 20 Aug 2015 13:31:28 +0000 Subject: [Neuroimaging] 3d registration for data fusion in material science Message-ID: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> Hi everybody, I am a (French) newcomer, working on the development of the data fusion of Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray Nano-Tomography (XuM) data at the CEA (the French state institute for energy, high-tech, etc.). In terms of samples, we're a bit far from the neuro-fields ... Solid oxide fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology I hope we have to share ... my project is to combine a chemical information (from ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at nano-scale). I am tackling a python module aiming to the registration of 3d datasets. it seems that nipy includes a such possibility (an a lot more ...). I'm a computer guy, mostly Pythonist and I wander if you would let me transpose your code (mainly the registration part) to my problematic, I would be very grateful for this. In this context would you have some advice for me ? I'm looking forward to hearing from you. Gael [cid:image002.png at 01D0DB5D.479B35A0] Dr. Ga?l Goret Chercheur Postdoctoral D?partement des Technologies Silicium Service de Caract?risation des Mat?riaux & Composants Commissariat ? l'?nergie atomique et aux ?nergies alternatives MINATEC Campus | 17 rue des martyrs | F-38054 Grenoble Cedex T. +33 (0)4 38 78 49 29 | gael.goret at cea.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 8992 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 1321 bytes Desc: image004.jpg URL: From garyfallidis at gmail.com Thu Aug 20 16:35:05 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Thu, 20 Aug 2015 10:35:05 -0400 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> Message-ID: Hi Gael, Sounds exciting. There is no restriction to use our tools in other libraries or domains. Look at these tutorials please (you need dipy development version) https://github.com/nipy/dipy/blob/master/doc/examples/affine_registration_3d.py https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_2d.py https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_3d.py Do you have a github repo of your project? Do you have any example pictures/volumes to show us that you would like to register? Cheers, Eleftherios On Thu, Aug 20, 2015 at 9:31 AM, GORET Gael 246279 wrote: > Hi everybody, > > I am a (French) newcomer, working on the development of the data fusion of > Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray > Nano-Tomography (XuM) data at the CEA (the French state institute for > energy, high-tech, etc.). > > In terms of samples, we?re a bit far from the neuro-fields ? Solid oxide > fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology I hope > we have to share ? my project is to combine a chemical information (from > ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at > nano-scale). I am tackling a python module aiming to the registration of > 3d datasets. it seems that nipy includes a such possibility (an a lot more > ?). > > I?m a computer guy, mostly Pythonist and I wander if you would let me > transpose your code (mainly the registration part) to my problematic, I > would be very grateful for this. > > In this context would you have some advice for me ? > > I'm looking forward to hearing from you. > > Gael > > > > > > *Dr. Ga?l Goret* > > Chercheur Postdoctoral > > D?partement des Technologies Silicium > > *S*ervice de *C*aract?risation des *M*at?riaux & *C*omposants > > Commissariat ? l??nergie atomique et aux ?nergies alternatives > > MINATEC Campus *|* 17 rue des martyrs *|* F-38054 Grenoble Cedex > > T. +33 (0)4 38 7*8 49 29 **| *gael.goret at cea.fr > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 1321 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 8992 bytes Desc: not available URL: From bertrand.thirion at inria.fr Thu Aug 20 22:01:00 2015 From: bertrand.thirion at inria.fr (bthirion) Date: Thu, 20 Aug 2015 22:01:00 +0200 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> Message-ID: <55D631FC.7040707@inria.fr> Dear Gael, If you're talking about the registration code in nipy, this is BSD code, so there is essentially no restriction to using/adapting it for your own purpose. You might want to collaborate with Alexis Roche who is the main author of this code. Best, Bertrand On 20/08/2015 15:31, GORET Gael 246279 wrote: > > Hi everybody, > > I am a (French) newcomer, working on the development of the data > fusion of Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) > and X ray Nano-Tomography (XuM) data at the CEA (the French state > institute for energy, high-tech, etc.). > > In terms of samples, we?re a bit far from the neuro-fields ? Solid > oxide fuel cell, 3D chips, Si/Li matrix, etc., but in terms of > methodology I hope we have to share ? my project is to combine a > chemical information (from ToF-SIMS) with X-ray absorption (given by > XuM) for a given volume (at nano-scale). I am tackling a python > module aiming to the registration of 3d datasets. it seems that nipy > includes a such possibility (an a lot more ?). > > I?m a computer guy, mostly Pythonist and I wander if you would let me > transpose your code (mainly the registration part) to my problematic, > I would be very grateful for this. > > In this context would you have some advice for me ? > > I'm looking forward to hearing from you. > > Gael > > > > *Dr. Ga?l Goret*** > > Chercheur Postdoctoral > > D?partement des Technologies Silicium > > *S*ervice de *C*aract?risation des *M*at?riaux & *C*omposants > > Commissariat ? l??nergie atomique et aux ?nergies alternatives > > MINATEC Campus *|*17 rue des martyrs *|*F-38054 Grenoble Cedex > > T. +33 (0)4 38 7*8 49 29 **| *gael.goret at cea.fr > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 8992 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1321 bytes Desc: not available URL: From Gael.GORET at cea.fr Fri Aug 21 09:57:59 2015 From: Gael.GORET at cea.fr (GORET Gael 246279) Date: Fri, 21 Aug 2015 07:57:59 +0000 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> Message-ID: <03955F518517BD4DB8C6698E5ADAEC2A20C7FB@EXDAG0-B1.intra.cea.fr> Hi all, Thanks for your quick replies, This project is just starting, and there is not too much materials ? However, to answer your questions, I just have created a public repo on my github account : https://github.com/ggoret/MUDRA - In /doc, I have placed a summary (a pdf slideshow) of the project containing some pictures (and info on instruments) - In /examples I have put two data volumes (npy binary file format) the kind of data I need to register. - In /mudra a first (naive) try using the Fourier shell correlation as metric And you can also find - a Cython wrapping of malik and perona?s algorithms implementation working (pretty quickly) on 3D Volumes : o /mudra/extensions/non_linear_filtering.pyx - In /scripts you will find mainly converters simplifying I/O - In /tools 3 very nice visualization tools based on VTK (not mayavi) working as standalone (npy input) : o elevation.py -> 2d image to 3d landscape o plan_interpolator.py -> 2d slicing of volume + isosurface rendering for given seeds o scalar_field.py -> volume rendering (color and opacity gradient) Thanks in advance for your advices Cheers, Gael De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret=cea.fr at python.org] De la part de Eleftherios Garyfallidis Envoy? : jeudi 20 ao?t 2015 16:35 ? : Neuroimaging analysis in Python Objet : Re: [Neuroimaging] 3d registration for data fusion in material science Hi Gael, Sounds exciting. There is no restriction to use our tools in other libraries or domains. Look at these tutorials please (you need dipy development version) https://github.com/nipy/dipy/blob/master/doc/examples/affine_registration_3d.py https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_2d.py https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_3d.py Do you have a github repo of your project? Do you have any example pictures/volumes to show us that you would like to register? Cheers, Eleftherios On Thu, Aug 20, 2015 at 9:31 AM, GORET Gael 246279 > wrote: Hi everybody, I am a (French) newcomer, working on the development of the data fusion of Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray Nano-Tomography (XuM) data at the CEA (the French state institute for energy, high-tech, etc.). In terms of samples, we?re a bit far from the neuro-fields ? Solid oxide fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology I hope we have to share ? my project is to combine a chemical information (from ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at nano-scale). I am tackling a python module aiming to the registration of 3d datasets. it seems that nipy includes a such possibility (an a lot more ?). I?m a computer guy, mostly Pythonist and I wander if you would let me transpose your code (mainly the registration part) to my problematic, I would be very grateful for this. In this context would you have some advice for me ? I'm looking forward to hearing from you. Gael [cid:image001.png at 01D0DBF3.C1848DD0] Dr. Ga?l Goret Chercheur Postdoctoral D?partement des Technologies Silicium Service de Caract?risation des Mat?riaux & Composants Commissariat ? l??nergie atomique et aux ?nergies alternatives MINATEC Campus | 17 rue des martyrs | F-38054 Grenoble Cedex T. +33 (0)4 38 78 49 29 | gael.goret at cea.fr _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8992 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1321 bytes Desc: image002.jpg URL: From alexis.roche at gmail.com Fri Aug 21 13:03:48 2015 From: alexis.roche at gmail.com (Alexis Roche) Date: Fri, 21 Aug 2015 13:03:48 +0200 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: <03955F518517BD4DB8C6698E5ADAEC2A20C7FB@EXDAG0-B1.intra.cea.fr> References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C7FB@EXDAG0-B1.intra.cea.fr> Message-ID: Hi Gael, Beside the stuff in dipy that Elef mentioned, there is another brain image registration package that has slowly developed over the years, and could be useful to you (although it still crucially lacks documentation): https://github.com/nipy/nireg This is rigid/affine registration only for the time being and has a BSD license too. Best, Alexis On Fri, Aug 21, 2015 at 9:57 AM, GORET Gael 246279 wrote: > Hi all, > > > > Thanks for your quick replies, > > This project is just starting, and there is not too much materials ? > > However, to answer your questions, I just have created a public repo on my > github account : > > > > https://github.com/ggoret/MUDRA > > > > - In /doc, I have placed a summary (a pdf slideshow) of the > project containing some pictures (and info on instruments) > > > > - In /examples I have put two data volumes (npy binary file > format) the kind of data I need to register. > > > > - In /mudra a first (naive) try using the Fourier shell > correlation as metric > > And you can also find > > - a Cython wrapping of malik and perona?s algorithms > implementation working (pretty quickly) on 3D Volumes : > > o /mudra/extensions/non_linear_filtering.pyx > > > > - In /scripts you will find mainly converters simplifying I/O > > - In /tools 3 very nice visualization tools based on VTK (not > mayavi) working as standalone (npy input) : > > o elevation.py -> 2d image to 3d landscape > > o plan_interpolator.py -> 2d slicing of volume + isosurface rendering > for given seeds > > o scalar_field.py -> volume rendering (color and opacity gradient) > > > > Thanks in advance for your advices > > > > Cheers, > > > > Gael > > > > *De :* Neuroimaging [mailto:neuroimaging-bounces+gael.goret= > cea.fr at python.org] *De la part de* Eleftherios Garyfallidis > *Envoy? :* jeudi 20 ao?t 2015 16:35 > *? :* Neuroimaging analysis in Python > *Objet :* Re: [Neuroimaging] 3d registration for data fusion in material > science > > > > Hi Gael, > > > > Sounds exciting. There is no restriction to use our tools in other > libraries or domains. > > Look at these tutorials please (you need dipy development version) > > > > > https://github.com/nipy/dipy/blob/master/doc/examples/affine_registration_3d.py > > > https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_2d.py > > > https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_3d.py > > > > Do you have a github repo of your project? Do you have any example > pictures/volumes to show us that you would > > like to register? > > > > Cheers, > > Eleftherios > > > > > > > > On Thu, Aug 20, 2015 at 9:31 AM, GORET Gael 246279 > wrote: > > Hi everybody, > > I am a (French) newcomer, working on the development of the data fusion of > Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray > Nano-Tomography (XuM) data at the CEA (the French state institute for > energy, high-tech, etc.). > > In terms of samples, we?re a bit far from the neuro-fields ? Solid oxide > fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology I hope > we have to share ? my project is to combine a chemical information (from > ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at > nano-scale). I am tackling a python module aiming to the registration of > 3d datasets. it seems that nipy includes a such possibility (an a lot more > ?). > > I?m a computer guy, mostly Pythonist and I wander if you would let me > transpose your code (mainly the registration part) to my problematic, I > would be very grateful for this. > > In this context would you have some advice for me ? > > I'm looking forward to hearing from you. > > Gael > > > > > > *Dr. Ga?l Goret* > > Chercheur Postdoctoral > > D?partement des Technologies Silicium > > *S*ervice de *C*aract?risation des *M*at?riaux & *C*omposants > > Commissariat ? l??nergie atomique et aux ?nergies alternatives > > MINATEC Campus *|* 17 rue des martyrs *|* F-38054 Grenoble Cedex > > T. +33 (0)4 38 7*8 49 29 **| *gael.goret at cea.fr > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Lead Clinical Research Advanced Clinical Imaging Technology Siemens/CHUV/EPFL 1015 Lausanne, Switzerland Phone: +41 21 545 9972 https://sites.google.com/site/alexisroche -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1321 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8992 bytes Desc: not available URL: From Gael.GORET at cea.fr Fri Aug 21 13:54:14 2015 From: Gael.GORET at cea.fr (GORET Gael 246279) Date: Fri, 21 Aug 2015 11:54:14 +0000 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C7FB@EXDAG0-B1.intra.cea.fr> Message-ID: <03955F518517BD4DB8C6698E5ADAEC2A20C86F@EXDAG0-B1.intra.cea.fr> The nireg repo was originally which push me to contact the Neuroimaging group. Apart some scaling issue (anisotropic pixel spacing), the rigid body approach should suit to my problematic. The following snippet : https://github.com/nipy/nireg/blob/master/examples/affine_registration.py seems a good starting points to me. The magic is confine into the HistogramRegistration class in the following module : https://github.com/nipy/nipy/blob/master/nipy/algorithms/registration/histogram_registration.py The code seems tricky, but with a lot of comments and docstrings !! it could have been much much worse :) Questions : - how to convert a numpy array to nipy-like image ? - should the two images have the same size ? - the version of nipy that I should use ? thank you, really, for your attention, this is kind. Gael De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret=cea.fr at python.org] De la part de Alexis Roche Envoy? : vendredi 21 ao?t 2015 13:04 ? : Neuroimaging analysis in Python Objet : Re: [Neuroimaging] 3d registration for data fusion in material science Hi Gael, Beside the stuff in dipy that Elef mentioned, there is another brain image registration package that has slowly developed over the years, and could be useful to you (although it still crucially lacks documentation): https://github.com/nipy/nireg This is rigid/affine registration only for the time being and has a BSD license too. Best, Alexis On Fri, Aug 21, 2015 at 9:57 AM, GORET Gael 246279 > wrote: Hi all, Thanks for your quick replies, This project is just starting, and there is not too much materials ? However, to answer your questions, I just have created a public repo on my github account : https://github.com/ggoret/MUDRA - In /doc, I have placed a summary (a pdf slideshow) of the project containing some pictures (and info on instruments) - In /examples I have put two data volumes (npy binary file format) the kind of data I need to register. - In /mudra a first (naive) try using the Fourier shell correlation as metric And you can also find - a Cython wrapping of malik and perona?s algorithms implementation working (pretty quickly) on 3D Volumes : o /mudra/extensions/non_linear_filtering.pyx - In /scripts you will find mainly converters simplifying I/O - In /tools 3 very nice visualization tools based on VTK (not mayavi) working as standalone (npy input) : o elevation.py -> 2d image to 3d landscape o plan_interpolator.py -> 2d slicing of volume + isosurface rendering for given seeds o scalar_field.py -> volume rendering (color and opacity gradient) Thanks in advance for your advices Cheers, Gael De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret=cea.fr at python.org] De la part de Eleftherios Garyfallidis Envoy? : jeudi 20 ao?t 2015 16:35 ? : Neuroimaging analysis in Python Objet : Re: [Neuroimaging] 3d registration for data fusion in material science Hi Gael, Sounds exciting. There is no restriction to use our tools in other libraries or domains. Look at these tutorials please (you need dipy development version) https://github.com/nipy/dipy/blob/master/doc/examples/affine_registration_3d.py https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_2d.py https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_3d.py Do you have a github repo of your project? Do you have any example pictures/volumes to show us that you would like to register? Cheers, Eleftherios On Thu, Aug 20, 2015 at 9:31 AM, GORET Gael 246279 > wrote: Hi everybody, I am a (French) newcomer, working on the development of the data fusion of Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray Nano-Tomography (XuM) data at the CEA (the French state institute for energy, high-tech, etc.). In terms of samples, we?re a bit far from the neuro-fields ? Solid oxide fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology I hope we have to share ? my project is to combine a chemical information (from ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at nano-scale). I am tackling a python module aiming to the registration of 3d datasets. it seems that nipy includes a such possibility (an a lot more ?). I?m a computer guy, mostly Pythonist and I wander if you would let me transpose your code (mainly the registration part) to my problematic, I would be very grateful for this. In this context would you have some advice for me ? I'm looking forward to hearing from you. Gael [cid:image001.png at 01D0DC13.C3A9F850] Dr. Ga?l Goret Chercheur Postdoctoral D?partement des Technologies Silicium Service de Caract?risation des Mat?riaux & Composants Commissariat ? l??nergie atomique et aux ?nergies alternatives MINATEC Campus | 17 rue des martyrs | F-38054 Grenoble Cedex T. +33 (0)4 38 78 49 29 | gael.goret at cea.fr _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -- Lead Clinical Research Advanced Clinical Imaging Technology Siemens/CHUV/EPFL 1015 Lausanne, Switzerland Phone: +41 21 545 9972 https://sites.google.com/site/alexisroche -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8992 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1321 bytes Desc: image002.jpg URL: From alexis.roche at gmail.com Fri Aug 21 15:07:44 2015 From: alexis.roche at gmail.com (Alexis Roche) Date: Fri, 21 Aug 2015 15:07:44 +0200 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: <03955F518517BD4DB8C6698E5ADAEC2A20C86F@EXDAG0-B1.intra.cea.fr> References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C7FB@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C86F@EXDAG0-B1.intra.cea.fr> Message-ID: Yes, nireg can recover an anisotropic scaling using a 12-parameter affine transform (this would also estimate a shearing effect) or an isotropic scaling using a similarity transform (7 parameters). Alexis Le 21 ao?t 2015 12:54, "GORET Gael 246279" a ?crit : > The nireg repo was originally which push me to contact the Neuroimaging > group. > > Apart some scaling issue (anisotropic pixel spacing), the rigid body > approach should suit to my problematic. > > > > The following snippet : > > https://github.com/nipy/nireg/blob/master/examples/affine_registration.py > > seems a good starting points to me. > > > > The magic is confine into the HistogramRegistration class in the > following module : > > > https://github.com/nipy/nipy/blob/master/nipy/algorithms/registration/histogram_registration.py > > The code seems tricky, but with a lot of comments and docstrings !! it > could have been much much worse :) > > > > Questions : > > - how to convert a numpy array to nipy-like image ? > > - should the two images have the same size ? > > - the version of nipy that I should use ? > > > > > > thank you, really, for your attention, this is kind. > > > > Gael > > > > > > > > > > *De :* Neuroimaging [mailto:neuroimaging-bounces+gael.goret=cea.fr at py > thon.org] *De la part de* Alexis Roche > *Envoy? :* vendredi 21 ao?t 2015 13:04 > *? :* Neuroimaging analysis in Python > *Objet :* Re: [Neuroimaging] 3d registration for data fusion in material > science > > > > Hi Gael, > > Beside the stuff in dipy that Elef mentioned, there is another brain image > registration package that has slowly developed over the years, and could be > useful to you (although it still crucially lacks documentation): > > https://github.com/nipy/nireg > > > > This is rigid/affine registration only for the time being and has a BSD > license too. > > > > Best, > > Alexis > > > > On Fri, Aug 21, 2015 at 9:57 AM, GORET Gael 246279 > wrote: > > Hi all, > > > > Thanks for your quick replies, > > This project is just starting, and there is not too much materials ? > > However, to answer your questions, I just have created a public repo on my > github account : > > > > https://github.com/ggoret/MUDRA > > > > - In /doc, I have placed a summary (a pdf slideshow) of the > project containing some pictures (and info on instruments) > > > > - In /examples I have put two data volumes (npy binary file > format) the kind of data I need to register. > > > > - In /mudra a first (naive) try using the Fourier shell > correlation as metric > > And you can also find > > - a Cython wrapping of malik and perona?s algorithms > implementation working (pretty quickly) on 3D Volumes : > > o /mudra/extensions/non_linear_filtering.pyx > > > > - In /scripts you will find mainly converters simplifying I/O > > - In /tools 3 very nice visualization tools based on VTK (not > mayavi) working as standalone (npy input) : > > o elevation.py -> 2d image to 3d landscape > > o plan_interpolator.py -> 2d slicing of volume + isosurface rendering > for given seeds > > o scalar_field.py -> volume rendering (color and opacity gradient) > > > > Thanks in advance for your advices > > > > Cheers, > > > > Gael > > > > *De :* Neuroimaging [mailto:neuroimaging-bounces+gael.goret= > cea.fr at python.org] *De la part de* Eleftherios Garyfallidis > *Envoy? :* jeudi 20 ao?t 2015 16:35 > *? :* Neuroimaging analysis in Python > *Objet :* Re: [Neuroimaging] 3d registration for data fusion in material > science > > > > Hi Gael, > > > > Sounds exciting. There is no restriction to use our tools in other > libraries or domains. > > Look at these tutorials please (you need dipy development version) > > > > > https://github.com/nipy/dipy/blob/master/doc/examples/affine_registration_3d.py > > > https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_2d.py > > > https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_3d.py > > > > Do you have a github repo of your project? Do you have any example > pictures/volumes to show us that you would > > like to register? > > > > Cheers, > > Eleftherios > > > > > > > > On Thu, Aug 20, 2015 at 9:31 AM, GORET Gael 246279 > wrote: > > Hi everybody, > > I am a (French) newcomer, working on the development of the data fusion of > Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray > Nano-Tomography (XuM) data at the CEA (the French state institute for > energy, high-tech, etc.). > > In terms of samples, we?re a bit far from the neuro-fields ? Solid oxide > fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology I hope > we have to share ? my project is to combine a chemical information (from > ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at > nano-scale). I am tackling a python module aiming to the registration of > 3d datasets. it seems that nipy includes a such possibility (an a lot more > ?). > > I?m a computer guy, mostly Pythonist and I wander if you would let me > transpose your code (mainly the registration part) to my problematic, I > would be very grateful for this. > > In this context would you have some advice for me ? > > I'm looking forward to hearing from you. > > Gael > > > > > > *Dr. Ga?l Goret* > > Chercheur Postdoctoral > > D?partement des Technologies Silicium > > *S*ervice de *C*aract?risation des *M*at?riaux & *C*omposants > > Commissariat ? l??nergie atomique et aux ?nergies alternatives > > MINATEC Campus *|* 17 rue des martyrs *|* F-38054 Grenoble Cedex > > T. +33 (0)4 38 7*8 49 29 **| *gael.goret at cea.fr > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > -- > > Lead Clinical Research > Advanced Clinical Imaging Technology > Siemens/CHUV/EPFL > 1015 Lausanne, Switzerland > Phone: +41 21 545 9972 > https://sites.google.com/site/alexisroche > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1321 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8992 bytes Desc: not available URL: From schreiber at cbs.mpg.de Fri Aug 21 17:44:53 2015 From: schreiber at cbs.mpg.de (Jan Schreiber) Date: Fri, 21 Aug 2015 17:44:53 +0200 Subject: [Neuroimaging] [dipy] connectivity_matrix Message-ID: <55D74775.4080501@cbs.mpg.de> Hi Dipy Experts, the function "connectivity_matrix()" provides the option to produce a symmetric connectivity matrix. The computation is done in line 202 in https://github.com/nipy/dipy/blob/master/dipy/tracking/utils.py 201 if symmetric: 202 matrix = np.maximum(matrix, matrix.T) The test of this function defines the expected matrix as 100 expected = expected + expected.T I think the test might not be correct and it should be 100 expected = expected + expected.T - np.diag(np.diag(expected)) This does pop up as an error because the test does not include a connection with start and end point in the same ROI. A within-ROI connection produces an entry on the diagonal and would be counted twice with "expected + expected.T". A patch for an extended test is attached. I also added some more combinations of possible connections. What keeps puzzling me is that the function that computes the symmetry as matrix = np.maximum(matrix, matrix.T) gives the same result as expected = expected + expected.T - np.diag(np.diag(expected)) Cheers, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-added-test-for-within-ROI-connections-in-connectivit.patch Type: text/x-patch Size: 4092 bytes Desc: not available URL: From matthew.brett at gmail.com Fri Aug 21 18:55:26 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 21 Aug 2015 17:55:26 +0100 Subject: [Neuroimaging] Website Update In-Reply-To: <87y4ha1l04.fsf@berkeley.edu> References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Hi Vanessa, Thanks again for doing this. Have you got a github-pages build of this somewhere? Sorry if I missed it. I tried building locally, but I'm not confident that I'm getting what you expect to see. It would be good to have the mission statement somewhere, if y'all agree. Do you have any thoughts on Stefan's suggestion? Cheers, Matthew From vsochat at stanford.edu Fri Aug 21 19:01:37 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Fri, 21 Aug 2015 10:01:37 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Hi Matthew, I'm on board with Stefan's suggestion, I just stick to Poldracklab work during the week and haven't done any new nipy site work. As I mentioned earlier, I was hoping for some help with a more elegant solution to resolve the current base url issue (please see my previous messages). If there aren't any ideas, I will likely implement a very un-elegant / harder to change solution, just to get something working, and only after that does it make sense to give a go at github pages deployment. Best, Vanessa On Fri, Aug 21, 2015 at 9:55 AM, Matthew Brett wrote: > Hi Vanessa, > > Thanks again for doing this. > > Have you got a github-pages build of this somewhere? Sorry if I > missed it. I tried building locally, but I'm not confident that I'm > getting what you expect to see. > > It would be good to have the mission statement somewhere, if y'all agree. > > Do you have any thoughts on Stefan's suggestion? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.roche at gmail.com Fri Aug 21 18:57:21 2015 From: alexis.roche at gmail.com (Alexis Roche) Date: Fri, 21 Aug 2015 18:57:21 +0200 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: <03955F518517BD4DB8C6698E5ADAEC2A20C86F@EXDAG0-B1.intra.cea.fr> References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C7FB@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C86F@EXDAG0-B1.intra.cea.fr> Message-ID: Hi, I am realizing that the following example script is outdated as it still relies on importing nipy: https://github.com/nipy/nireg/blob/master/examples/affine_registration.py I will submit an update in a few days. The registration code was previously part of the nipy package, which we have recently decided to split into several standalone packages, including nireg. The idea is that nireg only needs nibabel to run (in addition to the standard numpy/scipy packages). > - how to convert a numpy array to nipy-like image ? This is done using nibabel, see in particular the Nifti1Image class. > - should the two images have the same size ? No. > - the version of nipy that I should use ? As mentioned above, the latest version of the code does not require nipy. I will let you know when I push an up-to-date version of the affine registration example script. Best, Alexis > > > > > > thank you, really, for your attention, this is kind. > > > > Gael > > > > > > > > > > De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret= cea.fr at python.org] De la part de Alexis Roche > Envoy? : vendredi 21 ao?t 2015 13:04 > > > ? : Neuroimaging analysis in Python > Objet : Re: [Neuroimaging] 3d registration for data fusion in material science > > > > Hi Gael, > > Beside the stuff in dipy that Elef mentioned, there is another brain image registration package that has slowly developed over the years, and could be useful to you (although it still crucially lacks documentation): > > https://github.com/nipy/nireg > > > > This is rigid/affine registration only for the time being and has a BSD license too. > > > > Best, > > Alexis > > > > On Fri, Aug 21, 2015 at 9:57 AM, GORET Gael 246279 wrote: > > Hi all, > > > > Thanks for your quick replies, > > This project is just starting, and there is not too much materials ? > > However, to answer your questions, I just have created a public repo on my github account : > > > > https://github.com/ggoret/MUDRA > > > > - In /doc, I have placed a summary (a pdf slideshow) of the project containing some pictures (and info on instruments) > > > > - In /examples I have put two data volumes (npy binary file format) the kind of data I need to register. > > > > - In /mudra a first (naive) try using the Fourier shell correlation as metric > > And you can also find > > - a Cython wrapping of malik and perona?s algorithms implementation working (pretty quickly) on 3D Volumes : > > o /mudra/extensions/non_linear_filtering.pyx > > > > - In /scripts you will find mainly converters simplifying I/O > > - In /tools 3 very nice visualization tools based on VTK (not mayavi) working as standalone (npy input) : > > o elevation.py -> 2d image to 3d landscape > > o plan_interpolator.py -> 2d slicing of volume + isosurface rendering for given seeds > > o scalar_field.py -> volume rendering (color and opacity gradient) > > > > Thanks in advance for your advices > > > > Cheers, > > > > Gael > > > > De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret= cea.fr at python.org] De la part de Eleftherios Garyfallidis > Envoy? : jeudi 20 ao?t 2015 16:35 > ? : Neuroimaging analysis in Python > Objet : Re: [Neuroimaging] 3d registration for data fusion in material science > > > > Hi Gael, > > > > Sounds exciting. There is no restriction to use our tools in other libraries or domains. > > Look at these tutorials please (you need dipy development version) > > > > https://github.com/nipy/dipy/blob/master/doc/examples/affine_registration_3d.py > > https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_2d.py > > https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_3d.py > > > > Do you have a github repo of your project? Do you have any example pictures/volumes to show us that you would > > like to register? > > > > Cheers, > > Eleftherios > > > > > > > > On Thu, Aug 20, 2015 at 9:31 AM, GORET Gael 246279 wrote: > > Hi everybody, > > I am a (French) newcomer, working on the development of the data fusion of Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray Nano-Tomography (XuM) data at the CEA (the French state institute for energy, high-tech, etc.). > > In terms of samples, we?re a bit far from the neuro-fields ? Solid oxide fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology I hope we have to share ? my project is to combine a chemical information (from ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at nano-scale). I am tackling a python module aiming to the registration of 3d datasets. it seems that nipy includes a such possibility (an a lot more ?). > > I?m a computer guy, mostly Pythonist and I wander if you would let me transpose your code (mainly the registration part) to my problematic, I would be very grateful for this. > > In this context would you have some advice for me ? > > I'm looking forward to hearing from you. > > Gael > > > > > > Dr. Ga?l Goret > > Chercheur Postdoctoral > > D?partement des Technologies Silicium > > Service de Caract?risation des Mat?riaux & Composants > > Commissariat ? l??nergie atomique et aux ?nergies alternatives > > MINATEC Campus | 17 rue des martyrs | F-38054 Grenoble Cedex > > T. +33 (0)4 38 78 49 29 | gael.goret at cea.fr > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > -- > > Lead Clinical Research > Advanced Clinical Imaging Technology > Siemens/CHUV/EPFL > 1015 Lausanne, Switzerland > Phone: +41 21 545 9972 > https://sites.google.com/site/alexisroche > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -- Lead Clinical Research Advanced Clinical Imaging Technology Siemens/CHUV/EPFL 1015 Lausanne, Switzerland Phone: +41 21 545 9972 https://sites.google.com/site/alexisroche -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrbago at gmail.com Fri Aug 21 21:48:26 2015 From: mrbago at gmail.com (Bago) Date: Fri, 21 Aug 2015 12:48:26 -0700 Subject: [Neuroimaging] [dipy] connectivity_matrix In-Reply-To: <55D74775.4080501@cbs.mpg.de> References: <55D74775.4080501@cbs.mpg.de> Message-ID: Hi Jan, You're right in general the symmetric matrix is `M + M.T - diag(M)`, but in the two cases you've highlighted he have more information from context that allows us to simplify the operation. First if you notice in the function itself, notice the part that says: if symmetric: endlabels.sort(0) This line re-orders the endpoints for each streamline to ensure that we get an upper triangular connectivity matrix. Because we know the matrix is upper triangular, `maximum(M, M.T) == M + M.T - diag(M)` If you want to know why we do it this way, the goal here is to produce a mapping dictionary that is also "symmetric", but only has 1 reference to each streamline. From the docs: ``mapping[i, j]`` returns all the streamlines that connect region `i` to region `j`. If `symmetric` is True mapping will only have one key for each start end pair such that if ``i < j`` mapping will have key ``(i, j)`` but not key ``(j, i)``. As you're already noted, we know that the expected matrix is 0 along the diagonal so I just committed the ` - diag(M)` part. Hope that clears things up, let me know if you have any other questions, Bago On Fri, Aug 21, 2015 at 8:44 AM, Jan Schreiber wrote: > Hi Dipy Experts, > > the function "connectivity_matrix()" provides the option to produce a > symmetric connectivity matrix. > The computation is done in line 202 in > https://github.com/nipy/dipy/blob/master/dipy/tracking/utils.py > > 201 if symmetric: > 202 matrix = np.maximum(matrix, matrix.T) > > The test of this function defines the expected matrix as > > 100 expected = expected + expected.T > > I think the test might not be correct and it should be > > 100 expected = expected + expected.T - np.diag(np.diag(expected)) > > This does pop up as an error because the test does not include a > connection with start and end point in the same ROI. A within-ROI > connection produces an entry on the diagonal and would be counted twice > with "expected + expected.T". > > > A patch for an extended test is attached. I also added some more > combinations of possible connections. > > What keeps puzzling me is that the function that computes the symmetry as > matrix = np.maximum(matrix, matrix.T) > gives the same result as > expected = expected + expected.T - np.diag(np.diag(expected)) > > Cheers, > Jan > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schreiber at cbs.mpg.de Fri Aug 21 22:40:31 2015 From: schreiber at cbs.mpg.de (Jan Schreiber) Date: Fri, 21 Aug 2015 22:40:31 +0200 Subject: [Neuroimaging] [dipy] connectivity_matrix In-Reply-To: References: <55D74775.4080501@cbs.mpg.de> Message-ID: <55D78CBF.3090902@cbs.mpg.de> Hi Bago, very smart! :-) Thanks, Jan On 08/21/2015 09:48 PM, Bago wrote: > Hi Jan, > > You're right in general the symmetric matrix is `M + M.T - diag(M)`, but > in the two cases you've highlighted he have more information from > context that allows us to simplify the operation. > > First if you notice in the function itself, notice the part that says: > > if symmetric: > endlabels.sort(0) > > This line re-orders the endpoints for each streamline to ensure that we > get an upper triangular connectivity matrix. Because we know the matrix > is upper triangular, `maximum(M, M.T) == M + M.T - diag(M)` > > If you want to know why we do it this way, the goal here is to produce a > mapping dictionary that is also "symmetric", but only has 1 reference to > each streamline. From the docs: > > ``mapping[i, j]`` returns all the streamlines that connect > region `i` > to region `j`. If `symmetric` is True mapping will only have one key > for each start end pair such that if ``i < j`` mapping will have key > ``(i, j)`` but not key ``(j, i)``. > > As you're already noted, we know that the expected matrix is 0 along the > diagonal so I just committed the ` - diag(M)` part. > > Hope that clears things up, let me know if you have any other questions, > Bago > > On Fri, Aug 21, 2015 at 8:44 AM, Jan Schreiber > wrote: > > Hi Dipy Experts, > > the function "connectivity_matrix()" provides the option to produce a > symmetric connectivity matrix. > The computation is done in line 202 in > https://github.com/nipy/dipy/blob/master/dipy/tracking/utils.py > > 201 if symmetric: > 202 matrix = np.maximum(matrix, matrix.T) > > The test of this function defines the expected matrix as > > 100 expected = expected + expected.T > > I think the test might not be correct and it should be > > 100 expected = expected + expected.T - np.diag(np.diag(expected)) > > This does pop up as an error because the test does not include a > connection with start and end point in the same ROI. A within-ROI > connection produces an entry on the diagonal and would be counted twice > with "expected + expected.T". > > > A patch for an extended test is attached. I also added some more > combinations of possible connections. > > What keeps puzzling me is that the function that computes the > symmetry as > matrix = np.maximum(matrix, matrix.T) > gives the same result as > expected = expected + expected.T - np.diag(np.diag(expected)) > > Cheers, > Jan > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4852 bytes Desc: S/MIME Cryptographic Signature URL: From bcipolli at ucsd.edu Sat Aug 22 19:32:11 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sat, 22 Aug 2015 10:32:11 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: I'm trying to install Jekyll now, and will see if I can reproduce the problem. If so, I may have a few mins today to think about a solution. Vanessa, do you have a sense of why this is happening? Is the problem finding a solution to a problem you understand well, or is the problem investigating why this is happening to start with? Thanks! Ben On Fri, Aug 21, 2015 at 10:01 AM, vanessa sochat wrote: > Hi Matthew, > > I'm on board with Stefan's suggestion, I just stick to Poldracklab work > during the week and haven't done any new nipy site work. As I mentioned > earlier, I was hoping for some help with a more elegant solution to resolve > the current base url issue (please see my previous messages). If there > aren't any ideas, I will likely implement a very un-elegant / harder to > change solution, just to get something working, and only after that does it > make sense to give a go at github pages deployment. > > Best, > > Vanessa > > On Fri, Aug 21, 2015 at 9:55 AM, Matthew Brett > wrote: > >> Hi Vanessa, >> >> Thanks again for doing this. >> >> Have you got a github-pages build of this somewhere? Sorry if I >> missed it. I tried building locally, but I'm not confident that I'm >> getting what you expect to see. >> >> It would be good to have the mission statement somewhere, if y'all agree. >> >> Do you have any thoughts on Stefan's suggestion? >> >> Cheers, >> >> Matthew >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Sat Aug 22 20:04:37 2015 From: arokem at gmail.com (Ariel Rokem) Date: Sat, 22 Aug 2015 11:04:37 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Hi Vanessa, Sorry for the delay in responding. On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat wrote: > Hi Everyone, > > Here is an update to the site. I've ported it into jekyll > , and tested the template on iphone > and computer (seems reasonable). I've also gotten it to render the > artifacts on circle.ci , so > we could preview PRs (Click "artifact" and then find home.html > ). > However, I've run into a bug with regard to absolute vs. relative paths - > when you click the demo link above, the "posts" not being at the base url > means they will not be linked or render correctly (for example, here is a > link > > to a post on circle, and you won't see styling because the css/js links are > broken) > > The site works perfectly given that we aren't serving it at a relative > path, eg: > > jekyll serve --baseurl="/" > > And the challenge is finding a solution that will render locally, on > github pages, and circle.ci, and what we need, I think, is some kind of > liquid syntax that will detect when we are in a subfolder and render > appropriately. I've been messing around with it for 7 hours today and can't > figure it out, and I need to ask for help. Could someone else take a look? > Likely someone with more experience than me with Jekyll could figure this > out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would > be to figure out this bug, get it onto a (test) github pages, tweak the > details of the content, make proper documentation, and then release to > official github pages. > > Why do we need CircleCI here? I am actually not sure what the issue is, but here's the site rendered through gh-pages on my fork of your repo: http://arokem.github.io/nipy-jekyll/ I did also add a Gemfile to the repo, and that might matter: I believe Github pages serves jekyll through a call to "bundle exec jekyll serve" (see here: https://help.github.com/articles/using-jekyll-with-pages/). One comment about the content: I would prefer to have a front page that just states what this thing is, and the projects on a separate page. I would like for it to be *super* easy to add projects. The whole idea is that the NIPY community is not a static list of projects, but an ever-evolving ecosystem. Cheers, Ariel > Best, > > Vanessa > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sat Aug 22 19:59:05 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sat, 22 Aug 2015 10:59:05 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: OK, I see the problem. Our static files are served relative to the base directory, which is a _config.yaml setting (overridable from the command-line). If we set baseurl = "", then static files are referenced as relative URLs. This works for pages served from the base directory (css/bootstrap.css served from home.html will work), but needs a relative path change (../css/bootstrap.css served for somedir/somefile.html). If we set base_directory to "/", then everything works locally, because the root url (/) points to the home directory of the webpage. It doesn't work on circle.ci, because the root url does NOT point to the home directory of the webpage (of course not; it points to circle.ci). Now that I understand the problem, I'll look at the best way to do this. Could simply be overriding baseurl to the proper thing in circle.ci (not blank, but some deep path on the website), or embedding the proper relative paths in the html when generating the pages. Ben On Sat, Aug 22, 2015 at 10:32 AM, Ben Cipollini wrote: > I'm trying to install Jekyll now, and will see if I can reproduce the > problem. If so, I may have a few mins today to think about a solution. > > Vanessa, do you have a sense of why this is happening? Is the problem > finding a solution to a problem you understand well, or is the problem > investigating why this is happening to start with? > > Thanks! > Ben > > On Fri, Aug 21, 2015 at 10:01 AM, vanessa sochat > wrote: > >> Hi Matthew, >> >> I'm on board with Stefan's suggestion, I just stick to Poldracklab work >> during the week and haven't done any new nipy site work. As I mentioned >> earlier, I was hoping for some help with a more elegant solution to resolve >> the current base url issue (please see my previous messages). If there >> aren't any ideas, I will likely implement a very un-elegant / harder to >> change solution, just to get something working, and only after that does it >> make sense to give a go at github pages deployment. >> >> Best, >> >> Vanessa >> >> On Fri, Aug 21, 2015 at 9:55 AM, Matthew Brett >> wrote: >> >>> Hi Vanessa, >>> >>> Thanks again for doing this. >>> >>> Have you got a github-pages build of this somewhere? Sorry if I >>> missed it. I tried building locally, but I'm not confident that I'm >>> getting what you expect to see. >>> >>> It would be good to have the mission statement somewhere, if y'all agree. >>> >>> Do you have any thoughts on Stefan's suggestion? >>> >>> Cheers, >>> >>> Matthew >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Sat Aug 22 20:07:52 2015 From: arokem at gmail.com (Ariel Rokem) Date: Sat, 22 Aug 2015 11:07:52 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Just to be clear: On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: > Hi Vanessa, > > Sorry for the delay in responding. > > On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat > wrote: > >> Hi Everyone, >> >> Here is an update to the site. I've ported it into jekyll >> , and tested the template on >> iphone and computer (seems reasonable). I've also gotten it to render the >> artifacts on circle.ci , >> so we could preview PRs (Click "artifact" and then find home.html >> ). >> However, I've run into a bug with regard to absolute vs. relative paths - >> when you click the demo link above, the "posts" not being at the base url >> means they will not be linked or render correctly (for example, here is >> a link >> >> to a post on circle, and you won't see styling because the css/js links are >> broken) >> >> The site works perfectly given that we aren't serving it at a relative >> path, eg: >> >> jekyll serve --baseurl="/" >> >> And the challenge is finding a solution that will render locally, on >> github pages, and circle.ci, and what we need, I think, is some kind of >> liquid syntax that will detect when we are in a subfolder and render >> appropriately. I've been messing around with it for 7 hours today and can't >> figure it out, and I need to ask for help. Could someone else take a look? >> Likely someone with more experience than me with Jekyll could figure this >> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >> be to figure out this bug, get it onto a (test) github pages, tweak the >> details of the content, make proper documentation, and then release to >> official github pages. >> >> > Why do we need CircleCI here? I am actually not sure what the issue is, > but here's the site rendered through gh-pages on my fork of your repo: > > http://arokem.github.io/nipy-jekyll/ > > For this to happen, the content has to be on a branch named `gh-pages` in the repo. A jekyll build is triggered if and only if content is pushed to a branch with that exact name! Ariel > I did also add a Gemfile to the repo, and that might matter: I believe > Github pages serves jekyll through a call to "bundle exec jekyll serve" > (see here: https://help.github.com/articles/using-jekyll-with-pages/). > > One comment about the content: I would prefer to have a front page that > just states what this thing is, and the projects on a separate page. I > would like for it to be *super* easy to add projects. The whole idea is > that the NIPY community is not a static list of projects, but an > ever-evolving ecosystem. > > Cheers, > > Ariel > > > > >> Best, >> >> Vanessa >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sat Aug 22 20:10:21 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sat, 22 Aug 2015 11:10:21 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Hi Ben, Yes perfectly said! There are two issues: 1) the baseurl being "" vs. "/" to work on circle vs. locally. This could be addressed with simply changing it programatically for circle testing. 2) the second problem is in the case of subpages. A url like /blog/pagename needs to be smart enough to look at itself, realize it's one level down from the base, and adjust paths appropriately. This is also important so we can have our pages like "contribute" have urls like nipy.github.io/contribute instead of nipy.github.io/contribute.html. The first is achieved via having a folder called "contribute" with index.html inside. Best, Vanessa On Sat, Aug 22, 2015 at 10:59 AM, Ben Cipollini wrote: > OK, I see the problem. > > Our static files are served relative to the base directory, which is a > _config.yaml setting (overridable from the command-line). > > If we set baseurl = "", then static files are referenced as relative URLs. > This works for pages served from the base directory (css/bootstrap.css > served from home.html will work), but needs a relative path change > (../css/bootstrap.css served for somedir/somefile.html). > > If we set base_directory to "/", then everything works locally, because > the root url (/) points to the home directory of the webpage. It doesn't > work on circle.ci, because the root url does NOT point to the home > directory of the webpage (of course not; it points to circle.ci). > > Now that I understand the problem, I'll look at the best way to do this. > Could simply be overriding baseurl to the proper thing in circle.ci (not > blank, but some deep path on the website), or embedding the proper relative > paths in the html when generating the pages. > > Ben > > On Sat, Aug 22, 2015 at 10:32 AM, Ben Cipollini wrote: > >> I'm trying to install Jekyll now, and will see if I can reproduce the >> problem. If so, I may have a few mins today to think about a solution. >> >> Vanessa, do you have a sense of why this is happening? Is the problem >> finding a solution to a problem you understand well, or is the problem >> investigating why this is happening to start with? >> >> Thanks! >> Ben >> >> On Fri, Aug 21, 2015 at 10:01 AM, vanessa sochat >> wrote: >> >>> Hi Matthew, >>> >>> I'm on board with Stefan's suggestion, I just stick to Poldracklab work >>> during the week and haven't done any new nipy site work. As I mentioned >>> earlier, I was hoping for some help with a more elegant solution to resolve >>> the current base url issue (please see my previous messages). If there >>> aren't any ideas, I will likely implement a very un-elegant / harder to >>> change solution, just to get something working, and only after that does it >>> make sense to give a go at github pages deployment. >>> >>> Best, >>> >>> Vanessa >>> >>> On Fri, Aug 21, 2015 at 9:55 AM, Matthew Brett >>> wrote: >>> >>>> Hi Vanessa, >>>> >>>> Thanks again for doing this. >>>> >>>> Have you got a github-pages build of this somewhere? Sorry if I >>>> missed it. I tried building locally, but I'm not confident that I'm >>>> getting what you expect to see. >>>> >>>> It would be good to have the mission statement somewhere, if y'all >>>> agree. >>>> >>>> Do you have any thoughts on Stefan's suggestion? >>>> >>>> Cheers, >>>> >>>> Matthew >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sat Aug 22 20:19:14 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sat, 22 Aug 2015 11:19:14 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Hi Ariel, Circle is needed to preview PRs. On your fork take a look at the individual blog pages - the path goes to the base and it is not found. And then on circle since the baseurl is "/" it would be quite broken looking. Right now adding a project would mean adding an entry to the data file , and then copying a template page for it (for example , you would just need the header and to name the page corresponding to its tag in the data file). The navigation, front page, and D3 are rendered from that file, but I didn't see a nice way to generate an entire page for the package. The reason I had originally chosen flask is because a person could just add a line to a tsv file, and the application would be smart enough to make the page if the user did not. I don't see a way to achieve that with these more syntax based frameworks. For the content and more tweaks to the design - let's hold off on jumping into that until we get this url issue worked out! I am totally game for adjusting the design, layout, content for whatever people think is best. Best, Vanessa On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: > Hi Vanessa, > > Sorry for the delay in responding. > > On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat > wrote: > >> Hi Everyone, >> >> Here is an update to the site. I've ported it into jekyll >> , and tested the template on >> iphone and computer (seems reasonable). I've also gotten it to render the >> artifacts on circle.ci , >> so we could preview PRs (Click "artifact" and then find home.html >> ). >> However, I've run into a bug with regard to absolute vs. relative paths - >> when you click the demo link above, the "posts" not being at the base url >> means they will not be linked or render correctly (for example, here is >> a link >> >> to a post on circle, and you won't see styling because the css/js links are >> broken) >> >> The site works perfectly given that we aren't serving it at a relative >> path, eg: >> >> jekyll serve --baseurl="/" >> >> And the challenge is finding a solution that will render locally, on >> github pages, and circle.ci, and what we need, I think, is some kind of >> liquid syntax that will detect when we are in a subfolder and render >> appropriately. I've been messing around with it for 7 hours today and can't >> figure it out, and I need to ask for help. Could someone else take a look? >> Likely someone with more experience than me with Jekyll could figure this >> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >> be to figure out this bug, get it onto a (test) github pages, tweak the >> details of the content, make proper documentation, and then release to >> official github pages. >> >> > Why do we need CircleCI here? I am actually not sure what the issue is, > but here's the site rendered through gh-pages on my fork of your repo: > > http://arokem.github.io/nipy-jekyll/ > > I did also add a Gemfile to the repo, and that might matter: I believe > Github pages serves jekyll through a call to "bundle exec jekyll serve" > (see here: https://help.github.com/articles/using-jekyll-with-pages/). > > One comment about the content: I would prefer to have a front page that > just states what this thing is, and the projects on a separate page. I > would like for it to be *super* easy to add projects. The whole idea is > that the NIPY community is not a static list of projects, but an > ever-evolving ecosystem. > > Cheers, > > Ariel > > > > >> Best, >> >> Vanessa >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sat Aug 22 20:22:01 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sat, 22 Aug 2015 11:22:01 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Exactly! That's how I got the frozen flask version up and running: http://vsoch.github.io/nipy/ On Sat, Aug 22, 2015 at 11:07 AM, Ariel Rokem wrote: > Just to be clear: > > On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: > >> Hi Vanessa, >> >> Sorry for the delay in responding. >> >> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >> wrote: >> >>> Hi Everyone, >>> >>> Here is an update to the site. I've ported it into jekyll >>> , and tested the template on >>> iphone and computer (seems reasonable). I've also gotten it to render the >>> artifacts on circle.ci , >>> so we could preview PRs (Click "artifact" and then find home.html >>> ). >>> However, I've run into a bug with regard to absolute vs. relative paths - >>> when you click the demo link above, the "posts" not being at the base url >>> means they will not be linked or render correctly (for example, here is >>> a link >>> >>> to a post on circle, and you won't see styling because the css/js links are >>> broken) >>> >>> The site works perfectly given that we aren't serving it at a relative >>> path, eg: >>> >>> jekyll serve --baseurl="/" >>> >>> And the challenge is finding a solution that will render locally, on >>> github pages, and circle.ci, and what we need, I think, is some kind of >>> liquid syntax that will detect when we are in a subfolder and render >>> appropriately. I've been messing around with it for 7 hours today and can't >>> figure it out, and I need to ask for help. Could someone else take a look? >>> Likely someone with more experience than me with Jekyll could figure this >>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>> be to figure out this bug, get it onto a (test) github pages, tweak the >>> details of the content, make proper documentation, and then release to >>> official github pages. >>> >>> >> Why do we need CircleCI here? I am actually not sure what the issue is, >> but here's the site rendered through gh-pages on my fork of your repo: >> >> http://arokem.github.io/nipy-jekyll/ >> >> > For this to happen, the content has to be on a branch named `gh-pages` in > the repo. A jekyll build is triggered if and only if content is pushed to a > branch with that exact name! > > Ariel > > > >> I did also add a Gemfile to the repo, and that might matter: I believe >> Github pages serves jekyll through a call to "bundle exec jekyll serve" >> (see here: https://help.github.com/articles/using-jekyll-with-pages/). >> >> One comment about the content: I would prefer to have a front page that >> just states what this thing is, and the projects on a separate page. I >> would like for it to be *super* easy to add projects. The whole idea is >> that the NIPY community is not a static list of projects, but an >> ever-evolving ecosystem. >> >> Cheers, >> >> Ariel >> >> >> >> >>> Best, >>> >>> Vanessa >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sat Aug 22 20:24:05 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sat, 22 Aug 2015 11:24:05 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Oops, I spoke too soon. Sounds like circle.ci is very important. :) Vanessa, you had an idea for an "ugly" solution for the original issue? May I ask what that is? Looks like others are simply using --baseurl="" on the command-line. Thanks, Ben On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat wrote: > Hi Ariel, > > Circle is needed to preview PRs. > > On your fork take a look at the individual blog pages - the path goes to > the base and it is not found. And then on circle since the baseurl is "/" > it would be quite broken looking. > > Right now adding a project would mean adding an entry to the data file > , > and then copying a template page for it (for example > , you would > just need the header and to name the page corresponding to its tag in the > data file). The navigation, front page, and D3 are rendered from that file, > but I didn't see a nice way to generate an entire page for the package. The > reason I had originally chosen flask is because a person could just add a > line to a tsv file, and the application would be smart enough to make the > page if the user did not. I don't see a way to achieve that with these more > syntax based frameworks. > > For the content and more tweaks to the design - let's hold off on jumping > into that until we get this url issue worked out! I am totally game for > adjusting the design, layout, content for whatever people think is best. > > Best, > > Vanessa > > On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: > >> Hi Vanessa, >> >> Sorry for the delay in responding. >> >> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >> wrote: >> >>> Hi Everyone, >>> >>> Here is an update to the site. I've ported it into jekyll >>> , and tested the template on >>> iphone and computer (seems reasonable). I've also gotten it to render the >>> artifacts on circle.ci , >>> so we could preview PRs (Click "artifact" and then find home.html >>> ). >>> However, I've run into a bug with regard to absolute vs. relative paths - >>> when you click the demo link above, the "posts" not being at the base url >>> means they will not be linked or render correctly (for example, here is >>> a link >>> >>> to a post on circle, and you won't see styling because the css/js links are >>> broken) >>> >>> The site works perfectly given that we aren't serving it at a relative >>> path, eg: >>> >>> jekyll serve --baseurl="/" >>> >>> And the challenge is finding a solution that will render locally, on >>> github pages, and circle.ci, and what we need, I think, is some kind of >>> liquid syntax that will detect when we are in a subfolder and render >>> appropriately. I've been messing around with it for 7 hours today and can't >>> figure it out, and I need to ask for help. Could someone else take a look? >>> Likely someone with more experience than me with Jekyll could figure this >>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>> be to figure out this bug, get it onto a (test) github pages, tweak the >>> details of the content, make proper documentation, and then release to >>> official github pages. >>> >>> >> Why do we need CircleCI here? I am actually not sure what the issue is, >> but here's the site rendered through gh-pages on my fork of your repo: >> >> http://arokem.github.io/nipy-jekyll/ >> >> I did also add a Gemfile to the repo, and that might matter: I believe >> Github pages serves jekyll through a call to "bundle exec jekyll serve" >> (see here: https://help.github.com/articles/using-jekyll-with-pages/). >> >> One comment about the content: I would prefer to have a front page that >> just states what this thing is, and the projects on a separate page. I >> would like for it to be *super* easy to add projects. The whole idea is >> that the NIPY community is not a static list of projects, but an >> ever-evolving ecosystem. >> >> Cheers, >> >> Ariel >> >> >> >> >>> Best, >>> >>> Vanessa >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sat Aug 22 20:34:49 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sat, 22 Aug 2015 11:34:49 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: The "ugly" solution is to use different templates for the pages not at the base url, and then you can just hard code the page one level up. For example, in the header : a path currently looks like: and for subpages, we would make a new header_subpage.html with a path like: But then when you change anything about the design, you have to change it in two places. I started implementing this, felt sick to my stomach at how awful the idea was, and completely converted everything back :) I think it could be possible to use this weird language so that all pages detect their level. For example, take a look here at a solution I figured out using the syntax - but it fails in that the if statement is hard coded. Also take a look here - for the posts we can get the URLs programatically, but I wasn't sure how to do that for "non-post" pages. On Sat, Aug 22, 2015 at 11:24 AM, Ben Cipollini wrote: > Oops, I spoke too soon. Sounds like circle.ci is very important. :) > > Vanessa, you had an idea for an "ugly" solution for the original issue? > May I ask what that is? Looks like others are simply using --baseurl="" on > the command-line. > > Thanks, > Ben > > > On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat > wrote: > >> Hi Ariel, >> >> Circle is needed to preview PRs. >> >> On your fork take a look at the individual blog pages - the path goes to >> the base and it is not found. And then on circle since the baseurl is "/" >> it would be quite broken looking. >> >> Right now adding a project would mean adding an entry to the data file >> , >> and then copying a template page for it (for example >> , you would >> just need the header and to name the page corresponding to its tag in the >> data file). The navigation, front page, and D3 are rendered from that file, >> but I didn't see a nice way to generate an entire page for the package. The >> reason I had originally chosen flask is because a person could just add a >> line to a tsv file, and the application would be smart enough to make the >> page if the user did not. I don't see a way to achieve that with these more >> syntax based frameworks. >> >> For the content and more tweaks to the design - let's hold off on jumping >> into that until we get this url issue worked out! I am totally game for >> adjusting the design, layout, content for whatever people think is best. >> >> Best, >> >> Vanessa >> >> On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: >> >>> Hi Vanessa, >>> >>> Sorry for the delay in responding. >>> >>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>> wrote: >>> >>>> Hi Everyone, >>>> >>>> Here is an update to the site. I've ported it into jekyll >>>> , and tested the template on >>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>> artifacts on circle.ci , >>>> so we could preview PRs (Click "artifact" and then find home.html >>>> ). >>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>> when you click the demo link above, the "posts" not being at the base url >>>> means they will not be linked or render correctly (for example, here >>>> is a link >>>> >>>> to a post on circle, and you won't see styling because the css/js links are >>>> broken) >>>> >>>> The site works perfectly given that we aren't serving it at a relative >>>> path, eg: >>>> >>>> jekyll serve --baseurl="/" >>>> >>>> And the challenge is finding a solution that will render locally, on >>>> github pages, and circle.ci, and what we need, I think, is some kind >>>> of liquid syntax that will detect when we are in a subfolder and render >>>> appropriately. I've been messing around with it for 7 hours today and can't >>>> figure it out, and I need to ask for help. Could someone else take a look? >>>> Likely someone with more experience than me with Jekyll could figure this >>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>> details of the content, make proper documentation, and then release to >>>> official github pages. >>>> >>>> >>> Why do we need CircleCI here? I am actually not sure what the issue is, >>> but here's the site rendered through gh-pages on my fork of your repo: >>> >>> http://arokem.github.io/nipy-jekyll/ >>> >>> I did also add a Gemfile to the repo, and that might matter: I believe >>> Github pages serves jekyll through a call to "bundle exec jekyll serve" >>> (see here: https://help.github.com/articles/using-jekyll-with-pages/). >>> >>> One comment about the content: I would prefer to have a front page that >>> just states what this thing is, and the projects on a separate page. I >>> would like for it to be *super* easy to add projects. The whole idea is >>> that the NIPY community is not a static list of projects, but an >>> ever-evolving ecosystem. >>> >>> Cheers, >>> >>> Ariel >>> >>> >>> >>> >>>> Best, >>>> >>>> Vanessa >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sat Aug 22 20:42:29 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sat, 22 Aug 2015 11:42:29 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Ok, yeah. That's not acceptable :) This is very similar to Django, which I know well. I'll think over a solution. Really, there's got to be a way to pass the baseurl from github, circle.ci, etc. Will investigate further. On Sat, Aug 22, 2015 at 11:34 AM, vanessa sochat wrote: > The "ugly" solution is to use different templates for the pages not at the > base url, and then you can just hard code the page one level up. For > example, in the header > : > > a path currently looks like: > > > > and for subpages, we would make a new header_subpage.html with a path like: > > > > But then when you change anything about the design, you have to change it > in two places. I started implementing this, felt sick to my stomach at how > awful the idea was, and completely converted everything back :) I think it > could be possible to use this weird language > so that all pages detect their level. For example, take a look here > > at a solution I figured out using the syntax - but it fails in that the if > statement is hard coded. > > Also take a look here > > - for the posts we can get the URLs programatically, but I wasn't sure how > to do that for "non-post" pages. > > > On Sat, Aug 22, 2015 at 11:24 AM, Ben Cipollini wrote: > >> Oops, I spoke too soon. Sounds like circle.ci is very important. :) >> >> Vanessa, you had an idea for an "ugly" solution for the original issue? >> May I ask what that is? Looks like others are simply using --baseurl="" on >> the command-line. >> >> Thanks, >> Ben >> >> >> On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat >> wrote: >> >>> Hi Ariel, >>> >>> Circle is needed to preview PRs. >>> >>> On your fork take a look at the individual blog pages - the path goes to >>> the base and it is not found. And then on circle since the baseurl is "/" >>> it would be quite broken looking. >>> >>> Right now adding a project would mean adding an entry to the data file >>> , >>> and then copying a template page for it (for example >>> , you would >>> just need the header and to name the page corresponding to its tag in the >>> data file). The navigation, front page, and D3 are rendered from that file, >>> but I didn't see a nice way to generate an entire page for the package. The >>> reason I had originally chosen flask is because a person could just add a >>> line to a tsv file, and the application would be smart enough to make the >>> page if the user did not. I don't see a way to achieve that with these more >>> syntax based frameworks. >>> >>> For the content and more tweaks to the design - let's hold off on >>> jumping into that until we get this url issue worked out! I am totally game >>> for adjusting the design, layout, content for whatever people think is best. >>> >>> Best, >>> >>> Vanessa >>> >>> On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: >>> >>>> Hi Vanessa, >>>> >>>> Sorry for the delay in responding. >>>> >>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>>> wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> Here is an update to the site. I've ported it into jekyll >>>>> , and tested the template on >>>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>>> artifacts on circle.ci , >>>>> so we could preview PRs (Click "artifact" and then find home.html >>>>> ). >>>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>>> when you click the demo link above, the "posts" not being at the base url >>>>> means they will not be linked or render correctly (for example, here >>>>> is a link >>>>> >>>>> to a post on circle, and you won't see styling because the css/js links are >>>>> broken) >>>>> >>>>> The site works perfectly given that we aren't serving it at a relative >>>>> path, eg: >>>>> >>>>> jekyll serve --baseurl="/" >>>>> >>>>> And the challenge is finding a solution that will render locally, on >>>>> github pages, and circle.ci, and what we need, I think, is some kind >>>>> of liquid syntax that will detect when we are in a subfolder and render >>>>> appropriately. I've been messing around with it for 7 hours today and can't >>>>> figure it out, and I need to ask for help. Could someone else take a look? >>>>> Likely someone with more experience than me with Jekyll could figure this >>>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>>> details of the content, make proper documentation, and then release to >>>>> official github pages. >>>>> >>>>> >>>> Why do we need CircleCI here? I am actually not sure what the issue is, >>>> but here's the site rendered through gh-pages on my fork of your repo: >>>> >>>> http://arokem.github.io/nipy-jekyll/ >>>> >>>> I did also add a Gemfile to the repo, and that might matter: I believe >>>> Github pages serves jekyll through a call to "bundle exec jekyll serve" >>>> (see here: https://help.github.com/articles/using-jekyll-with-pages/). >>>> >>>> One comment about the content: I would prefer to have a front page that >>>> just states what this thing is, and the projects on a separate page. I >>>> would like for it to be *super* easy to add projects. The whole idea is >>>> that the NIPY community is not a static list of projects, but an >>>> ever-evolving ecosystem. >>>> >>>> Cheers, >>>> >>>> Ariel >>>> >>>> >>>> >>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sat Aug 22 20:47:07 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sat, 22 Aug 2015 11:47:07 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: Awesome! Thanks so much for your help Ben, we will figure it out :O) I'm working on a few different projects today but will have some time tomorrow for nipy. Keep me posted. On Sat, Aug 22, 2015 at 11:42 AM, Ben Cipollini wrote: > Ok, yeah. That's not acceptable :) This is very similar to Django, which I > know well. I'll think over a solution. > > Really, there's got to be a way to pass the baseurl from github, circle.ci, > etc. Will investigate further. > > On Sat, Aug 22, 2015 at 11:34 AM, vanessa sochat > wrote: > >> The "ugly" solution is to use different templates for the pages not at >> the base url, and then you can just hard code the page one level up. For >> example, in the header >> : >> >> a path currently looks like: >> >> >> >> and for subpages, we would make a new header_subpage.html with a path >> like: >> >> >> >> But then when you change anything about the design, you have to change it >> in two places. I started implementing this, felt sick to my stomach at how >> awful the idea was, and completely converted everything back :) I think it >> could be possible to use this weird language >> so that all pages detect their level. For example, take a look here >> >> at a solution I figured out using the syntax - but it fails in that the if >> statement is hard coded. >> >> Also take a look here >> >> - for the posts we can get the URLs programatically, but I wasn't sure how >> to do that for "non-post" pages. >> >> >> On Sat, Aug 22, 2015 at 11:24 AM, Ben Cipollini >> wrote: >> >>> Oops, I spoke too soon. Sounds like circle.ci is very important. :) >>> >>> Vanessa, you had an idea for an "ugly" solution for the original issue? >>> May I ask what that is? Looks like others are simply using --baseurl="" on >>> the command-line. >>> >>> Thanks, >>> Ben >>> >>> >>> On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat >>> wrote: >>> >>>> Hi Ariel, >>>> >>>> Circle is needed to preview PRs. >>>> >>>> On your fork take a look at the individual blog pages - the path goes >>>> to the base and it is not found. And then on circle since the baseurl is >>>> "/" it would be quite broken looking. >>>> >>>> Right now adding a project would mean adding an entry to the data file >>>> , >>>> and then copying a template page for it (for example >>>> , you would >>>> just need the header and to name the page corresponding to its tag in the >>>> data file). The navigation, front page, and D3 are rendered from that file, >>>> but I didn't see a nice way to generate an entire page for the package. The >>>> reason I had originally chosen flask is because a person could just add a >>>> line to a tsv file, and the application would be smart enough to make the >>>> page if the user did not. I don't see a way to achieve that with these more >>>> syntax based frameworks. >>>> >>>> For the content and more tweaks to the design - let's hold off on >>>> jumping into that until we get this url issue worked out! I am totally game >>>> for adjusting the design, layout, content for whatever people think is best. >>>> >>>> Best, >>>> >>>> Vanessa >>>> >>>> On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: >>>> >>>>> Hi Vanessa, >>>>> >>>>> Sorry for the delay in responding. >>>>> >>>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>>>> wrote: >>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> Here is an update to the site. I've ported it into jekyll >>>>>> , and tested the template on >>>>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>>>> artifacts on circle.ci , >>>>>> so we could preview PRs (Click "artifact" and then find home.html >>>>>> ). >>>>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>>>> when you click the demo link above, the "posts" not being at the base url >>>>>> means they will not be linked or render correctly (for example, here >>>>>> is a link >>>>>> >>>>>> to a post on circle, and you won't see styling because the css/js links are >>>>>> broken) >>>>>> >>>>>> The site works perfectly given that we aren't serving it at a >>>>>> relative path, eg: >>>>>> >>>>>> jekyll serve --baseurl="/" >>>>>> >>>>>> And the challenge is finding a solution that will render locally, on >>>>>> github pages, and circle.ci, and what we need, I think, is some kind >>>>>> of liquid syntax that will detect when we are in a subfolder and render >>>>>> appropriately. I've been messing around with it for 7 hours today and can't >>>>>> figure it out, and I need to ask for help. Could someone else take a look? >>>>>> Likely someone with more experience than me with Jekyll could figure this >>>>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>>>> details of the content, make proper documentation, and then release to >>>>>> official github pages. >>>>>> >>>>>> >>>>> Why do we need CircleCI here? I am actually not sure what the issue >>>>> is, but here's the site rendered through gh-pages on my fork of your repo: >>>>> >>>>> http://arokem.github.io/nipy-jekyll/ >>>>> >>>>> I did also add a Gemfile to the repo, and that might matter: I believe >>>>> Github pages serves jekyll through a call to "bundle exec jekyll serve" >>>>> (see here: https://help.github.com/articles/using-jekyll-with-pages/ >>>>> ). >>>>> >>>>> One comment about the content: I would prefer to have a front page >>>>> that just states what this thing is, and the projects on a separate page. I >>>>> would like for it to be *super* easy to add projects. The whole idea is >>>>> that the NIPY community is not a static list of projects, but an >>>>> ever-evolving ecosystem. >>>>> >>>>> Cheers, >>>>> >>>>> Ariel >>>>> >>>>> >>>>> >>>>> >>>>>> Best, >>>>>> >>>>>> Vanessa >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sat Aug 22 20:20:52 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sat, 22 Aug 2015 11:20:52 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Thanks Ariel for the tips! Seems like we can scrap circle.ci. However, rendering to the github pages breaks all links currently. To resolve the original issue (having to specify a --baseurl when serving jekyll locally), it looks like this is just the way it is. See: http://jekyllrb.com/docs/github-pages/ Will look at the broken urls when rendered on github pages now. Ben On Sat, Aug 22, 2015 at 11:10 AM, vanessa sochat wrote: > Hi Ben, > > Yes perfectly said! There are two issues: > > 1) the baseurl being "" vs. "/" to work on circle vs. locally. This could > be addressed with simply changing it programatically for circle testing. > > 2) the second problem is in the case of subpages. A url like > /blog/pagename needs to be smart enough to look at itself, realize it's one > level down from the base, and adjust paths appropriately. This is also > important so we can have our pages like "contribute" have urls like > nipy.github.io/contribute instead of nipy.github.io/contribute.html. The > first is achieved via having a folder called "contribute" with index.html > inside. > > Best, > > Vanessa > > On Sat, Aug 22, 2015 at 10:59 AM, Ben Cipollini wrote: > >> OK, I see the problem. >> >> Our static files are served relative to the base directory, which is a >> _config.yaml setting (overridable from the command-line). >> >> If we set baseurl = "", then static files are referenced as relative >> URLs. This works for pages served from the base directory >> (css/bootstrap.css served from home.html will work), but needs a relative >> path change (../css/bootstrap.css served for somedir/somefile.html). >> >> If we set base_directory to "/", then everything works locally, because >> the root url (/) points to the home directory of the webpage. It doesn't >> work on circle.ci, because the root url does NOT point to the home >> directory of the webpage (of course not; it points to circle.ci). >> >> Now that I understand the problem, I'll look at the best way to do this. >> Could simply be overriding baseurl to the proper thing in circle.ci (not >> blank, but some deep path on the website), or embedding the proper relative >> paths in the html when generating the pages. >> >> Ben >> >> On Sat, Aug 22, 2015 at 10:32 AM, Ben Cipollini >> wrote: >> >>> I'm trying to install Jekyll now, and will see if I can reproduce the >>> problem. If so, I may have a few mins today to think about a solution. >>> >>> Vanessa, do you have a sense of why this is happening? Is the problem >>> finding a solution to a problem you understand well, or is the problem >>> investigating why this is happening to start with? >>> >>> Thanks! >>> Ben >>> >>> On Fri, Aug 21, 2015 at 10:01 AM, vanessa sochat >>> wrote: >>> >>>> Hi Matthew, >>>> >>>> I'm on board with Stefan's suggestion, I just stick to Poldracklab work >>>> during the week and haven't done any new nipy site work. As I mentioned >>>> earlier, I was hoping for some help with a more elegant solution to resolve >>>> the current base url issue (please see my previous messages). If there >>>> aren't any ideas, I will likely implement a very un-elegant / harder to >>>> change solution, just to get something working, and only after that does it >>>> make sense to give a go at github pages deployment. >>>> >>>> Best, >>>> >>>> Vanessa >>>> >>>> On Fri, Aug 21, 2015 at 9:55 AM, Matthew Brett >>> > wrote: >>>> >>>>> Hi Vanessa, >>>>> >>>>> Thanks again for doing this. >>>>> >>>>> Have you got a github-pages build of this somewhere? Sorry if I >>>>> missed it. I tried building locally, but I'm not confident that I'm >>>>> getting what you expect to see. >>>>> >>>>> It would be good to have the mission statement somewhere, if y'all >>>>> agree. >>>>> >>>>> Do you have any thoughts on Stefan's suggestion? >>>>> >>>>> Cheers, >>>>> >>>>> Matthew >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Sat Aug 22 21:12:11 2015 From: arokem at gmail.com (Ariel Rokem) Date: Sat, 22 Aug 2015 12:12:11 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: On Sat, Aug 22, 2015 at 11:34 AM, vanessa sochat wrote: > The "ugly" solution is to use different templates for the pages not at the > base url, and then you can just hard code the page one level up. For > example, in the header > : > > a path currently looks like: > > > > and for subpages, we would make a new header_subpage.html with a path like: > > > > But then when you change anything about the design, you have to change it > in two places. I started implementing this, felt sick to my stomach at how > awful the idea was, and completely converted everything back :) I think it > could be possible to use this weird language > so that all pages detect their level. For example, take a look here > > at a solution I figured out using the syntax - but it fails in that the if > statement is hard coded. > > Also take a look here > > - for the posts we can get the URLs programatically, but I wasn't sure how > to do that for "non-post" pages. > > > I am also thinking in this direction. Maybe we can have different baseurl configs for different things? Something along these lines: https://github.com/arokem/nipy-jekyll/commit/9f2b6be741b20b779321dc2739fc6c6efa1a3bac Still not working, but something like this might work. Once we settle on a design, I don't expect that we will have many changes there. I think that most PRs will be with text content, and not to things of this sort, so I am not too worried about the potential ugliness of having to change many things in many places for that. > On Sat, Aug 22, 2015 at 11:24 AM, Ben Cipollini wrote: > >> Oops, I spoke too soon. Sounds like circle.ci is very important. :) >> >> Vanessa, you had an idea for an "ugly" solution for the original issue? >> May I ask what that is? Looks like others are simply using --baseurl="" on >> the command-line. >> >> Thanks, >> Ben >> >> >> On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat >> wrote: >> >>> Hi Ariel, >>> >>> Circle is needed to preview PRs. >>> >>> On your fork take a look at the individual blog pages - the path goes to >>> the base and it is not found. And then on circle since the baseurl is "/" >>> it would be quite broken looking. >>> >>> Right now adding a project would mean adding an entry to the data file >>> , >>> and then copying a template page for it (for example >>> , you would >>> just need the header and to name the page corresponding to its tag in the >>> data file). The navigation, front page, and D3 are rendered from that file, >>> but I didn't see a nice way to generate an entire page for the package. The >>> reason I had originally chosen flask is because a person could just add a >>> line to a tsv file, and the application would be smart enough to make the >>> page if the user did not. I don't see a way to achieve that with these more >>> syntax based frameworks. >>> >>> For the content and more tweaks to the design - let's hold off on >>> jumping into that until we get this url issue worked out! I am totally game >>> for adjusting the design, layout, content for whatever people think is best. >>> >>> Best, >>> >>> Vanessa >>> >>> On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: >>> >>>> Hi Vanessa, >>>> >>>> Sorry for the delay in responding. >>>> >>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>>> wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> Here is an update to the site. I've ported it into jekyll >>>>> , and tested the template on >>>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>>> artifacts on circle.ci , >>>>> so we could preview PRs (Click "artifact" and then find home.html >>>>> ). >>>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>>> when you click the demo link above, the "posts" not being at the base url >>>>> means they will not be linked or render correctly (for example, here >>>>> is a link >>>>> >>>>> to a post on circle, and you won't see styling because the css/js links are >>>>> broken) >>>>> >>>>> The site works perfectly given that we aren't serving it at a relative >>>>> path, eg: >>>>> >>>>> jekyll serve --baseurl="/" >>>>> >>>>> And the challenge is finding a solution that will render locally, on >>>>> github pages, and circle.ci, and what we need, I think, is some kind >>>>> of liquid syntax that will detect when we are in a subfolder and render >>>>> appropriately. I've been messing around with it for 7 hours today and can't >>>>> figure it out, and I need to ask for help. Could someone else take a look? >>>>> Likely someone with more experience than me with Jekyll could figure this >>>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>>> details of the content, make proper documentation, and then release to >>>>> official github pages. >>>>> >>>>> >>>> Why do we need CircleCI here? I am actually not sure what the issue is, >>>> but here's the site rendered through gh-pages on my fork of your repo: >>>> >>>> http://arokem.github.io/nipy-jekyll/ >>>> >>>> I did also add a Gemfile to the repo, and that might matter: I believe >>>> Github pages serves jekyll through a call to "bundle exec jekyll serve" >>>> (see here: https://help.github.com/articles/using-jekyll-with-pages/). >>>> >>>> One comment about the content: I would prefer to have a front page that >>>> just states what this thing is, and the projects on a separate page. I >>>> would like for it to be *super* easy to add projects. The whole idea is >>>> that the NIPY community is not a static list of projects, but an >>>> ever-evolving ecosystem. >>>> >>>> Cheers, >>>> >>>> Ariel >>>> >>>> >>>> >>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sat Aug 22 21:19:45 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sat, 22 Aug 2015 12:19:45 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: That's a good idea to specify the urls in the config file - I think that could work! However we still need a consistent way to preview PRs, and I'm not quite ready to just throw circle.ci away. I think it would be pretty reasonable to change those base URLs in the config in the circle with a line here . On Sat, Aug 22, 2015 at 12:12 PM, Ariel Rokem wrote: > > On Sat, Aug 22, 2015 at 11:34 AM, vanessa sochat > wrote: > >> The "ugly" solution is to use different templates for the pages not at >> the base url, and then you can just hard code the page one level up. For >> example, in the header >> : >> >> a path currently looks like: >> >> >> >> and for subpages, we would make a new header_subpage.html with a path >> like: >> >> >> >> But then when you change anything about the design, you have to change it >> in two places. I started implementing this, felt sick to my stomach at how >> awful the idea was, and completely converted everything back :) I think it >> could be possible to use this weird language >> so that all pages detect their level. For example, take a look here >> >> at a solution I figured out using the syntax - but it fails in that the if >> statement is hard coded. >> >> Also take a look here >> >> - for the posts we can get the URLs programatically, but I wasn't sure how >> to do that for "non-post" pages. >> >> >> > I am also thinking in this direction. Maybe we can have different baseurl > configs for different things? Something along these lines: > > > https://github.com/arokem/nipy-jekyll/commit/9f2b6be741b20b779321dc2739fc6c6efa1a3bac > > Still not working, but something like this might work. Once we settle on a > design, I don't expect that we will have many changes there. I think that > most PRs will be with text content, and not to things of this sort, so I am > not too worried about the potential ugliness of having to change many > things in many places for that. > > > > > >> On Sat, Aug 22, 2015 at 11:24 AM, Ben Cipollini >> wrote: >> >>> Oops, I spoke too soon. Sounds like circle.ci is very important. :) >>> >>> Vanessa, you had an idea for an "ugly" solution for the original issue? >>> May I ask what that is? Looks like others are simply using --baseurl="" on >>> the command-line. >>> >>> Thanks, >>> Ben >>> >>> >>> On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat >>> wrote: >>> >>>> Hi Ariel, >>>> >>>> Circle is needed to preview PRs. >>>> >>>> On your fork take a look at the individual blog pages - the path goes >>>> to the base and it is not found. And then on circle since the baseurl is >>>> "/" it would be quite broken looking. >>>> >>>> Right now adding a project would mean adding an entry to the data file >>>> , >>>> and then copying a template page for it (for example >>>> , you would >>>> just need the header and to name the page corresponding to its tag in the >>>> data file). The navigation, front page, and D3 are rendered from that file, >>>> but I didn't see a nice way to generate an entire page for the package. The >>>> reason I had originally chosen flask is because a person could just add a >>>> line to a tsv file, and the application would be smart enough to make the >>>> page if the user did not. I don't see a way to achieve that with these more >>>> syntax based frameworks. >>>> >>>> For the content and more tweaks to the design - let's hold off on >>>> jumping into that until we get this url issue worked out! I am totally game >>>> for adjusting the design, layout, content for whatever people think is best. >>>> >>>> Best, >>>> >>>> Vanessa >>>> >>>> On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: >>>> >>>>> Hi Vanessa, >>>>> >>>>> Sorry for the delay in responding. >>>>> >>>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>>>> wrote: >>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> Here is an update to the site. I've ported it into jekyll >>>>>> , and tested the template on >>>>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>>>> artifacts on circle.ci , >>>>>> so we could preview PRs (Click "artifact" and then find home.html >>>>>> ). >>>>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>>>> when you click the demo link above, the "posts" not being at the base url >>>>>> means they will not be linked or render correctly (for example, here >>>>>> is a link >>>>>> >>>>>> to a post on circle, and you won't see styling because the css/js links are >>>>>> broken) >>>>>> >>>>>> The site works perfectly given that we aren't serving it at a >>>>>> relative path, eg: >>>>>> >>>>>> jekyll serve --baseurl="/" >>>>>> >>>>>> And the challenge is finding a solution that will render locally, on >>>>>> github pages, and circle.ci, and what we need, I think, is some kind >>>>>> of liquid syntax that will detect when we are in a subfolder and render >>>>>> appropriately. I've been messing around with it for 7 hours today and can't >>>>>> figure it out, and I need to ask for help. Could someone else take a look? >>>>>> Likely someone with more experience than me with Jekyll could figure this >>>>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>>>> details of the content, make proper documentation, and then release to >>>>>> official github pages. >>>>>> >>>>>> >>>>> Why do we need CircleCI here? I am actually not sure what the issue >>>>> is, but here's the site rendered through gh-pages on my fork of your repo: >>>>> >>>>> http://arokem.github.io/nipy-jekyll/ >>>>> >>>>> I did also add a Gemfile to the repo, and that might matter: I believe >>>>> Github pages serves jekyll through a call to "bundle exec jekyll serve" >>>>> (see here: https://help.github.com/articles/using-jekyll-with-pages/ >>>>> ). >>>>> >>>>> One comment about the content: I would prefer to have a front page >>>>> that just states what this thing is, and the projects on a separate page. I >>>>> would like for it to be *super* easy to add projects. The whole idea is >>>>> that the NIPY community is not a static list of projects, but an >>>>> ever-evolving ecosystem. >>>>> >>>>> Cheers, >>>>> >>>>> Ariel >>>>> >>>>> >>>>> >>>>> >>>>>> Best, >>>>>> >>>>>> Vanessa >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sat Aug 22 21:56:13 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sat, 22 Aug 2015 12:56:13 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: @Ariel I don't think that change solves anything different than simply setting the baseurl to /nipy-jekyll/ (note: I would avoid the fully qualified URL, it would unintentionally make a circle.ci version of the site, or a locally built one without specifying an overriding baseurl, to pull from an unexpected source.) The problem is (at least as I see it), we need different baseurl values for different build situations (gh-pages, circle.ci, local). On Sat, Aug 22, 2015 at 12:12 PM, Ariel Rokem wrote: > > On Sat, Aug 22, 2015 at 11:34 AM, vanessa sochat > wrote: > >> The "ugly" solution is to use different templates for the pages not at >> the base url, and then you can just hard code the page one level up. For >> example, in the header >> : >> >> a path currently looks like: >> >> >> >> and for subpages, we would make a new header_subpage.html with a path >> like: >> >> >> >> But then when you change anything about the design, you have to change it >> in two places. I started implementing this, felt sick to my stomach at how >> awful the idea was, and completely converted everything back :) I think it >> could be possible to use this weird language >> so that all pages detect their level. For example, take a look here >> >> at a solution I figured out using the syntax - but it fails in that the if >> statement is hard coded. >> >> Also take a look here >> >> - for the posts we can get the URLs programatically, but I wasn't sure how >> to do that for "non-post" pages. >> >> >> > I am also thinking in this direction. Maybe we can have different baseurl > configs for different things? Something along these lines: > > > https://github.com/arokem/nipy-jekyll/commit/9f2b6be741b20b779321dc2739fc6c6efa1a3bac > > Still not working, but something like this might work. Once we settle on a > design, I don't expect that we will have many changes there. I think that > most PRs will be with text content, and not to things of this sort, so I am > not too worried about the potential ugliness of having to change many > things in many places for that. > > > > > >> On Sat, Aug 22, 2015 at 11:24 AM, Ben Cipollini >> wrote: >> >>> Oops, I spoke too soon. Sounds like circle.ci is very important. :) >>> >>> Vanessa, you had an idea for an "ugly" solution for the original issue? >>> May I ask what that is? Looks like others are simply using --baseurl="" on >>> the command-line. >>> >>> Thanks, >>> Ben >>> >>> >>> On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat >>> wrote: >>> >>>> Hi Ariel, >>>> >>>> Circle is needed to preview PRs. >>>> >>>> On your fork take a look at the individual blog pages - the path goes >>>> to the base and it is not found. And then on circle since the baseurl is >>>> "/" it would be quite broken looking. >>>> >>>> Right now adding a project would mean adding an entry to the data file >>>> , >>>> and then copying a template page for it (for example >>>> , you would >>>> just need the header and to name the page corresponding to its tag in the >>>> data file). The navigation, front page, and D3 are rendered from that file, >>>> but I didn't see a nice way to generate an entire page for the package. The >>>> reason I had originally chosen flask is because a person could just add a >>>> line to a tsv file, and the application would be smart enough to make the >>>> page if the user did not. I don't see a way to achieve that with these more >>>> syntax based frameworks. >>>> >>>> For the content and more tweaks to the design - let's hold off on >>>> jumping into that until we get this url issue worked out! I am totally game >>>> for adjusting the design, layout, content for whatever people think is best. >>>> >>>> Best, >>>> >>>> Vanessa >>>> >>>> On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem wrote: >>>> >>>>> Hi Vanessa, >>>>> >>>>> Sorry for the delay in responding. >>>>> >>>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>>>> wrote: >>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> Here is an update to the site. I've ported it into jekyll >>>>>> , and tested the template on >>>>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>>>> artifacts on circle.ci , >>>>>> so we could preview PRs (Click "artifact" and then find home.html >>>>>> ). >>>>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>>>> when you click the demo link above, the "posts" not being at the base url >>>>>> means they will not be linked or render correctly (for example, here >>>>>> is a link >>>>>> >>>>>> to a post on circle, and you won't see styling because the css/js links are >>>>>> broken) >>>>>> >>>>>> The site works perfectly given that we aren't serving it at a >>>>>> relative path, eg: >>>>>> >>>>>> jekyll serve --baseurl="/" >>>>>> >>>>>> And the challenge is finding a solution that will render locally, on >>>>>> github pages, and circle.ci, and what we need, I think, is some kind >>>>>> of liquid syntax that will detect when we are in a subfolder and render >>>>>> appropriately. I've been messing around with it for 7 hours today and can't >>>>>> figure it out, and I need to ask for help. Could someone else take a look? >>>>>> Likely someone with more experience than me with Jekyll could figure this >>>>>> out in a heartbeat (Ariel?) The plan right now, I'd like to propose, would >>>>>> be to figure out this bug, get it onto a (test) github pages, tweak the >>>>>> details of the content, make proper documentation, and then release to >>>>>> official github pages. >>>>>> >>>>>> >>>>> Why do we need CircleCI here? I am actually not sure what the issue >>>>> is, but here's the site rendered through gh-pages on my fork of your repo: >>>>> >>>>> http://arokem.github.io/nipy-jekyll/ >>>>> >>>>> I did also add a Gemfile to the repo, and that might matter: I believe >>>>> Github pages serves jekyll through a call to "bundle exec jekyll serve" >>>>> (see here: https://help.github.com/articles/using-jekyll-with-pages/ >>>>> ). >>>>> >>>>> One comment about the content: I would prefer to have a front page >>>>> that just states what this thing is, and the projects on a separate page. I >>>>> would like for it to be *super* easy to add projects. The whole idea is >>>>> that the NIPY community is not a static list of projects, but an >>>>> ever-evolving ecosystem. >>>>> >>>>> Cheers, >>>>> >>>>> Ariel >>>>> >>>>> >>>>> >>>>> >>>>>> Best, >>>>>> >>>>>> Vanessa >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sun Aug 23 02:08:54 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sat, 22 Aug 2015 17:08:54 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: Message-ID: My current strategy is to use Jekyll plugins to try and set either the site.baseurl, or a "baseurl" variable, based on, say, environment variables (circle.ci) or the site object (github). It's easy to set variables, easy to get environment variables, sometimes ok to get the site object... but haven't got it all together yet. Some references: https://circleci.com/docs/environment-variables https://help.github.com/articles/repository-metadata-on-github-pages/ http://jekyllrb.com/docs/plugins/ http://ruby-doc.org/core-2.1.4/ENV.html and according to this: http://jekyllrb.com/docs/variables/ you can't reset values of the site.baseurl value, so probably will have to store a separate variable in some other structure, and use that elsewhere. Ben On Sat, Aug 22, 2015 at 12:56 PM, Ben Cipollini wrote: > @Ariel I don't think that change solves anything different than simply > setting the baseurl to /nipy-jekyll/ (note: I would avoid the fully > qualified URL, it would unintentionally make a circle.ci version of the > site, or a locally built one without specifying an overriding baseurl, to > pull from an unexpected source.) > > The problem is (at least as I see it), we need different baseurl values > for different build situations (gh-pages, circle.ci, local). > > > On Sat, Aug 22, 2015 at 12:12 PM, Ariel Rokem wrote: > >> >> On Sat, Aug 22, 2015 at 11:34 AM, vanessa sochat >> wrote: >> >>> The "ugly" solution is to use different templates for the pages not at >>> the base url, and then you can just hard code the page one level up. For >>> example, in the header >>> : >>> >>> a path currently looks like: >>> >>> >>> >>> and for subpages, we would make a new header_subpage.html with a path >>> like: >>> >>> >>> >>> But then when you change anything about the design, you have to change >>> it in two places. I started implementing this, felt sick to my stomach at >>> how awful the idea was, and completely converted everything back :) I think >>> it could be possible to use this weird language >>> so that all pages detect their level. For >>> example, take a look here >>> >>> at a solution I figured out using the syntax - but it fails in that the if >>> statement is hard coded. >>> >>> Also take a look here >>> >>> - for the posts we can get the URLs programatically, but I wasn't sure how >>> to do that for "non-post" pages. >>> >>> >>> >> I am also thinking in this direction. Maybe we can have different baseurl >> configs for different things? Something along these lines: >> >> >> https://github.com/arokem/nipy-jekyll/commit/9f2b6be741b20b779321dc2739fc6c6efa1a3bac >> >> Still not working, but something like this might work. Once we settle on >> a design, I don't expect that we will have many changes there. I think that >> most PRs will be with text content, and not to things of this sort, so I am >> not too worried about the potential ugliness of having to change many >> things in many places for that. >> >> >> >> >> >>> On Sat, Aug 22, 2015 at 11:24 AM, Ben Cipollini >>> wrote: >>> >>>> Oops, I spoke too soon. Sounds like circle.ci is very important. :) >>>> >>>> Vanessa, you had an idea for an "ugly" solution for the original issue? >>>> May I ask what that is? Looks like others are simply using --baseurl="" on >>>> the command-line. >>>> >>>> Thanks, >>>> Ben >>>> >>>> >>>> On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat >>>> wrote: >>>> >>>>> Hi Ariel, >>>>> >>>>> Circle is needed to preview PRs. >>>>> >>>>> On your fork take a look at the individual blog pages - the path goes >>>>> to the base and it is not found. And then on circle since the baseurl is >>>>> "/" it would be quite broken looking. >>>>> >>>>> Right now adding a project would mean adding an entry to the data file >>>>> , >>>>> and then copying a template page for it (for example >>>>> , you >>>>> would just need the header and to name the page corresponding to its tag in >>>>> the data file). The navigation, front page, and D3 are rendered from that >>>>> file, but I didn't see a nice way to generate an entire page for the >>>>> package. The reason I had originally chosen flask is because a person could >>>>> just add a line to a tsv file, and the application would be smart enough to >>>>> make the page if the user did not. I don't see a way to achieve that with >>>>> these more syntax based frameworks. >>>>> >>>>> For the content and more tweaks to the design - let's hold off on >>>>> jumping into that until we get this url issue worked out! I am totally game >>>>> for adjusting the design, layout, content for whatever people think is best. >>>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem >>>>> wrote: >>>>> >>>>>> Hi Vanessa, >>>>>> >>>>>> Sorry for the delay in responding. >>>>>> >>>>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat >>>>> > wrote: >>>>>> >>>>>>> Hi Everyone, >>>>>>> >>>>>>> Here is an update to the site. I've ported it into jekyll >>>>>>> , and tested the template on >>>>>>> iphone and computer (seems reasonable). I've also gotten it to render the >>>>>>> artifacts on circle.ci >>>>>>> , so we could preview >>>>>>> PRs (Click "artifact" and then find home.html >>>>>>> ). >>>>>>> However, I've run into a bug with regard to absolute vs. relative paths - >>>>>>> when you click the demo link above, the "posts" not being at the base url >>>>>>> means they will not be linked or render correctly (for example, here >>>>>>> is a link >>>>>>> >>>>>>> to a post on circle, and you won't see styling because the css/js links are >>>>>>> broken) >>>>>>> >>>>>>> The site works perfectly given that we aren't serving it at a >>>>>>> relative path, eg: >>>>>>> >>>>>>> jekyll serve --baseurl="/" >>>>>>> >>>>>>> And the challenge is finding a solution that will render locally, on >>>>>>> github pages, and circle.ci, and what we need, I think, is some >>>>>>> kind of liquid syntax that will detect when we are in a subfolder and >>>>>>> render appropriately. I've been messing around with it for 7 hours today >>>>>>> and can't figure it out, and I need to ask for help. Could someone else >>>>>>> take a look? Likely someone with more experience than me with Jekyll could >>>>>>> figure this out in a heartbeat (Ariel?) The plan right now, I'd like to >>>>>>> propose, would be to figure out this bug, get it onto a (test) github >>>>>>> pages, tweak the details of the content, make proper documentation, and >>>>>>> then release to official github pages. >>>>>>> >>>>>>> >>>>>> Why do we need CircleCI here? I am actually not sure what the issue >>>>>> is, but here's the site rendered through gh-pages on my fork of your repo: >>>>>> >>>>>> http://arokem.github.io/nipy-jekyll/ >>>>>> >>>>>> I did also add a Gemfile to the repo, and that might matter: I >>>>>> believe Github pages serves jekyll through a call to "bundle exec jekyll >>>>>> serve" (see here: >>>>>> https://help.github.com/articles/using-jekyll-with-pages/). >>>>>> >>>>>> One comment about the content: I would prefer to have a front page >>>>>> that just states what this thing is, and the projects on a separate page. I >>>>>> would like for it to be *super* easy to add projects. The whole idea is >>>>>> that the NIPY community is not a static list of projects, but an >>>>>> ever-evolving ecosystem. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Ariel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Vanessa >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at gmail.com Sat Aug 22 19:56:53 2015 From: vsochat at gmail.com (Vanessa) Date: Sat, 22 Aug 2015 10:56:53 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Hi Ben, The problem is well understood - it is just about absolute vs relative path coding. When we specify the base url to be absolute, at the root ("/") this will render everything correctly locally, and if the site is hosted at some root, there as well, but only for pages present at the root. However, in the case of previewing the pages on circle, all paths must be relative (files rendered with a root path are not found). We need a solution that renders correctly in both places, for pages at all levels. So - methinks a good strategy would be to 1) for circle- dynamically change the paths of the artifacts in the test code from absolute to relative before finishing, and 2) for subpages use liquid syntax to detect when a path is at a level other than root and change appropriately. Actually, a strategy that could do the second would also fix the first issue with circle. I haven't even tried github pages yet because the workflow and paths for a repo level page is likely different from an organization one, so it would not be useful. I wont get a chance to work on this today bur likely tomorrow so please keep me in the loop! Best, Vanessa > On Aug 22, 2015, at 10:32 AM, Ben Cipollini wrote: > > I'm trying to install Jekyll now, and will see if I can reproduce the problem. If so, I may have a few mins today to think about a solution. > > Vanessa, do you have a sense of why this is happening? Is the problem finding a solution to a problem you understand well, or is the problem investigating why this is happening to start with? > > Thanks! > Ben > >> On Fri, Aug 21, 2015 at 10:01 AM, vanessa sochat wrote: >> Hi Matthew, >> >> I'm on board with Stefan's suggestion, I just stick to Poldracklab work during the week and haven't done any new nipy site work. As I mentioned earlier, I was hoping for some help with a more elegant solution to resolve the current base url issue (please see my previous messages). If there aren't any ideas, I will likely implement a very un-elegant / harder to change solution, just to get something working, and only after that does it make sense to give a go at github pages deployment. >> >> Best, >> >> Vanessa >> >>> On Fri, Aug 21, 2015 at 9:55 AM, Matthew Brett wrote: >>> Hi Vanessa, >>> >>> Thanks again for doing this. >>> >>> Have you got a github-pages build of this somewhere? Sorry if I >>> missed it. I tried building locally, but I'm not confident that I'm >>> getting what you expect to see. >>> >>> It would be good to have the mission statement somewhere, if y'all agree. >>> >>> Do you have any thoughts on Stefan's suggestion? >>> >>> Cheers, >>> >>> Matthew >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sun Aug 23 23:40:04 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sun, 23 Aug 2015 14:40:04 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Hi Vanessa, Another solution is simply to send Jekyll the proper baseurl in all cases. In my eyes, that's the simplest and intended solution. I just can't understand why it's so hard to do easily, or at all. The relative paths thing is another solution, but I feel that's a workaround--Jekyll has the baseurl defined and configurable, it's clearly part of the software design. Hope we find an elegant solution soon :) Ben On Sat, Aug 22, 2015 at 10:56 AM, Vanessa wrote: > Hi Ben, > > The problem is well understood - it is just about absolute vs relative > path coding. When we specify the base url to be absolute, at the root ("/") > this will render everything correctly locally, and if the site is hosted at > some root, there as well, but only for pages present at the root. However, > in the case of previewing the pages on circle, all paths must be relative > (files rendered with a root path are not found). We need a solution that > renders correctly in both places, for pages at all levels. So - methinks a > good strategy would be to 1) for circle- dynamically change the paths of > the artifacts in the test code from absolute to relative before finishing, > and 2) for subpages use liquid syntax to detect when a path is at a level > other than root and change appropriately. Actually, a strategy that could > do the second would also fix the first issue with circle. > > I haven't even tried github pages yet because the workflow and paths for a > repo level page is likely different from an organization one, so it would > not be useful. > > I wont get a chance to work on this today bur likely tomorrow so please > keep me in the loop! > > Best, > > Vanessa > > On Aug 22, 2015, at 10:32 AM, Ben Cipollini wrote: > > I'm trying to install Jekyll now, and will see if I can reproduce the > problem. If so, I may have a few mins today to think about a solution. > > Vanessa, do you have a sense of why this is happening? Is the problem > finding a solution to a problem you understand well, or is the problem > investigating why this is happening to start with? > > Thanks! > Ben > > On Fri, Aug 21, 2015 at 10:01 AM, vanessa sochat > wrote: > >> Hi Matthew, >> >> I'm on board with Stefan's suggestion, I just stick to Poldracklab work >> during the week and haven't done any new nipy site work. As I mentioned >> earlier, I was hoping for some help with a more elegant solution to resolve >> the current base url issue (please see my previous messages). If there >> aren't any ideas, I will likely implement a very un-elegant / harder to >> change solution, just to get something working, and only after that does it >> make sense to give a go at github pages deployment. >> >> Best, >> >> Vanessa >> >> On Fri, Aug 21, 2015 at 9:55 AM, Matthew Brett >> wrote: >> >>> Hi Vanessa, >>> >>> Thanks again for doing this. >>> >>> Have you got a github-pages build of this somewhere? Sorry if I >>> missed it. I tried building locally, but I'm not confident that I'm >>> getting what you expect to see. >>> >>> It would be good to have the mission statement somewhere, if y'all agree. >>> >>> Do you have any thoughts on Stefan's suggestion? >>> >>> Cheers, >>> >>> Matthew >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Sun Aug 23 23:43:01 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Sun, 23 Aug 2015 22:43:01 +0100 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Hi, On Sun, Aug 23, 2015 at 10:40 PM, Ben Cipollini wrote: > Hi Vanessa, > > Another solution is simply to send Jekyll the proper baseurl in all cases. > In my eyes, that's the simplest and intended solution. I just can't > understand why it's so hard to do easily, or at all. > > The relative paths thing is another solution, but I feel that's a > workaround--Jekyll has the baseurl defined and configurable, it's clearly > part of the software design. > > Hope we find an elegant solution soon :) > Ben Forgive my anxiety, but this conversation worries me. It seems to me, that if we are having to do some serious custom configuration to make a jekyll site work, it goes rather a long way to defeating the purpose of jekyll as compared to - say - sphinx - in that it makes the site more difficult and fragile to maintain. Is that worry reasonable do you think? Cheers, Matthew From bcipolli at ucsd.edu Sun Aug 23 23:46:25 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sun, 23 Aug 2015 14:46:25 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: If it's just a matter of configuring a variable like the base url of the website, then I say no--no problem. If we have to work around it by manipulating URLs in funky ways inside templates... then I say, probably. I don't find this to be a Jekyll issue as much as how the different publishing sources expose Jekyll config. If they simply set the baseurl properly for ya, this would all be so simple! That's exactly what that config variable is there for... and Vanessa's using it quite properly in all the template code. Ben On Sun, Aug 23, 2015 at 2:43 PM, Matthew Brett wrote: > Hi, > > On Sun, Aug 23, 2015 at 10:40 PM, Ben Cipollini wrote: > > Hi Vanessa, > > > > Another solution is simply to send Jekyll the proper baseurl in all > cases. > > In my eyes, that's the simplest and intended solution. I just can't > > understand why it's so hard to do easily, or at all. > > > > The relative paths thing is another solution, but I feel that's a > > workaround--Jekyll has the baseurl defined and configurable, it's clearly > > part of the software design. > > > > Hope we find an elegant solution soon :) > > Ben > > Forgive my anxiety, but this conversation worries me. It seems to me, > that if we are having to do some serious custom configuration to make > a jekyll site work, it goes rather a long way to defeating the purpose > of jekyll as compared to - say - sphinx - in that it makes the site > more difficult and fragile to maintain. Is that worry reasonable do > you think? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Mon Aug 24 00:17:56 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sun, 23 Aug 2015 15:17:56 -0700 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C7FB@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C86F@EXDAG0-B1.intra.cea.fr> Message-ID: Alexis, I'm also interested in having this demo. Is this the right code-path to do functional/structural alignment within a subject as well as aligning subject and atlas data? Thanks, Ben On Fri, Aug 21, 2015 at 9:57 AM, Alexis Roche wrote: > Hi, > > I am realizing that the following example script is outdated as it still > relies on importing nipy: > > https://github.com/nipy/nireg/blob/master/examples/affine_registration.py > > I will submit an update in a few days. The registration code was > previously part of the nipy package, which we have recently decided to > split into several standalone packages, including nireg. The idea is that > nireg only needs nibabel to run (in addition to the standard numpy/scipy > packages). > > > > - how to convert a numpy array to nipy-like image ? > > This is done using nibabel, see in particular the Nifti1Image class. > > > - should the two images have the same size ? > > No. > > > - the version of nipy that I should use ? > > As mentioned above, the latest version of the code does not require nipy. > > I will let you know when I push an up-to-date version of the affine > registration example script. > > Best, > > Alexis > > > > > > > > > > > > > > thank you, really, for your attention, this is kind. > > > > > > > > Gael > > > > > > > > > > > > > > > > > > > > De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret= > cea.fr at python.org] De la part de Alexis Roche > > Envoy? : vendredi 21 ao?t 2015 13:04 > > > > > > ? : Neuroimaging analysis in Python > > Objet : Re: [Neuroimaging] 3d registration for data fusion in material > science > > > > > > > > Hi Gael, > > > > Beside the stuff in dipy that Elef mentioned, there is another brain > image registration package that has slowly developed over the years, and > could be useful to you (although it still crucially lacks documentation): > > > > https://github.com/nipy/nireg > > > > > > > > This is rigid/affine registration only for the time being and has a BSD > license too. > > > > > > > > Best, > > > > Alexis > > > > > > > > On Fri, Aug 21, 2015 at 9:57 AM, GORET Gael 246279 > wrote: > > > > Hi all, > > > > > > > > Thanks for your quick replies, > > > > This project is just starting, and there is not too much materials ? > > > > However, to answer your questions, I just have created a public repo on > my github account : > > > > > > > > https://github.com/ggoret/MUDRA > > > > > > > > - In /doc, I have placed a summary (a pdf slideshow) of the > project containing some pictures (and info on instruments) > > > > > > > > - In /examples I have put two data volumes (npy binary file > format) the kind of data I need to register. > > > > > > > > - In /mudra a first (naive) try using the Fourier shell > correlation as metric > > > > And you can also find > > > > - a Cython wrapping of malik and perona?s algorithms > implementation working (pretty quickly) on 3D Volumes : > > > > o /mudra/extensions/non_linear_filtering.pyx > > > > > > > > - In /scripts you will find mainly converters simplifying I/O > > > > - In /tools 3 very nice visualization tools based on VTK (not > mayavi) working as standalone (npy input) : > > > > o elevation.py -> 2d image to 3d landscape > > > > o plan_interpolator.py -> 2d slicing of volume + isosurface rendering > for given seeds > > > > o scalar_field.py -> volume rendering (color and opacity gradient) > > > > > > > > Thanks in advance for your advices > > > > > > > > Cheers, > > > > > > > > Gael > > > > > > > > De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret= > cea.fr at python.org] De la part de Eleftherios Garyfallidis > > Envoy? : jeudi 20 ao?t 2015 16:35 > > ? : Neuroimaging analysis in Python > > Objet : Re: [Neuroimaging] 3d registration for data fusion in material > science > > > > > > > > Hi Gael, > > > > > > > > Sounds exciting. There is no restriction to use our tools in other > libraries or domains. > > > > Look at these tutorials please (you need dipy development version) > > > > > > > > > https://github.com/nipy/dipy/blob/master/doc/examples/affine_registration_3d.py > > > > > https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_2d.py > > > > > https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_3d.py > > > > > > > > Do you have a github repo of your project? Do you have any example > pictures/volumes to show us that you would > > > > like to register? > > > > > > > > Cheers, > > > > Eleftherios > > > > > > > > > > > > > > > > On Thu, Aug 20, 2015 at 9:31 AM, GORET Gael 246279 > wrote: > > > > Hi everybody, > > > > I am a (French) newcomer, working on the development of the data fusion > of Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray > Nano-Tomography (XuM) data at the CEA (the French state institute for > energy, high-tech, etc.). > > > > In terms of samples, we?re a bit far from the neuro-fields ? Solid oxide > fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology I hope > we have to share ? my project is to combine a chemical information (from > ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at > nano-scale). I am tackling a python module aiming to the registration of > 3d datasets. it seems that nipy includes a such possibility (an a lot more > ?). > > > > I?m a computer guy, mostly Pythonist and I wander if you would let me > transpose your code (mainly the registration part) to my problematic, I > would be very grateful for this. > > > > In this context would you have some advice for me ? > > > > I'm looking forward to hearing from you. > > > > Gael > > > > > > > > > > > > Dr. Ga?l Goret > > > > Chercheur Postdoctoral > > > > D?partement des Technologies Silicium > > > > Service de Caract?risation des Mat?riaux & Composants > > > > Commissariat ? l??nergie atomique et aux ?nergies alternatives > > > > MINATEC Campus | 17 rue des martyrs | F-38054 Grenoble Cedex > > > > T. +33 (0)4 38 78 49 29 | gael.goret at cea.fr > > > > > > > > > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > > > > > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > > > > > > -- > > > > Lead Clinical Research > > Advanced Clinical Imaging Technology > > Siemens/CHUV/EPFL > > 1015 Lausanne, Switzerland > > Phone: +41 21 545 9972 > > https://sites.google.com/site/alexisroche > > > > > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > > > > > -- > Lead Clinical Research > Advanced Clinical Imaging Technology > Siemens/CHUV/EPFL > 1015 Lausanne, Switzerland > Phone: +41 21 545 9972 > https://sites.google.com/site/alexisroche > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Mon Aug 24 02:02:45 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sun, 23 Aug 2015 17:02:45 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: OK, I think this will work: * set baseurl in _config.yml to the repo name (/nipy-jekyll), since github has no flexibility. * locally, launch with --baseurl="/" (this is a semi-standard, from what I see while searching) * for circle.ci, write a small bash script that creates the circle.ci base url from environment variables, and dumps it to a custom config.yml file. Then call that shell script from circle.yml, and launch Jekyll with that config file from circle.yml. That should be pretty simple to set up in all cases, keep things very clean in the templates (just use the baseurl on all urls, as is currently done). I'm heading out for the night, but may have time to try this in a branch later tonight or tomorrow. On Sun, Aug 23, 2015 at 2:46 PM, Ben Cipollini wrote: > If it's just a matter of configuring a variable like the base url of the > website, then I say no--no problem. > > If we have to work around it by manipulating URLs in funky ways inside > templates... then I say, probably. > > I don't find this to be a Jekyll issue as much as how the different > publishing sources expose Jekyll config. If they simply set the baseurl > properly for ya, this would all be so simple! That's exactly what that > config variable is there for... and Vanessa's using it quite properly in > all the template code. > > Ben > > > > On Sun, Aug 23, 2015 at 2:43 PM, Matthew Brett > wrote: > >> Hi, >> >> On Sun, Aug 23, 2015 at 10:40 PM, Ben Cipollini >> wrote: >> > Hi Vanessa, >> > >> > Another solution is simply to send Jekyll the proper baseurl in all >> cases. >> > In my eyes, that's the simplest and intended solution. I just can't >> > understand why it's so hard to do easily, or at all. >> > >> > The relative paths thing is another solution, but I feel that's a >> > workaround--Jekyll has the baseurl defined and configurable, it's >> clearly >> > part of the software design. >> > >> > Hope we find an elegant solution soon :) >> > Ben >> >> Forgive my anxiety, but this conversation worries me. It seems to me, >> that if we are having to do some serious custom configuration to make >> a jekyll site work, it goes rather a long way to defeating the purpose >> of jekyll as compared to - say - sphinx - in that it makes the site >> more difficult and fragile to maintain. Is that worry reasonable do >> you think? >> >> Cheers, >> >> Matthew >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 24 02:25:42 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sun, 23 Aug 2015 17:25:42 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: ok, I'm testing this out! I was just giving Ariel's solution a try but it broke circle in weird ways. Apologies for delay in response, I was working on useless and silly things, and have about an hour for nipy right now! On Sun, Aug 23, 2015 at 5:02 PM, Ben Cipollini wrote: > OK, I think this will work: > > * set baseurl in _config.yml to the repo name (/nipy-jekyll), since github > has no flexibility. > * locally, launch with --baseurl="/" (this is a semi-standard, from what I > see while searching) > * for circle.ci, write a small bash script that creates the circle.ci > base url from environment variables, and dumps it to a custom config.yml > file. Then call that shell script from circle.yml, and launch Jekyll with > that config file from circle.yml. > > That should be pretty simple to set up in all cases, keep things very > clean in the templates (just use the baseurl on all urls, as is currently > done). > > I'm heading out for the night, but may have time to try this in a branch > later tonight or tomorrow. > > > On Sun, Aug 23, 2015 at 2:46 PM, Ben Cipollini wrote: > >> If it's just a matter of configuring a variable like the base url of the >> website, then I say no--no problem. >> >> If we have to work around it by manipulating URLs in funky ways inside >> templates... then I say, probably. >> >> I don't find this to be a Jekyll issue as much as how the different >> publishing sources expose Jekyll config. If they simply set the baseurl >> properly for ya, this would all be so simple! That's exactly what that >> config variable is there for... and Vanessa's using it quite properly in >> all the template code. >> >> Ben >> >> >> >> On Sun, Aug 23, 2015 at 2:43 PM, Matthew Brett >> wrote: >> >>> Hi, >>> >>> On Sun, Aug 23, 2015 at 10:40 PM, Ben Cipollini >>> wrote: >>> > Hi Vanessa, >>> > >>> > Another solution is simply to send Jekyll the proper baseurl in all >>> cases. >>> > In my eyes, that's the simplest and intended solution. I just can't >>> > understand why it's so hard to do easily, or at all. >>> > >>> > The relative paths thing is another solution, but I feel that's a >>> > workaround--Jekyll has the baseurl defined and configurable, it's >>> clearly >>> > part of the software design. >>> > >>> > Hope we find an elegant solution soon :) >>> > Ben >>> >>> Forgive my anxiety, but this conversation worries me. It seems to me, >>> that if we are having to do some serious custom configuration to make >>> a jekyll site work, it goes rather a long way to defeating the purpose >>> of jekyll as compared to - say - sphinx - in that it makes the site >>> more difficult and fragile to maintain. Is that worry reasonable do >>> you think? >>> >>> Cheers, >>> >>> Matthew >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Mon Aug 24 03:32:47 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sun, 23 Aug 2015 18:32:47 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Fantastic idea Ben! I think we possibly have found something that would work. Github pages: http://vsoch.github.io/nipy-jekyll/ Circle: https://circle-artifacts.com/gh/vsoch/nipy-jekyll/53/artifacts/0/home/ubuntu/nipy-jekyll/_site/home.html Locally (using the --baseurl="/") A few notes: - The above was done by replacing the baseurl with one generated from circle environmental variables - Github pages does not need a Gemfile to work. - I don't know what circle does with gh-pages branches, but they don't work, even when the code is identical. It looks like the last little bug is the paths for the posts - we likely need another regular expression. I'm closing up shop for today, but it's great that we made progress! We can fix this last bug, then address the content, and then hopefully have something polished enough to work. I'm also thinking it would be a good idea to contact circle about this - it should be their default to change the baseurl so the artifacts render properly. On Sun, Aug 23, 2015 at 5:25 PM, vanessa sochat wrote: > ok, I'm testing this out! I was just giving Ariel's solution a try but it > broke circle in weird ways. Apologies for delay in response, I was working > on useless and silly things, and have about an hour for nipy right now! > > On Sun, Aug 23, 2015 at 5:02 PM, Ben Cipollini wrote: > >> OK, I think this will work: >> >> * set baseurl in _config.yml to the repo name (/nipy-jekyll), since >> github has no flexibility. >> * locally, launch with --baseurl="/" (this is a semi-standard, from what >> I see while searching) >> * for circle.ci, write a small bash script that creates the circle.ci >> base url from environment variables, and dumps it to a custom config.yml >> file. Then call that shell script from circle.yml, and launch Jekyll with >> that config file from circle.yml. >> >> That should be pretty simple to set up in all cases, keep things very >> clean in the templates (just use the baseurl on all urls, as is currently >> done). >> >> I'm heading out for the night, but may have time to try this in a branch >> later tonight or tomorrow. >> >> >> On Sun, Aug 23, 2015 at 2:46 PM, Ben Cipollini wrote: >> >>> If it's just a matter of configuring a variable like the base url of the >>> website, then I say no--no problem. >>> >>> If we have to work around it by manipulating URLs in funky ways inside >>> templates... then I say, probably. >>> >>> I don't find this to be a Jekyll issue as much as how the different >>> publishing sources expose Jekyll config. If they simply set the baseurl >>> properly for ya, this would all be so simple! That's exactly what that >>> config variable is there for... and Vanessa's using it quite properly in >>> all the template code. >>> >>> Ben >>> >>> >>> >>> On Sun, Aug 23, 2015 at 2:43 PM, Matthew Brett >>> wrote: >>> >>>> Hi, >>>> >>>> On Sun, Aug 23, 2015 at 10:40 PM, Ben Cipollini >>>> wrote: >>>> > Hi Vanessa, >>>> > >>>> > Another solution is simply to send Jekyll the proper baseurl in all >>>> cases. >>>> > In my eyes, that's the simplest and intended solution. I just can't >>>> > understand why it's so hard to do easily, or at all. >>>> > >>>> > The relative paths thing is another solution, but I feel that's a >>>> > workaround--Jekyll has the baseurl defined and configurable, it's >>>> clearly >>>> > part of the software design. >>>> > >>>> > Hope we find an elegant solution soon :) >>>> > Ben >>>> >>>> Forgive my anxiety, but this conversation worries me. It seems to me, >>>> that if we are having to do some serious custom configuration to make >>>> a jekyll site work, it goes rather a long way to defeating the purpose >>>> of jekyll as compared to - say - sphinx - in that it makes the site >>>> more difficult and fragile to maintain. Is that worry reasonable do >>>> you think? >>>> >>>> Cheers, >>>> >>>> Matthew >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Mon Aug 24 07:16:53 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sun, 23 Aug 2015 22:16:53 -0700 Subject: [Neuroimaging] Website Update In-Reply-To: References: <87y4ha1l04.fsf@berkeley.edu> Message-ID: Great! Thanks for trying that out, and glad to hear it's mostly working! What a relief :P Probably we can move discussion of this to a pull request or issue in the repository, it seems to be mostly small technical details now. I agree; we should contact circle. It's so silly that they're not setting up the config for us--this seems like an obvious need for any jekyll project. On Sun, Aug 23, 2015 at 6:32 PM, vanessa sochat wrote: > Fantastic idea Ben! I think we possibly have found something that would > work. > > Github pages: http://vsoch.github.io/nipy-jekyll/ > Circle: > https://circle-artifacts.com/gh/vsoch/nipy-jekyll/53/artifacts/0/home/ubuntu/nipy-jekyll/_site/home.html > Locally (using the --baseurl="/") > > A few notes: > > - The above was done by replacing the baseurl with one generated from > circle environmental variables > > - Github pages does not need a Gemfile to work. > - I don't know what circle does with gh-pages branches, but they don't > work, even when the code is identical. > > It looks like the last little bug is the paths for the posts - we likely > need another regular expression. I'm closing up shop for today, but it's > great that we made progress! We can fix this last bug, then address the > content, and then hopefully have something polished enough to work. I'm > also thinking it would be a good idea to contact circle about this - it > should be their default to change the baseurl so the artifacts render > properly. > > On Sun, Aug 23, 2015 at 5:25 PM, vanessa sochat > wrote: > >> ok, I'm testing this out! I was just giving Ariel's solution a try but it >> broke circle in weird ways. Apologies for delay in response, I was working >> on useless and silly things, and have about an hour for nipy right now! >> >> On Sun, Aug 23, 2015 at 5:02 PM, Ben Cipollini wrote: >> >>> OK, I think this will work: >>> >>> * set baseurl in _config.yml to the repo name (/nipy-jekyll), since >>> github has no flexibility. >>> * locally, launch with --baseurl="/" (this is a semi-standard, from what >>> I see while searching) >>> * for circle.ci, write a small bash script that creates the circle.ci >>> base url from environment variables, and dumps it to a custom config.yml >>> file. Then call that shell script from circle.yml, and launch Jekyll with >>> that config file from circle.yml. >>> >>> That should be pretty simple to set up in all cases, keep things very >>> clean in the templates (just use the baseurl on all urls, as is currently >>> done). >>> >>> I'm heading out for the night, but may have time to try this in a branch >>> later tonight or tomorrow. >>> >>> >>> On Sun, Aug 23, 2015 at 2:46 PM, Ben Cipollini >>> wrote: >>> >>>> If it's just a matter of configuring a variable like the base url of >>>> the website, then I say no--no problem. >>>> >>>> If we have to work around it by manipulating URLs in funky ways inside >>>> templates... then I say, probably. >>>> >>>> I don't find this to be a Jekyll issue as much as how the different >>>> publishing sources expose Jekyll config. If they simply set the baseurl >>>> properly for ya, this would all be so simple! That's exactly what that >>>> config variable is there for... and Vanessa's using it quite properly in >>>> all the template code. >>>> >>>> Ben >>>> >>>> >>>> >>>> On Sun, Aug 23, 2015 at 2:43 PM, Matthew Brett >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> On Sun, Aug 23, 2015 at 10:40 PM, Ben Cipollini >>>>> wrote: >>>>> > Hi Vanessa, >>>>> > >>>>> > Another solution is simply to send Jekyll the proper baseurl in all >>>>> cases. >>>>> > In my eyes, that's the simplest and intended solution. I just can't >>>>> > understand why it's so hard to do easily, or at all. >>>>> > >>>>> > The relative paths thing is another solution, but I feel that's a >>>>> > workaround--Jekyll has the baseurl defined and configurable, it's >>>>> clearly >>>>> > part of the software design. >>>>> > >>>>> > Hope we find an elegant solution soon :) >>>>> > Ben >>>>> >>>>> Forgive my anxiety, but this conversation worries me. It seems to me, >>>>> that if we are having to do some serious custom configuration to make >>>>> a jekyll site work, it goes rather a long way to defeating the purpose >>>>> of jekyll as compared to - say - sphinx - in that it makes the site >>>>> more difficult and fragile to maintain. Is that worry reasonable do >>>>> you think? >>>>> >>>>> Cheers, >>>>> >>>>> Matthew >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Aug 25 17:40:39 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 25 Aug 2015 16:40:39 +0100 Subject: [Neuroimaging] When to use neurostars, and when not to Message-ID: Hi, This just came up from a discussion on a nipy pull request: https://github.com/nipy/nipy/pull/340 I thought it was worth clarifying what my position is. I don't use neurostars, so if you want advice on using or developing nibabel, then this mailing list is the right place to go. rather than neurostars. This is probably also true for the nipy project - in that I can help on this list but you probably won't get my attention on neurostars. The other two main authors of nipy are Alexis and Bertrand - maybe they hang out more on neurostars? Can y'all clarify? I'm actually not sure what the policy is for dipy - Eleftherios - did you decide on this? To explain a bit further, I much prefer unified user- and developer- discussions and therefore mailing lists, because I think it's important to keep a fluid boundary between users and developers. I also have an instinctive aversion to reputation-based systems, Cheers, Matthew From bertrand.thirion at inria.fr Tue Aug 25 17:42:47 2015 From: bertrand.thirion at inria.fr (Bertrand Thirion) Date: Tue, 25 Aug 2015 17:42:47 +0200 (CEST) Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: Message-ID: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> ----- Mail original ----- > De: "Matthew Brett" > ?: "neuroimaging" > Envoy?: Mardi 25 Ao?t 2015 17:40:39 > Objet: [Neuroimaging] When to use neurostars, and when not to > > Hi, > > This just came up from a discussion on a nipy pull request: > > https://github.com/nipy/nipy/pull/340 > > I thought it was worth clarifying what my position is. I don't use > neurostars, so if you want advice on using or developing nibabel, then > this mailing list is the right place to go. rather than neurostars. > > This is probably also true for the nipy project - in that I can help > on this list but you probably won't get my attention on neurostars. > The other two main authors of nipy are Alexis and Bertrand - maybe > they hang out more on neurostars? Can y'all clarify? > Hi Matthew, No, I don't look at Neurostars in general. Best, Bertrand > I'm actually not sure what the policy is for dipy - Eleftherios - did > you decide on this? > > To explain a bit further, I much prefer unified user- and developer- > discussions and therefore mailing lists, because I think it's > important to keep a fluid boundary between users and developers. I > also have an instinctive aversion to reputation-based systems, > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > From pellman.john at gmail.com Tue Aug 25 18:29:06 2015 From: pellman.john at gmail.com (John Pellman) Date: Tue, 25 Aug 2015 12:29:06 -0400 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: While I understand an aversion to reputation-based systems (this article comes to mind) I would note that it is quite a bit more difficult to keep track of questions when they are divided between two discussion fora (more if you count the AFNI, FSL, and SPM mailing lists), and I can't help but wonder if some amount of consolidation while preserving individual interests would be beneficial to the neuroimaging community. 2015-08-25 11:42 GMT-04:00 Bertrand Thirion : > > > ----- Mail original ----- > > De: "Matthew Brett" > > ?: "neuroimaging" > > Envoy?: Mardi 25 Ao?t 2015 17:40:39 > > Objet: [Neuroimaging] When to use neurostars, and when not to > > > > Hi, > > > > This just came up from a discussion on a nipy pull request: > > > > https://github.com/nipy/nipy/pull/340 > > > > I thought it was worth clarifying what my position is. I don't use > > neurostars, so if you want advice on using or developing nibabel, then > > this mailing list is the right place to go. rather than neurostars. > > > > This is probably also true for the nipy project - in that I can help > > on this list but you probably won't get my attention on neurostars. > > The other two main authors of nipy are Alexis and Bertrand - maybe > > they hang out more on neurostars? Can y'all clarify? > > > > Hi Matthew, > > No, I don't look at Neurostars in general. > Best, > > Bertrand > > > I'm actually not sure what the policy is for dipy - Eleftherios - did > > you decide on this? > > > > To explain a bit further, I much prefer unified user- and developer- > > discussions and therefore mailing lists, because I think it's > > important to keep a fluid boundary between users and developers. I > > also have an instinctive aversion to reputation-based systems, > > > > Cheers, > > > > Matthew > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pellman.john at gmail.com Tue Aug 25 18:35:06 2015 From: pellman.john at gmail.com (John Pellman) Date: Tue, 25 Aug 2015 12:35:06 -0400 Subject: [Neuroimaging] Nipype with Taverna (or similar)? Message-ID: Odd question, but has the nipype team ever considered integrating nipype with a more general workflow management system such as Taverna ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Tue Aug 25 18:37:27 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Tue, 25 Aug 2015 09:37:27 -0700 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: The ideal for questions / issues related to packages is github. However neurostars would have a much larger group. I'm not familiar with how neurostars is set up (django?) but why not have (akin to slack) an app integration for particular github repos and neurostars? Aka, when someone posts to the repo in some fashion, it is also shared on neurostars, and possibly directs to the repo. On Tue, Aug 25, 2015 at 9:29 AM, John Pellman wrote: > While I understand an aversion to reputation-based systems (this article > > comes to mind) I would note that it is quite a bit more difficult to keep > track of questions when they are divided between two discussion fora (more > if you count the AFNI, FSL, and SPM mailing lists), and I can't help but > wonder if some amount of consolidation while preserving individual > interests would be beneficial to the neuroimaging community. > > 2015-08-25 11:42 GMT-04:00 Bertrand Thirion : > >> >> >> ----- Mail original ----- >> > De: "Matthew Brett" >> > ?: "neuroimaging" >> > Envoy?: Mardi 25 Ao?t 2015 17:40:39 >> > Objet: [Neuroimaging] When to use neurostars, and when not to >> > >> > Hi, >> > >> > This just came up from a discussion on a nipy pull request: >> > >> > https://github.com/nipy/nipy/pull/340 >> > >> > I thought it was worth clarifying what my position is. I don't use >> > neurostars, so if you want advice on using or developing nibabel, then >> > this mailing list is the right place to go. rather than neurostars. >> > >> > This is probably also true for the nipy project - in that I can help >> > on this list but you probably won't get my attention on neurostars. >> > The other two main authors of nipy are Alexis and Bertrand - maybe >> > they hang out more on neurostars? Can y'all clarify? >> > >> >> Hi Matthew, >> >> No, I don't look at Neurostars in general. >> Best, >> >> Bertrand >> >> > I'm actually not sure what the policy is for dipy - Eleftherios - did >> > you decide on this? >> > >> > To explain a bit further, I much prefer unified user- and developer- >> > discussions and therefore mailing lists, because I think it's >> > important to keep a fluid boundary between users and developers. I >> > also have an instinctive aversion to reputation-based systems, >> > >> > Cheers, >> > >> > Matthew >> > _______________________________________________ >> > Neuroimaging mailing list >> > Neuroimaging at python.org >> > https://mail.python.org/mailman/listinfo/neuroimaging >> > >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Tue Aug 25 17:57:36 2015 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Tue, 25 Aug 2015 17:57:36 +0200 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: Message-ID: <20150825155736.GA252021@phare.normalesup.org> For nilearn, we are considering advising all are users to ask questions on neurostars. The reason is that a interface like neurostars encourages users to answer questions, and also is easier to search than mailing list archie. The huge success of stack overflow shows the power of such interface in supporting users. At the end of the day, I hope that it will remove some user-support load from our side. Ga?l From bcipolli at ucsd.edu Tue Aug 25 18:41:14 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Tue, 25 Aug 2015 09:41:14 -0700 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: I really like that idea, Vanessa! I find it hard to keep track of both. Though it doesn't solve the issue with the mailing list integration. Any idea how hard it is to write such a plugin/app? -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Tue Aug 25 18:46:31 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Tue, 25 Aug 2015 12:46:31 -0400 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: hi folks, issue posted here: https://github.com/ialbert/biostar-central/issues/389 neurostars is based off biostars (shares the same codebase, with a different config). biostars is a complete opensource django project that anyone can contribute to. we do have plans for federation that will come online in the next year or two. cheers, satra On Tue, Aug 25, 2015 at 12:37 PM, vanessa sochat wrote: > The ideal for questions / issues related to packages is github. However > neurostars would have a much larger group. I'm not familiar with how > neurostars is set up (django?) but why not have (akin to slack) an app > integration for particular github repos and neurostars? Aka, when someone > posts to the repo in some fashion, it is also shared on neurostars, and > possibly directs to the repo. > > On Tue, Aug 25, 2015 at 9:29 AM, John Pellman > wrote: > >> While I understand an aversion to reputation-based systems (this article >> >> comes to mind) I would note that it is quite a bit more difficult to keep >> track of questions when they are divided between two discussion fora (more >> if you count the AFNI, FSL, and SPM mailing lists), and I can't help but >> wonder if some amount of consolidation while preserving individual >> interests would be beneficial to the neuroimaging community. >> >> 2015-08-25 11:42 GMT-04:00 Bertrand Thirion : >> >>> >>> >>> ----- Mail original ----- >>> > De: "Matthew Brett" >>> > ?: "neuroimaging" >>> > Envoy?: Mardi 25 Ao?t 2015 17:40:39 >>> > Objet: [Neuroimaging] When to use neurostars, and when not to >>> > >>> > Hi, >>> > >>> > This just came up from a discussion on a nipy pull request: >>> > >>> > https://github.com/nipy/nipy/pull/340 >>> > >>> > I thought it was worth clarifying what my position is. I don't use >>> > neurostars, so if you want advice on using or developing nibabel, then >>> > this mailing list is the right place to go. rather than neurostars. >>> > >>> > This is probably also true for the nipy project - in that I can help >>> > on this list but you probably won't get my attention on neurostars. >>> > The other two main authors of nipy are Alexis and Bertrand - maybe >>> > they hang out more on neurostars? Can y'all clarify? >>> > >>> >>> Hi Matthew, >>> >>> No, I don't look at Neurostars in general. >>> Best, >>> >>> Bertrand >>> >>> > I'm actually not sure what the policy is for dipy - Eleftherios - did >>> > you decide on this? >>> > >>> > To explain a bit further, I much prefer unified user- and developer- >>> > discussions and therefore mailing lists, because I think it's >>> > important to keep a fluid boundary between users and developers. I >>> > also have an instinctive aversion to reputation-based systems, >>> > >>> > Cheers, >>> > >>> > Matthew >>> > _______________________________________________ >>> > Neuroimaging mailing list >>> > Neuroimaging at python.org >>> > https://mail.python.org/mailman/listinfo/neuroimaging >>> > >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Tue Aug 25 18:55:19 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Tue, 25 Aug 2015 12:55:19 -0400 Subject: [Neuroimaging] Nipype with Taverna (or similar)? In-Reply-To: References: Message-ID: hi john, considered yes, but more closely discussed things like provenance with carole, daniel, and others from the taverna world. taverna was too web-based for us when we started. but these days we are keeping a close eye on CWL (https://common-workflow-language.github.io/), which carries many of nipype's semantics as a way to integrate with a broader workflow base. when nipype started, you either had to be in the cloud, or local, or on an HPC cluster for the existing workflow systems to work. we needed to be able to do all of those, given our user-base, so nipype's plugin architecture focused on providing that flexibility, first through ipython and then through more native plugins. one constraint that nipype still has is a shared directory space. we will be moving away from this constraint in the next year as we integrate with CWL, but that has limited some of the things. the constraint was fine for neuroimaging, because files are big, you don't want to move or replicate them. but as nipype gets used for other things, the constraint is constraining! cheers, satra On Tue, Aug 25, 2015 at 12:35 PM, John Pellman wrote: > Odd question, but has the nipype team ever considered integrating nipype > with a more general workflow management system such as Taverna > ? > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Aug 25 18:49:37 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 25 Aug 2015 17:49:37 +0100 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, On Tue, Aug 25, 2015 at 5:29 PM, John Pellman wrote: > While I understand an aversion to reputation-based systems (this article > comes to mind) I would note that it is quite a bit more difficult to keep > track of questions when they are divided between two discussion fora (more > if you count the AFNI, FSL, and SPM mailing lists), and I can't help but > wonder if some amount of consolidation while preserving individual interests > would be beneficial to the neuroimaging community. Well - we do need a mailing list - I guess everyone agrees with that. I have an impression that there's general agreement that developer questions go to this list - or maybe to the relevant github issues. So the remaining question is - where should user questions go. Obviously this is a matter of taste, where my taste is strongly for having user questions on the general mailing list, and I think that's important. I also agree with blog post you (John P) referenced. In particular, I think reputation sites encourage what the author calls 'creeping authoritarianism'. So I hope to persuade y'all to do the same as me, and stick to the mailing list. But we have an open community where we can each follow our individual preferences, and I believe that's a strength. So I can't see an obvious way round the current situation. Cheers, Matthew From vsochat at stanford.edu Tue Aug 25 19:03:44 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Tue, 25 Aug 2015 10:03:44 -0700 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Awesome thanks Satra! On Tue, Aug 25, 2015 at 9:46 AM, Satrajit Ghosh wrote: > hi folks, > > issue posted here: https://github.com/ialbert/biostar-central/issues/389 > > neurostars is based off biostars (shares the same codebase, with a > different config). biostars is a complete opensource django project that > anyone can contribute to. we do have plans for federation that will come > online in the next year or two. > > cheers, > > satra > > On Tue, Aug 25, 2015 at 12:37 PM, vanessa sochat > wrote: > >> The ideal for questions / issues related to packages is github. However >> neurostars would have a much larger group. I'm not familiar with how >> neurostars is set up (django?) but why not have (akin to slack) an app >> integration for particular github repos and neurostars? Aka, when someone >> posts to the repo in some fashion, it is also shared on neurostars, and >> possibly directs to the repo. >> >> On Tue, Aug 25, 2015 at 9:29 AM, John Pellman >> wrote: >> >>> While I understand an aversion to reputation-based systems (this article >>> >>> comes to mind) I would note that it is quite a bit more difficult to keep >>> track of questions when they are divided between two discussion fora (more >>> if you count the AFNI, FSL, and SPM mailing lists), and I can't help but >>> wonder if some amount of consolidation while preserving individual >>> interests would be beneficial to the neuroimaging community. >>> >>> 2015-08-25 11:42 GMT-04:00 Bertrand Thirion : >>> >>>> >>>> >>>> ----- Mail original ----- >>>> > De: "Matthew Brett" >>>> > ?: "neuroimaging" >>>> > Envoy?: Mardi 25 Ao?t 2015 17:40:39 >>>> > Objet: [Neuroimaging] When to use neurostars, and when not to >>>> > >>>> > Hi, >>>> > >>>> > This just came up from a discussion on a nipy pull request: >>>> > >>>> > https://github.com/nipy/nipy/pull/340 >>>> > >>>> > I thought it was worth clarifying what my position is. I don't use >>>> > neurostars, so if you want advice on using or developing nibabel, then >>>> > this mailing list is the right place to go. rather than neurostars. >>>> > >>>> > This is probably also true for the nipy project - in that I can help >>>> > on this list but you probably won't get my attention on neurostars. >>>> > The other two main authors of nipy are Alexis and Bertrand - maybe >>>> > they hang out more on neurostars? Can y'all clarify? >>>> > >>>> >>>> Hi Matthew, >>>> >>>> No, I don't look at Neurostars in general. >>>> Best, >>>> >>>> Bertrand >>>> >>>> > I'm actually not sure what the policy is for dipy - Eleftherios - did >>>> > you decide on this? >>>> > >>>> > To explain a bit further, I much prefer unified user- and developer- >>>> > discussions and therefore mailing lists, because I think it's >>>> > important to keep a fluid boundary between users and developers. I >>>> > also have an instinctive aversion to reputation-based systems, >>>> > >>>> > Cheers, >>>> > >>>> > Matthew >>>> > _______________________________________________ >>>> > Neuroimaging mailing list >>>> > Neuroimaging at python.org >>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>> > >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Tue Aug 25 19:06:48 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Tue, 25 Aug 2015 13:06:48 -0400 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: hi, i personally don't think of biostars/neurostars as an author reputation site per se. also unlike stack overflow, reputation doesn't constrain you to the practical elements of posting and answering questions on *stars. feel free to discuss this on biostars where the discussion of reputation and its role in the platform is more apt. neurostars, like biostars, is a Q+A site and serves a place for aggregation of information in a better manner than a mailing list for many of the reasons gael pointed. it overlaps with but doesn't provide all functions of a mailing list. we will continue to evolve it as a platform for discussion, but that's not one of the strengths of neurostars. it is more suited for focused answers to questions. cheers, satra On Tue, Aug 25, 2015 at 12:49 PM, Matthew Brett wrote: > Hi, > > On Tue, Aug 25, 2015 at 5:29 PM, John Pellman > wrote: > > While I understand an aversion to reputation-based systems (this article > > comes to mind) I would note that it is quite a bit more difficult to keep > > track of questions when they are divided between two discussion fora > (more > > if you count the AFNI, FSL, and SPM mailing lists), and I can't help but > > wonder if some amount of consolidation while preserving individual > interests > > would be beneficial to the neuroimaging community. > > Well - we do need a mailing list - I guess everyone agrees with that. > > I have an impression that there's general agreement that developer > questions go to this list - or maybe to the relevant github issues. > > So the remaining question is - where should user questions go. > > Obviously this is a matter of taste, where my taste is strongly for > having user questions on the general mailing list, and I think that's > important. I also agree with blog post you (John P) referenced. In > particular, I think reputation sites encourage what the author calls > 'creeping authoritarianism'. So I hope to persuade y'all to do the > same as me, and stick to the mailing list. But we have an open > community where we can each follow our individual preferences, and I > believe that's a strength. So I can't see an obvious way round the > current situation. > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hanke at gmail.com Tue Aug 25 19:10:27 2015 From: michael.hanke at gmail.com (Michael Hanke) Date: Tue, 25 Aug 2015 19:10:27 +0200 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, please allow me to hijack some of this thread and ask for feedback on how to guide users to find help. For the upcoming relaunch of neuro.debian.net we have drafted this (example for nibabel): http://neurodebian.ovgu.de/pkgs/python-nibabel.html If you click the "help" button you can see how we envision this guidance. Here is a more featureful example: http://neurodebian.ovgu.de/pkgs/fsl-core.html You can see that neurostars will be recommended for most cases. I'd be glad to get your feedback and any suggestions for improvements. Thanks, Michael On Tue, Aug 25, 2015 at 7:03 PM, vanessa sochat wrote: > Awesome thanks Satra! > > On Tue, Aug 25, 2015 at 9:46 AM, Satrajit Ghosh wrote: > >> hi folks, >> >> issue posted here: https://github.com/ialbert/biostar-central/issues/389 >> >> neurostars is based off biostars (shares the same codebase, with a >> different config). biostars is a complete opensource django project that >> anyone can contribute to. we do have plans for federation that will come >> online in the next year or two. >> >> cheers, >> >> satra >> >> On Tue, Aug 25, 2015 at 12:37 PM, vanessa sochat >> wrote: >> >>> The ideal for questions / issues related to packages is github. However >>> neurostars would have a much larger group. I'm not familiar with how >>> neurostars is set up (django?) but why not have (akin to slack) an app >>> integration for particular github repos and neurostars? Aka, when someone >>> posts to the repo in some fashion, it is also shared on neurostars, and >>> possibly directs to the repo. >>> >>> On Tue, Aug 25, 2015 at 9:29 AM, John Pellman >>> wrote: >>> >>>> While I understand an aversion to reputation-based systems (this >>>> article >>>> >>>> comes to mind) I would note that it is quite a bit more difficult to keep >>>> track of questions when they are divided between two discussion fora (more >>>> if you count the AFNI, FSL, and SPM mailing lists), and I can't help but >>>> wonder if some amount of consolidation while preserving individual >>>> interests would be beneficial to the neuroimaging community. >>>> >>>> 2015-08-25 11:42 GMT-04:00 Bertrand Thirion >>>> : >>>> >>>>> >>>>> >>>>> ----- Mail original ----- >>>>> > De: "Matthew Brett" >>>>> > ?: "neuroimaging" >>>>> > Envoy?: Mardi 25 Ao?t 2015 17:40:39 >>>>> > Objet: [Neuroimaging] When to use neurostars, and when not to >>>>> > >>>>> > Hi, >>>>> > >>>>> > This just came up from a discussion on a nipy pull request: >>>>> > >>>>> > https://github.com/nipy/nipy/pull/340 >>>>> > >>>>> > I thought it was worth clarifying what my position is. I don't use >>>>> > neurostars, so if you want advice on using or developing nibabel, >>>>> then >>>>> > this mailing list is the right place to go. rather than neurostars. >>>>> > >>>>> > This is probably also true for the nipy project - in that I can help >>>>> > on this list but you probably won't get my attention on neurostars. >>>>> > The other two main authors of nipy are Alexis and Bertrand - maybe >>>>> > they hang out more on neurostars? Can y'all clarify? >>>>> > >>>>> >>>>> Hi Matthew, >>>>> >>>>> No, I don't look at Neurostars in general. >>>>> Best, >>>>> >>>>> Bertrand >>>>> >>>>> > I'm actually not sure what the policy is for dipy - Eleftherios - did >>>>> > you decide on this? >>>>> > >>>>> > To explain a bit further, I much prefer unified user- and developer- >>>>> > discussions and therefore mailing lists, because I think it's >>>>> > important to keep a fluid boundary between users and developers. I >>>>> > also have an instinctive aversion to reputation-based systems, >>>>> > >>>>> > Cheers, >>>>> > >>>>> > Matthew >>>>> > _______________________________________________ >>>>> > Neuroimaging mailing list >>>>> > Neuroimaging at python.org >>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>> > >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Michael Hanke http://mih.voxindeserto.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Aug 25 19:15:06 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 25 Aug 2015 18:15:06 +0100 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, On Tue, Aug 25, 2015 at 6:10 PM, Michael Hanke wrote: > Hi, > > please allow me to hijack some of this thread and ask for feedback on how to > guide users to find help. For the upcoming relaunch of neuro.debian.net we > have drafted this (example for nibabel): > > http://neurodebian.ovgu.de/pkgs/python-nibabel.html > > If you click the "help" button you can see how we envision this guidance. > > Here is a more featureful example: > > http://neurodebian.ovgu.de/pkgs/fsl-core.html > > You can see that neurostars will be recommended for most cases. I'd be glad > to get your feedback and any suggestions for improvements. Why yes - I do have a suggestion - I recommend you refer people to the relevant mailing lists! But more seriously - we have a serious issue here which is about the balance of convenience and accessibility against the quality of the community that results. We don't have enough data to know how this will pan out yet, but my strong instinct is that the risks of moving user discussion and questions to neurostar-type forums are rather high, and not worth the gain. Cheers, Matthew From vsochat at stanford.edu Tue Aug 25 19:27:33 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Tue, 25 Aug 2015 10:27:33 -0700 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Just curious, what is the infrastructure (hosting, continuous integration, etc) for that site? On Tue, Aug 25, 2015 at 10:10 AM, Michael Hanke wrote: > Hi, > > please allow me to hijack some of this thread and ask for feedback on how > to guide users to find help. For the upcoming relaunch of neuro.debian.net > we have drafted this (example for nibabel): > > http://neurodebian.ovgu.de/pkgs/python-nibabel.html > > If you click the "help" button you can see how we envision this guidance. > > Here is a more featureful example: > > http://neurodebian.ovgu.de/pkgs/fsl-core.html > > You can see that neurostars will be recommended for most cases. I'd be > glad to get your feedback and any suggestions for improvements. > > Thanks, > > Michael > > > > On Tue, Aug 25, 2015 at 7:03 PM, vanessa sochat > wrote: > >> Awesome thanks Satra! >> >> On Tue, Aug 25, 2015 at 9:46 AM, Satrajit Ghosh wrote: >> >>> hi folks, >>> >>> issue posted here: https://github.com/ialbert/biostar-central/issues/389 >>> >>> neurostars is based off biostars (shares the same codebase, with a >>> different config). biostars is a complete opensource django project that >>> anyone can contribute to. we do have plans for federation that will come >>> online in the next year or two. >>> >>> cheers, >>> >>> satra >>> >>> On Tue, Aug 25, 2015 at 12:37 PM, vanessa sochat >>> wrote: >>> >>>> The ideal for questions / issues related to packages is github. However >>>> neurostars would have a much larger group. I'm not familiar with how >>>> neurostars is set up (django?) but why not have (akin to slack) an app >>>> integration for particular github repos and neurostars? Aka, when someone >>>> posts to the repo in some fashion, it is also shared on neurostars, and >>>> possibly directs to the repo. >>>> >>>> On Tue, Aug 25, 2015 at 9:29 AM, John Pellman >>>> wrote: >>>> >>>>> While I understand an aversion to reputation-based systems (this >>>>> article >>>>> >>>>> comes to mind) I would note that it is quite a bit more difficult to keep >>>>> track of questions when they are divided between two discussion fora (more >>>>> if you count the AFNI, FSL, and SPM mailing lists), and I can't help but >>>>> wonder if some amount of consolidation while preserving individual >>>>> interests would be beneficial to the neuroimaging community. >>>>> >>>>> 2015-08-25 11:42 GMT-04:00 Bertrand Thirion >>>> >: >>>>> >>>>>> >>>>>> >>>>>> ----- Mail original ----- >>>>>> > De: "Matthew Brett" >>>>>> > ?: "neuroimaging" >>>>>> > Envoy?: Mardi 25 Ao?t 2015 17:40:39 >>>>>> > Objet: [Neuroimaging] When to use neurostars, and when not to >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > This just came up from a discussion on a nipy pull request: >>>>>> > >>>>>> > https://github.com/nipy/nipy/pull/340 >>>>>> > >>>>>> > I thought it was worth clarifying what my position is. I don't use >>>>>> > neurostars, so if you want advice on using or developing nibabel, >>>>>> then >>>>>> > this mailing list is the right place to go. rather than neurostars. >>>>>> > >>>>>> > This is probably also true for the nipy project - in that I can help >>>>>> > on this list but you probably won't get my attention on neurostars. >>>>>> > The other two main authors of nipy are Alexis and Bertrand - maybe >>>>>> > they hang out more on neurostars? Can y'all clarify? >>>>>> > >>>>>> >>>>>> Hi Matthew, >>>>>> >>>>>> No, I don't look at Neurostars in general. >>>>>> Best, >>>>>> >>>>>> Bertrand >>>>>> >>>>>> > I'm actually not sure what the policy is for dipy - Eleftherios - >>>>>> did >>>>>> > you decide on this? >>>>>> > >>>>>> > To explain a bit further, I much prefer unified user- and developer- >>>>>> > discussions and therefore mailing lists, because I think it's >>>>>> > important to keep a fluid boundary between users and developers. I >>>>>> > also have an instinctive aversion to reputation-based systems, >>>>>> > >>>>>> > Cheers, >>>>>> > >>>>>> > Matthew >>>>>> > _______________________________________________ >>>>>> > Neuroimaging mailing list >>>>>> > Neuroimaging at python.org >>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> > >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Michael Hanke > http://mih.voxindeserto.de > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hanke at gmail.com Tue Aug 25 19:40:18 2015 From: michael.hanke at gmail.com (Michael Hanke) Date: Tue, 25 Aug 2015 19:40:18 +0200 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hey, On Tue, Aug 25, 2015 at 7:15 PM, Matthew Brett wrote: > Hi, > > On Tue, Aug 25, 2015 at 6:10 PM, Michael Hanke > wrote: > > Hi, > > > > please allow me to hijack some of this thread and ask for feedback on > how to > > guide users to find help. For the upcoming relaunch of neuro.debian.net > we > > have drafted this (example for nibabel): > > > > http://neurodebian.ovgu.de/pkgs/python-nibabel.html > > > > If you click the "help" button you can see how we envision this guidance. > > > > Here is a more featureful example: > > > > http://neurodebian.ovgu.de/pkgs/fsl-core.html > > > > You can see that neurostars will be recommended for most cases. I'd be > glad > > to get your feedback and any suggestions for improvements. > > Why yes - I do have a suggestion - I recommend you refer people to the > relevant mailing lists! > I agree. The problem is that it is not always clear what mailing list is the right one. Currently, we use this formulation: | If you have evidence that your issue not specific to NeuroDebian, your report is best directed to the developers of the respective software. | Information on how to contact the respective developers is available at this location , or on the project homepage. where 'this location' and 'project homepage' are links to the project sites that we have on record in the package meta data. Needs improvement? > But more seriously - we have a serious issue here which is about the > balance of convenience and accessibility against the quality of the > community that results. We don't have enough data to know how this > will pan out yet, but my strong instinct is that the risks of moving > user discussion and questions to neurostar-type forums are rather > high, and not worth the gain. > I'd be interested in the outcome of this discussion and will adjust our acting accordingly. We (NeuroDebian) have to balance the goals of not "stealing community", and not "flooding upstream with Debian-specific bugs". Cheers, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hanke at gmail.com Tue Aug 25 19:43:11 2015 From: michael.hanke at gmail.com (Michael Hanke) Date: Tue, 25 Aug 2015 19:43:11 +0200 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, On Tue, Aug 25, 2015 at 7:27 PM, vanessa sochat wrote: > Just curious, what is the infrastructure (hosting, continuous integration, > etc) for that site? > I assume you are talking about neurodebian.ovgu.de? This is a mirror of neuro.debian.net (currently used to showcase the new site). This cite is completely static and rebuilt on demand (underlying data changes) all with custom hand-polished scripts from the 70s... ;-) Hosting is sponsored by generous educational institutions and even more generous individuals. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Aug 25 19:44:52 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 25 Aug 2015 18:44:52 +0100 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, On Tue, Aug 25, 2015 at 6:40 PM, Michael Hanke wrote: > Hey, > > On Tue, Aug 25, 2015 at 7:15 PM, Matthew Brett > wrote: >> >> Hi, >> >> On Tue, Aug 25, 2015 at 6:10 PM, Michael Hanke >> wrote: >> > Hi, >> > >> > please allow me to hijack some of this thread and ask for feedback on >> > how to >> > guide users to find help. For the upcoming relaunch of neuro.debian.net >> > we >> > have drafted this (example for nibabel): >> > >> > http://neurodebian.ovgu.de/pkgs/python-nibabel.html >> > >> > If you click the "help" button you can see how we envision this >> > guidance. >> > >> > Here is a more featureful example: >> > >> > http://neurodebian.ovgu.de/pkgs/fsl-core.html >> > >> > You can see that neurostars will be recommended for most cases. I'd be >> > glad >> > to get your feedback and any suggestions for improvements. >> >> Why yes - I do have a suggestion - I recommend you refer people to the >> relevant mailing lists! > > > I agree. The problem is that it is not always clear what mailing list is the > right one. Currently, > we use this formulation: > > > | If you have evidence that your issue not specific to NeuroDebian, your > report is best directed to the developers of the respective software. > | Information on how to contact the respective developers is available at > this location , or on the project homepage. > > where 'this location' and 'project homepage' are links to the project sites > that we have on record > in the package meta data. > > Needs improvement? > > >> >> But more seriously - we have a serious issue here which is about the >> balance of convenience and accessibility against the quality of the >> community that results. We don't have enough data to know how this >> will pan out yet, but my strong instinct is that the risks of moving >> user discussion and questions to neurostar-type forums are rather >> high, and not worth the gain. > > > I'd be interested in the outcome of this discussion and will adjust our > acting accordingly. > > We (NeuroDebian) have to balance the goals of not "stealing community", and > not "flooding upstream with > Debian-specific bugs". The question for me is not about stealing community - but about what kind of community results from the different interfaces. Unfortunately we (tech) people don't often consider "soft" questions like this - or reject them from consideration as being in poor taste. See you, Matthew From michael.hanke at gmail.com Tue Aug 25 19:49:18 2015 From: michael.hanke at gmail.com (Michael Hanke) Date: Tue, 25 Aug 2015 19:49:18 +0200 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hey, On Tue, Aug 25, 2015 at 7:44 PM, Matthew Brett wrote: > > We (NeuroDebian) have to balance the goals of not "stealing community", > and > > not "flooding upstream with > > Debian-specific bugs". > > The question for me is not about stealing community - but about what > kind of community results from the different interfaces. > Unfortunately we (tech) people don't often consider "soft" questions > like this - or reject them from consideration as being in poor taste. > I tend to agree. However, the "community stealing" issue did come up in the past, and we cannot afford to ignore it from our side. Some projects want all communication, some don't want to technical Debian-related bits. User just want the answers quick, with as little ping-pong as possible. Some, though, want to become an active part of a community. Best, Michael -- Michael Hanke http://mih.voxindeserto.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Aug 25 19:53:42 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 25 Aug 2015 18:53:42 +0100 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: On Tue, Aug 25, 2015 at 6:49 PM, Michael Hanke wrote: > Hey, > > On Tue, Aug 25, 2015 at 7:44 PM, Matthew Brett > wrote: >> >> > We (NeuroDebian) have to balance the goals of not "stealing community", >> > and >> > not "flooding upstream with >> > Debian-specific bugs". >> >> The question for me is not about stealing community - but about what >> kind of community results from the different interfaces. >> Unfortunately we (tech) people don't often consider "soft" questions >> like this - or reject them from consideration as being in poor taste. > > > I tend to agree. However, the "community stealing" issue did come up in the > past, and > we cannot afford to ignore it from our side. Some projects want all > communication, some > don't want to technical Debian-related bits. User just want the answers > quick, with as little > ping-pong as possible. Some, though, want to become an active part of a > community. Sure - but the problem arises when we give the users a wrong impression and a wrong start by giving them what they want. When we are teaching for example, the student may well just want the answer the question in the exam, but it would be a bad teacher that gave them that answer, rather than teaching them how to work out the answer for themselves. For the communities - it's surely reasonable to refer questions to the chosen forum of the project - for example, I think I'm right in saying there's no controversy that nipype wants user questions to neurostars. I guess it's more complex to direct people who have more general neuroimaging questions. See you, Matthew From michael.hanke at gmail.com Tue Aug 25 20:05:34 2015 From: michael.hanke at gmail.com (Michael Hanke) Date: Tue, 25 Aug 2015 20:05:34 +0200 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hey, On Tue, Aug 25, 2015 at 7:53 PM, Matthew Brett wrote: > For the communities - it's surely reasonable to refer questions to the > chosen forum of the project - for example, I think I'm right in saying > there's no controversy that nipype wants user questions to neurostars. > I guess it's more complex to direct people who have more general > neuroimaging questions. Not just that. For nipype, imagine a user sees that the package install fails. _I_ don't want them to go to neurostars -- even if nipype wants that. I want that bug, because it is fairly clear that _I_ should deal with it. I can do that better and quicker, if there is a single forum (or even better a bug tracker) for all these bugs -- regardless of the actual software in question. For everything else, I prefer a pass-through of some kind that neither burdens me, nor the user. Michael -- Michael Hanke http://mih.voxindeserto.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.chr at mail.ru Tue Aug 25 20:26:23 2015 From: h.chr at mail.ru (Horea Christian) Date: Tue, 25 Aug 2015 20:26:23 +0200 Subject: [Neuroimaging] Cannot edit some NIfTI header fields Message-ID: <1440527183.21438.21.camel@mail.ru> Hi, I am experiencing some issues with editing my NIfTI headers. Apparently I can save some tags after I edit them, but not others. I have pasted all my outputs here: https://neurostars.org/p/3362/ Can you help me out? I have received the following suggestion: >Just guessing, but I wonder if you are trying to edit the fields >supporting the affines, and then saving the image? >If you are doing this, then the image save takes the image affine and >applies it to the header, overwriting any changes you made the qform >fields, including pixdim. >If you want to change the qform / sform affine in the image header, >use the ``img.set_qform`` and `img.set_sform`` methods. I have looked into these functions, and I cannot figure out how I could use them to effect the changes I waqnt in the header. The most important thing right now would be to be able to edit pixdim[3]. For some reason this is set to the slice spacing (which is 0.5mm) but I want it set to (and I believe it *should* be set to) the slice thickness, which is 0.3mm. BEst Regards, Christian From vsochat at stanford.edu Wed Aug 26 17:10:30 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 08:10:30 -0700 Subject: [Neuroimaging] Site Discussion Message-ID: Hi Group, Ben and I are having some discussion on the higher level goals of the site, and want to bring everyone in. In summary, we want something that is easy to contribute content to, and has continuous integration for previewing updates. I am wondering, what was wrong with the initial look of the site ? Was it that sphinx is hard to update? Jekyll has significant bugs that likely will only be worked out with hacks. I'm not convinced that hosting on github pages with jekyll is somehow ideal or easier than say, something like Google Sites for such a simple portal. I'm not convinced that a platform like jekyll offers improved code and documentation over a standard solution like sphinx. To go to extremes, even a free hosted blog site would be a much easier workflow. There is definitely work to be done to improve the look of the template, and arguably we can get it looking more along the lines of something like sphinx, but I want to place this front and center to the group before more time is spent on it. I'm willing to invest time in just about anything in terms of developing an ideal solution, but I want to make sure said solution is in line with the goal for this site. It seems that Flask was not appropriate, and I'm slightly dis-illusion-ed with the bugs that are being revealed a-la jekyll. Let's bring this to discussion properly. Best, Vanessa -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Wed Aug 26 17:21:39 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 08:21:39 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: Message-ID: A suggestion that would get Jekyll to work - use it for the main site base, and have a free service that allows for custom templates for these "blog posts." Given the customization, said free service would be "hidden" in the site. That would mean the continuous integration would function fine for the main site pages (likely updates would be few), the hosting could be on github pages, and a more common activity like pulling out your smartphone and writing a quick blog post from a conference would be easy, better integrated with social media, etc. A person who is in the community and not familiar with github would be much better empowered to contribute! On Wed, Aug 26, 2015 at 8:10 AM, vanessa sochat wrote: > Hi Group, > > Ben and I are having some discussion > on > the higher level goals of the site, and want to bring everyone in. In > summary, we want something that is easy to contribute content to, and has > continuous integration for previewing updates. I am wondering, what was > wrong with the initial look of the site ? Was > it that sphinx is hard to update? Jekyll has significant bugs that likely > will only be worked out with hacks. I'm not convinced that hosting on > github pages with jekyll is somehow ideal or easier than say, something > like Google Sites for such a simple portal. I'm not convinced that a > platform like jekyll offers improved code and documentation over a standard > solution like sphinx. To go to extremes, even a free hosted blog site would > be a much easier workflow. There is definitely work to be done to improve > the look of the template, and arguably we can get it looking more along the > lines of something like sphinx, but I want to place this front and center > to the group before more time is spent on it. I'm willing to invest time in > just about anything in terms of developing an ideal solution, but I want to > make sure said solution is in line with the goal for this site. It seems > that Flask was not appropriate, and I'm slightly dis-illusion-ed with the > bugs that are being revealed a-la jekyll. Let's bring this to discussion > properly. > > Best, > > Vanessa > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Wed Aug 26 17:25:54 2015 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 26 Aug 2015 08:25:54 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: Message-ID: Fwiw in case the problem is Jekyll itself, then there are a bunch of Jekyll competitors out there. Some prominent ones written in python include pelican, mkdocs, hyde, ... (I haven't used any of them myself though, just heard mention of them go by.) On Aug 26, 2015 8:12 AM, "vanessa sochat" wrote: > Hi Group, > > Ben and I are having some discussion > on > the higher level goals of the site, and want to bring everyone in. In > summary, we want something that is easy to contribute content to, and has > continuous integration for previewing updates. I am wondering, what was > wrong with the initial look of the site ? Was > it that sphinx is hard to update? Jekyll has significant bugs that likely > will only be worked out with hacks. I'm not convinced that hosting on > github pages with jekyll is somehow ideal or easier than say, something > like Google Sites for such a simple portal. I'm not convinced that a > platform like jekyll offers improved code and documentation over a standard > solution like sphinx. To go to extremes, even a free hosted blog site would > be a much easier workflow. There is definitely work to be done to improve > the look of the template, and arguably we can get it looking more along the > lines of something like sphinx, but I want to place this front and center > to the group before more time is spent on it. I'm willing to invest time in > just about anything in terms of developing an ideal solution, but I want to > make sure said solution is in line with the goal for this site. It seems > that Flask was not appropriate, and I'm slightly dis-illusion-ed with the > bugs that are being revealed a-la jekyll. Let's bring this to discussion > properly. > > Best, > > Vanessa > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Wed Aug 26 17:32:39 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 26 Aug 2015 16:32:39 +0100 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: Message-ID: Hi, On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat wrote: > Hi Group, > > Ben and I are having some discussion on the higher level goals of the site, > and want to bring everyone in. In summary, we want something that is easy to > contribute content to, and has continuous integration for previewing > updates. I am wondering, what was wrong with the initial look of the site? > Was it that sphinx is hard to update? Actually, I think that sphinx is a very good option, and most other scientific Python sites use sphinx for their main pages. The particular template that we were using was a little dated and ugly, but I bet that could be improved. Most if not all developers are perfectly capable of building the sphinx documentation locally to preview it, but we can also do what other projects are doing, and build / publish the docs in some temporary place for each commit, using an entry in the travis-ci matrix of jobs. I think Ariel was particularly attracted to Jekyll / github pages, because it is very easy to get a rendered version to look at with a git push, and although that is generally desirable, I think building / reviewing locally is at least as important. So - if it were entirely up to me - I would prefer we go back to sphinx, on the basis that it is a very familiar workflow to most Python developers. Thanks very much for doing all this work by the way - it's very helpful, and I'm sorry that we are going round and round. See you, Matthew From vsochat at stanford.edu Wed Aug 26 18:23:18 2015 From: vsochat at stanford.edu (Vanessa Villamia Sochat) Date: Wed, 26 Aug 2015 16:23:18 +0000 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: Message-ID: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Hi everyone! I thought more about this on my walk - here is a reasonable game plan! I will do the work to put together a solution that integrates Ariel's original vision with ghpages, the parts of Jekyll that do work, and a more non developer friendly integrated blog. I think this could meet all of our goals and be a solution that better integrates social aspects of our community - github just doesn't specialize in blogging but many services do. If that does not work, then we can go to Sphinx. Boum! I will send out an update likely during weekend time when I've tested some things. Best, Vanessa > On Aug 26, 2015, at 8:32 AM, Matthew Brett wrote: > > Hi, > >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat wrote: >> Hi Group, >> >> Ben and I are having some discussion on the higher level goals of the site, >> and want to bring everyone in. In summary, we want something that is easy to >> contribute content to, and has continuous integration for previewing >> updates. I am wondering, what was wrong with the initial look of the site? >> Was it that sphinx is hard to update? > > Actually, I think that sphinx is a very good option, and most other > scientific Python sites use sphinx for their main pages. > > The particular template that we were using was a little dated and > ugly, but I bet that could be improved. > > Most if not all developers are perfectly capable of building the > sphinx documentation locally to preview it, but we can also do what > other projects are doing, and build / publish the docs in some > temporary place for each commit, using an entry in the travis-ci > matrix of jobs. > > I think Ariel was particularly attracted to Jekyll / github pages, > because it is very easy to get a rendered version to look at with a > git push, and although that is generally desirable, I think building / > reviewing locally is at least as important. > > So - if it were entirely up to me - I would prefer we go back to > sphinx, on the basis that it is a very familiar workflow to most > Python developers. > > Thanks very much for doing all this work by the way - it's very > helpful, and I'm sorry that we are going round and round. > > See you, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From bcipolli at ucsd.edu Wed Aug 26 18:24:48 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Wed, 26 Aug 2015 09:24:48 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Thanks for all your work, Vanessa! Looking forward to see what you come up with. Ben On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < vsochat at stanford.edu> wrote: > Hi everyone! > > I thought more about this on my walk - here is a reasonable game plan! I > will do the work to put together a solution that integrates Ariel's > original vision with ghpages, the parts of Jekyll that do work, and a more > non developer friendly integrated blog. I think this could meet all of our > goals and be a solution that better integrates social aspects of our > community - github just doesn't specialize in blogging but many services > do. If that does not work, then we can go to Sphinx. Boum! > > I will send out an update likely during weekend time when I've tested some > things. > > Best, > > Vanessa > > > On Aug 26, 2015, at 8:32 AM, Matthew Brett > wrote: > > > > Hi, > > > >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat > wrote: > >> Hi Group, > >> > >> Ben and I are having some discussion on the higher level goals of the > site, > >> and want to bring everyone in. In summary, we want something that is > easy to > >> contribute content to, and has continuous integration for previewing > >> updates. I am wondering, what was wrong with the initial look of the > site? > >> Was it that sphinx is hard to update? > > > > Actually, I think that sphinx is a very good option, and most other > > scientific Python sites use sphinx for their main pages. > > > > The particular template that we were using was a little dated and > > ugly, but I bet that could be improved. > > > > Most if not all developers are perfectly capable of building the > > sphinx documentation locally to preview it, but we can also do what > > other projects are doing, and build / publish the docs in some > > temporary place for each commit, using an entry in the travis-ci > > matrix of jobs. > > > > I think Ariel was particularly attracted to Jekyll / github pages, > > because it is very easy to get a rendered version to look at with a > > git push, and although that is generally desirable, I think building / > > reviewing locally is at least as important. > > > > So - if it were entirely up to me - I would prefer we go back to > > sphinx, on the basis that it is a very familiar workflow to most > > Python developers. > > > > Thanks very much for doing all this work by the way - it's very > > helpful, and I'm sorry that we are going round and round. > > > > See you, > > > > Matthew > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Wed Aug 26 19:44:34 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 10:44:34 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: Message-ID: Hi all, Sorry for checking out on the technical discussions. It's been a busy couple of weeks! I did not particularly mind the appearance of the old site. I was more concerned with the content. In particular, quoting myself from back in May (archives of that list for that time-frame are apparently lost forever...): "It doesn't really represent the current state of affairs, and is s source of confusion for the unwary beginner. One proposal, that I would be happy to lead (if no one is really aching to do it themselves...) was to create a community portal on that page, where a large number of projects in this space could be represented through a (semi-) rational organization. Something with a front page that tells the beginner that there are many paths through this particular garden, and guides them along to what they need." The drash: - "large number of projects" precludes any particular project from appearing on the front page. I don't mind (and indeed have put) a link to the nipy github organization. See message here: https://mail.python.org/pipermail/neuroimaging/2015-July/000186.html - "(semi-) rational" means that the projects are organized in a directory in a way that someone just entering the field can easily browse. - "guides them along" would mean that we would want to add content on a more-or-less regular basis with some tutorials, links to events, rants, etc. I don't mind if we use sphinx, or pelican (or anything else), but I did choose jekyll because of its perceived advantages on the github platform (see discussion here: https://mail.python.org/pipermail/neuroimaging/2015-July/000174.html). I am always happy to be proven wrong for my choices, and for others to show me the way to the light. Cheers, Ariel On Wed, Aug 26, 2015 at 8:32 AM, Matthew Brett wrote: > Hi, > > On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat > wrote: > > Hi Group, > > > > Ben and I are having some discussion on the higher level goals of the > site, > > and want to bring everyone in. In summary, we want something that is > easy to > > contribute content to, and has continuous integration for previewing > > updates. I am wondering, what was wrong with the initial look of the > site? > > Was it that sphinx is hard to update? > > Actually, I think that sphinx is a very good option, and most other > scientific Python sites use sphinx for their main pages. > > The particular template that we were using was a little dated and > ugly, but I bet that could be improved. > > Most if not all developers are perfectly capable of building the > sphinx documentation locally to preview it, but we can also do what > other projects are doing, and build / publish the docs in some > temporary place for each commit, using an entry in the travis-ci > matrix of jobs. > > I think Ariel was particularly attracted to Jekyll / github pages, > because it is very easy to get a rendered version to look at with a > git push, and although that is generally desirable, I think building / > reviewing locally is at least as important. > > So - if it were entirely up to me - I would prefer we go back to > sphinx, on the basis that it is a very familiar workflow to most > Python developers. > > Thanks very much for doing all this work by the way - it's very > helpful, and I'm sorry that we are going round and round. > > See you, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Wed Aug 26 19:46:11 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 10:46:11 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Sorry - didn't see that one for some reason. On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < vsochat at stanford.edu> wrote: > Hi everyone! > > I thought more about this on my walk - here is a reasonable game plan! I > will do the work to put together a solution that integrates Ariel's > original vision with ghpages, the parts of Jekyll that do work, and a more > non developer friendly integrated blog. I think this could meet all of our > goals and be a solution that better integrates social aspects of our > community - github just doesn't specialize in blogging but many services > do. If that does not work, then we can go to Sphinx. Boum! > +1 Bada-boum! > I will send out an update likely during weekend time when I've tested some > things. > > Best, > > Vanessa > > > On Aug 26, 2015, at 8:32 AM, Matthew Brett > wrote: > > > > Hi, > > > >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat > wrote: > >> Hi Group, > >> > >> Ben and I are having some discussion on the higher level goals of the > site, > >> and want to bring everyone in. In summary, we want something that is > easy to > >> contribute content to, and has continuous integration for previewing > >> updates. I am wondering, what was wrong with the initial look of the > site? > >> Was it that sphinx is hard to update? > > > > Actually, I think that sphinx is a very good option, and most other > > scientific Python sites use sphinx for their main pages. > > > > The particular template that we were using was a little dated and > > ugly, but I bet that could be improved. > > > > Most if not all developers are perfectly capable of building the > > sphinx documentation locally to preview it, but we can also do what > > other projects are doing, and build / publish the docs in some > > temporary place for each commit, using an entry in the travis-ci > > matrix of jobs. > > > > I think Ariel was particularly attracted to Jekyll / github pages, > > because it is very easy to get a rendered version to look at with a > > git push, and although that is generally desirable, I think building / > > reviewing locally is at least as important. > > > > So - if it were entirely up to me - I would prefer we go back to > > sphinx, on the basis that it is a very familiar workflow to most > > Python developers. > > > > Thanks very much for doing all this work by the way - it's very > > helpful, and I'm sorry that we are going round and round. > > > > See you, > > > > Matthew > > _______________________________________________ > > Neuroimaging mailing list > > Neuroimaging at python.org > > https://mail.python.org/mailman/listinfo/neuroimaging > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Wed Aug 26 19:54:17 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 10:54:17 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: exactly :) https://www.youtube.com/watch?v=Uwzg7SYZKF0 On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: > Sorry - didn't see that one for some reason. > > On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < > vsochat at stanford.edu> wrote: > >> Hi everyone! >> >> I thought more about this on my walk - here is a reasonable game plan! I >> will do the work to put together a solution that integrates Ariel's >> original vision with ghpages, the parts of Jekyll that do work, and a more >> non developer friendly integrated blog. I think this could meet all of our >> goals and be a solution that better integrates social aspects of our >> community - github just doesn't specialize in blogging but many services >> do. If that does not work, then we can go to Sphinx. Boum! >> > > +1 > > Bada-boum! > > >> I will send out an update likely during weekend time when I've tested >> some things. >> >> Best, >> >> Vanessa >> >> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >> wrote: >> > >> > Hi, >> > >> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat >> wrote: >> >> Hi Group, >> >> >> >> Ben and I are having some discussion on the higher level goals of the >> site, >> >> and want to bring everyone in. In summary, we want something that is >> easy to >> >> contribute content to, and has continuous integration for previewing >> >> updates. I am wondering, what was wrong with the initial look of the >> site? >> >> Was it that sphinx is hard to update? >> > >> > Actually, I think that sphinx is a very good option, and most other >> > scientific Python sites use sphinx for their main pages. >> > >> > The particular template that we were using was a little dated and >> > ugly, but I bet that could be improved. >> > >> > Most if not all developers are perfectly capable of building the >> > sphinx documentation locally to preview it, but we can also do what >> > other projects are doing, and build / publish the docs in some >> > temporary place for each commit, using an entry in the travis-ci >> > matrix of jobs. >> > >> > I think Ariel was particularly attracted to Jekyll / github pages, >> > because it is very easy to get a rendered version to look at with a >> > git push, and although that is generally desirable, I think building / >> > reviewing locally is at least as important. >> > >> > So - if it were entirely up to me - I would prefer we go back to >> > sphinx, on the basis that it is a very familiar workflow to most >> > Python developers. >> > >> > Thanks very much for doing all this work by the way - it's very >> > helpful, and I'm sorry that we are going round and round. >> > >> > See you, >> > >> > Matthew >> > _______________________________________________ >> > Neuroimaging mailing list >> > Neuroimaging at python.org >> > https://mail.python.org/mailman/listinfo/neuroimaging >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Wed Aug 26 20:52:26 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 14:52:26 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Vanessa, I think we need to setup a hangout to discuss about this. Before we move forward with more coding. Figuring out the content will make designing the website much easier. By the way thank you for all the hard work. It's really inspiring. One important issue is what the portal will be about. And that is not currently clear. If the purpose is only to provide links to the other websites then we can just use the technology that we already have using sphinx and/or bootstrap/css or pelican. If the purpose is to make something that is really dynamic and people can add comments on the fly I think we really need something like django. But anyway. Can all the interested parties meet and discuss these following important issues: a) What the portal is about? We need to reach consensus. This is currently vague. b) Which projects are currently under the neuroimaging in python umbrella? Projects that do not share the same vision should not be promoted. I think. But maybe others think differently. I would like to hear the opinions on that. c) How the website and e-mail lists/forums will benefit and promote the work and the vision of this organization. d) Make some decisions on the technologies that we can use to support a, b, c. Maybe points b and c are not clear. So here are some clarifications. (b) is critical because for example I saw that you added in the website projects which are not currently under our github organization https://github.com/nipy. I think we need consensus to take such a decisions. (c) is also much related to Matthew's e-mail for supporting or not Neurostars for answering questions about the NIPY projects. This information and whatever we decide must be highlighted clearly in the portal. My feeling is that we really need such a meeting and that the discussion in the e-mail list was not that helpful. I know you specifically were happy to hangout as I suggested in a previous e-mail. I hope you can suggest a time and then resolve this and move on to a better future. Best regards, Eleftherios On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat wrote: > exactly :) > > https://www.youtube.com/watch?v=Uwzg7SYZKF0 > > On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: > >> Sorry - didn't see that one for some reason. >> >> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >> vsochat at stanford.edu> wrote: >> >>> Hi everyone! >>> >>> I thought more about this on my walk - here is a reasonable game plan! I >>> will do the work to put together a solution that integrates Ariel's >>> original vision with ghpages, the parts of Jekyll that do work, and a more >>> non developer friendly integrated blog. I think this could meet all of our >>> goals and be a solution that better integrates social aspects of our >>> community - github just doesn't specialize in blogging but many services >>> do. If that does not work, then we can go to Sphinx. Boum! >>> >> >> +1 >> >> Bada-boum! >> >> >>> I will send out an update likely during weekend time when I've tested >>> some things. >>> >>> Best, >>> >>> Vanessa >>> >>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>> wrote: >>> > >>> > Hi, >>> > >>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat >>> wrote: >>> >> Hi Group, >>> >> >>> >> Ben and I are having some discussion on the higher level goals of the >>> site, >>> >> and want to bring everyone in. In summary, we want something that is >>> easy to >>> >> contribute content to, and has continuous integration for previewing >>> >> updates. I am wondering, what was wrong with the initial look of the >>> site? >>> >> Was it that sphinx is hard to update? >>> > >>> > Actually, I think that sphinx is a very good option, and most other >>> > scientific Python sites use sphinx for their main pages. >>> > >>> > The particular template that we were using was a little dated and >>> > ugly, but I bet that could be improved. >>> > >>> > Most if not all developers are perfectly capable of building the >>> > sphinx documentation locally to preview it, but we can also do what >>> > other projects are doing, and build / publish the docs in some >>> > temporary place for each commit, using an entry in the travis-ci >>> > matrix of jobs. >>> > >>> > I think Ariel was particularly attracted to Jekyll / github pages, >>> > because it is very easy to get a rendered version to look at with a >>> > git push, and although that is generally desirable, I think building / >>> > reviewing locally is at least as important. >>> > >>> > So - if it were entirely up to me - I would prefer we go back to >>> > sphinx, on the basis that it is a very familiar workflow to most >>> > Python developers. >>> > >>> > Thanks very much for doing all this work by the way - it's very >>> > helpful, and I'm sorry that we are going round and round. >>> > >>> > See you, >>> > >>> > Matthew >>> > _______________________________________________ >>> > Neuroimaging mailing list >>> > Neuroimaging at python.org >>> > https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Wed Aug 26 21:09:42 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 12:09:42 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Eleftherios, A framework like Django is too heavy for a simple portal and blog, and we want to stay away from making something substantial that requires regular maintenance and care, and an actual server. We can achieve all the functionality of comments / social media, etc by integrating a blogging platform into a site that works on Github pages. Question b (sites included) and c (organization vision) needs discussion from everyone, and for the rest, here are my thoughts: a) What the portal is about? We need to reach consensus. This is currently > vague. > > A simple portal that gives nipy a brand, links to its products, and integrates some platform for us to easily write about it. If something more substantial than that is desired, then we first need to resolve where it will be hosted and who takes responsibility for its life. > c) How the website and e-mail lists/forums will benefit and promote the > work and the vision of this organization. > > For the work - the website blog will afford all the things that blogs afford: sharing ideas, examples, links, social media integration, etc. > d) Make some decisions on the technologies that we can use to support a, > b, c. > > Again, this is more about hosting and responsibility. > (b) is critical because for example I saw that you added in the website > projects which are not currently under our > github organization https://github.com/nipy. I think we need consensus to > take such a decisions. > > You should consider all current content on the site as Lorem Ipsum etc. I simply reproduced what is on the current site and did not make any "decisions." As I said earlier, content and template come *after* getting the site functioning. > (c) is also much related to Matthew's e-mail for supporting or not > Neurostars for answering questions about the NIPY > projects. This information and whatever we decide must be highlighted > clearly in the portal. > > Lorem,.. ipsum... :) > > > On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat > wrote: > >> exactly :) >> >> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >> >> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: >> >>> Sorry - didn't see that one for some reason. >>> >>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>> vsochat at stanford.edu> wrote: >>> >>>> Hi everyone! >>>> >>>> I thought more about this on my walk - here is a reasonable game plan! >>>> I will do the work to put together a solution that integrates Ariel's >>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>> non developer friendly integrated blog. I think this could meet all of our >>>> goals and be a solution that better integrates social aspects of our >>>> community - github just doesn't specialize in blogging but many services >>>> do. If that does not work, then we can go to Sphinx. Boum! >>>> >>> >>> +1 >>> >>> Bada-boum! >>> >>> >>>> I will send out an update likely during weekend time when I've tested >>>> some things. >>>> >>>> Best, >>>> >>>> Vanessa >>>> >>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>>> wrote: >>>> > >>>> > Hi, >>>> > >>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>> vsochat at stanford.edu> wrote: >>>> >> Hi Group, >>>> >> >>>> >> Ben and I are having some discussion on the higher level goals of >>>> the site, >>>> >> and want to bring everyone in. In summary, we want something that is >>>> easy to >>>> >> contribute content to, and has continuous integration for previewing >>>> >> updates. I am wondering, what was wrong with the initial look of the >>>> site? >>>> >> Was it that sphinx is hard to update? >>>> > >>>> > Actually, I think that sphinx is a very good option, and most other >>>> > scientific Python sites use sphinx for their main pages. >>>> > >>>> > The particular template that we were using was a little dated and >>>> > ugly, but I bet that could be improved. >>>> > >>>> > Most if not all developers are perfectly capable of building the >>>> > sphinx documentation locally to preview it, but we can also do what >>>> > other projects are doing, and build / publish the docs in some >>>> > temporary place for each commit, using an entry in the travis-ci >>>> > matrix of jobs. >>>> > >>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>> > because it is very easy to get a rendered version to look at with a >>>> > git push, and although that is generally desirable, I think building / >>>> > reviewing locally is at least as important. >>>> > >>>> > So - if it were entirely up to me - I would prefer we go back to >>>> > sphinx, on the basis that it is a very familiar workflow to most >>>> > Python developers. >>>> > >>>> > Thanks very much for doing all this work by the way - it's very >>>> > helpful, and I'm sorry that we are going round and round. >>>> > >>>> > See you, >>>> > >>>> > Matthew >>>> > _______________________________________________ >>>> > Neuroimaging mailing list >>>> > Neuroimaging at python.org >>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Wed Aug 26 21:16:23 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 12:16:23 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Eleftherios, On Wed, Aug 26, 2015 at 11:52 AM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hi Vanessa, > > I think we need to setup a hangout to discuss about this. Before we move > forward with more coding. > Figuring out the content will make designing the website much easier. > > By the way thank you for all the hard work. It's really inspiring. > > One important issue is what the portal will be about. And that is not > currently clear. > > If the purpose is only to provide links to the other websites then we can > just use the technology that > we already have using sphinx and/or bootstrap/css or pelican. > > If the purpose is to make something that is really dynamic and people can > add comments on the fly > I think we really need something like django. > > But anyway. Can all the interested parties meet and discuss these > following important issues: > > a) What the portal is about? We need to reach consensus. This is currently > vague. > See above: "...to create a community portal on that page, where a large number of projects in this space could be represented through a (semi-) rational organization. Something with a front page that tells the beginner that there are many paths through this particular garden, and guides them along to what they need" > b) Which projects are currently under the neuroimaging in python umbrella? > Projects that do not share the > same vision should not be promoted. I think. But maybe others think > differently. I would like to hear the > opinions on that. > > I think this vision should be inclusive. See more below for clarification. > c) How the website and e-mail lists/forums will benefit and promote the > work and the vision of this organization. > > d) Make some decisions on the technologies that we can use to support a, > b, c. > > Maybe points b and c are not clear. So here are some clarifications. > > (b) is critical because for example I saw that you added in the website > projects which are not currently under our > github organization https://github.com/nipy. I think we need consensus to > take such a decisions. > Yes - I think that a "neuroimaging in python" website should definitely include projects that are under that particular github organization. See also response to (a) above and "many paths". > > (c) is also much related to Matthew's e-mail for supporting or not > Neurostars for answering questions about the NIPY > projects. This information and whatever we decide must be highlighted > clearly in the portal. > > My feeling is that we really need such a meeting and that the discussion > in the e-mail list was not that helpful. > -1 to a meeting on this. Those take too much time, don't typically lead to decision making by consensus, and don't leave any trace, so don't facilitate consistent follow up. I strongly feel that a public email forum like this is exactly the right place to discuss these things. How would you feel if you discovered that the website was changed in some way that you don't like in a meeting that you hadn't attended? Actually, we already know how you feel about that... ;D Cheers, Ariel I know you specifically were happy to hangout as I suggested in a previous > e-mail. > > I hope you can suggest a time and then resolve this and move on to a > better future. > > Best regards, > Eleftherios > > > > > > > > > > > On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat > wrote: > >> exactly :) >> >> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >> >> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: >> >>> Sorry - didn't see that one for some reason. >>> >>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>> vsochat at stanford.edu> wrote: >>> >>>> Hi everyone! >>>> >>>> I thought more about this on my walk - here is a reasonable game plan! >>>> I will do the work to put together a solution that integrates Ariel's >>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>> non developer friendly integrated blog. I think this could meet all of our >>>> goals and be a solution that better integrates social aspects of our >>>> community - github just doesn't specialize in blogging but many services >>>> do. If that does not work, then we can go to Sphinx. Boum! >>>> >>> >>> +1 >>> >>> Bada-boum! >>> >>> >>>> I will send out an update likely during weekend time when I've tested >>>> some things. >>>> >>>> Best, >>>> >>>> Vanessa >>>> >>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>>> wrote: >>>> > >>>> > Hi, >>>> > >>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>> vsochat at stanford.edu> wrote: >>>> >> Hi Group, >>>> >> >>>> >> Ben and I are having some discussion on the higher level goals of >>>> the site, >>>> >> and want to bring everyone in. In summary, we want something that is >>>> easy to >>>> >> contribute content to, and has continuous integration for previewing >>>> >> updates. I am wondering, what was wrong with the initial look of the >>>> site? >>>> >> Was it that sphinx is hard to update? >>>> > >>>> > Actually, I think that sphinx is a very good option, and most other >>>> > scientific Python sites use sphinx for their main pages. >>>> > >>>> > The particular template that we were using was a little dated and >>>> > ugly, but I bet that could be improved. >>>> > >>>> > Most if not all developers are perfectly capable of building the >>>> > sphinx documentation locally to preview it, but we can also do what >>>> > other projects are doing, and build / publish the docs in some >>>> > temporary place for each commit, using an entry in the travis-ci >>>> > matrix of jobs. >>>> > >>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>> > because it is very easy to get a rendered version to look at with a >>>> > git push, and although that is generally desirable, I think building / >>>> > reviewing locally is at least as important. >>>> > >>>> > So - if it were entirely up to me - I would prefer we go back to >>>> > sphinx, on the basis that it is a very familiar workflow to most >>>> > Python developers. >>>> > >>>> > Thanks very much for doing all this work by the way - it's very >>>> > helpful, and I'm sorry that we are going round and round. >>>> > >>>> > See you, >>>> > >>>> > Matthew >>>> > _______________________________________________ >>>> > Neuroimaging mailing list >>>> > Neuroimaging at python.org >>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Wed Aug 26 21:20:43 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 12:20:43 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Eleftherios, it's good that you express concern because that means that you care about nipy, and we can work together to ensure that the vision is properly reflected in this site. It's typically not a straight path to converge on the right solution, and I think that it's ok we are needing to try different things. If it isn't too troubling to you, please let me implement what I have in mind, and then we can move forward with discussion on the points of content. On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat wrote: > Hi Eleftherios, > > A framework like Django is too heavy for a simple portal and blog, and we > want to stay away from making something substantial that requires regular > maintenance and care, and an actual server. We can achieve all the > functionality of comments / social media, etc by integrating a blogging > platform into a site that works on Github pages. Question b (sites > included) and c (organization vision) needs discussion from everyone, and > for the rest, here are my thoughts: > > a) What the portal is about? We need to reach consensus. This is currently >> vague. >> >> A simple portal that gives nipy a brand, links to its products, and > integrates some platform for us to easily write about it. If something more > substantial than that is desired, then we first need to resolve where it > will be hosted and who takes responsibility for its life. > > >> c) How the website and e-mail lists/forums will benefit and promote the >> work and the vision of this organization. >> >> For the work - the website blog will afford all the things that blogs > afford: sharing ideas, examples, links, social media integration, etc. > > >> d) Make some decisions on the technologies that we can use to support a, >> b, c. >> >> Again, this is more about hosting and responsibility. > > >> (b) is critical because for example I saw that you added in the website >> projects which are not currently under our >> github organization https://github.com/nipy. I think we need consensus >> to take such a decisions. >> >> You should consider all current content on the site as Lorem Ipsum etc. I > simply reproduced what is on the current site and did not make any > "decisions." As I said earlier, content and template come *after* getting > the site functioning. > > >> (c) is also much related to Matthew's e-mail for supporting or not >> Neurostars for answering questions about the NIPY >> projects. This information and whatever we decide must be highlighted >> clearly in the portal. >> >> Lorem,.. ipsum... > > :) > > > > > >> >> >> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >> wrote: >> >>> exactly :) >>> >>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>> >>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: >>> >>>> Sorry - didn't see that one for some reason. >>>> >>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>> vsochat at stanford.edu> wrote: >>>> >>>>> Hi everyone! >>>>> >>>>> I thought more about this on my walk - here is a reasonable game plan! >>>>> I will do the work to put together a solution that integrates Ariel's >>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>> non developer friendly integrated blog. I think this could meet all of our >>>>> goals and be a solution that better integrates social aspects of our >>>>> community - github just doesn't specialize in blogging but many services >>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>> >>>> >>>> +1 >>>> >>>> Bada-boum! >>>> >>>> >>>>> I will send out an update likely during weekend time when I've tested >>>>> some things. >>>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>>>> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>> vsochat at stanford.edu> wrote: >>>>> >> Hi Group, >>>>> >> >>>>> >> Ben and I are having some discussion on the higher level goals of >>>>> the site, >>>>> >> and want to bring everyone in. In summary, we want something that >>>>> is easy to >>>>> >> contribute content to, and has continuous integration for previewing >>>>> >> updates. I am wondering, what was wrong with the initial look of >>>>> the site? >>>>> >> Was it that sphinx is hard to update? >>>>> > >>>>> > Actually, I think that sphinx is a very good option, and most other >>>>> > scientific Python sites use sphinx for their main pages. >>>>> > >>>>> > The particular template that we were using was a little dated and >>>>> > ugly, but I bet that could be improved. >>>>> > >>>>> > Most if not all developers are perfectly capable of building the >>>>> > sphinx documentation locally to preview it, but we can also do what >>>>> > other projects are doing, and build / publish the docs in some >>>>> > temporary place for each commit, using an entry in the travis-ci >>>>> > matrix of jobs. >>>>> > >>>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>>> > because it is very easy to get a rendered version to look at with a >>>>> > git push, and although that is generally desirable, I think building >>>>> / >>>>> > reviewing locally is at least as important. >>>>> > >>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>> > Python developers. >>>>> > >>>>> > Thanks very much for doing all this work by the way - it's very >>>>> > helpful, and I'm sorry that we are going round and round. >>>>> > >>>>> > See you, >>>>> > >>>>> > Matthew >>>>> > _______________________________________________ >>>>> > Neuroimaging mailing list >>>>> > Neuroimaging at python.org >>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Wed Aug 26 21:26:23 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 15:26:23 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Vanessa, On Wed, Aug 26, 2015 at 3:09 PM, vanessa sochat wrote: > Hi Eleftherios, > > A framework like Django is too heavy for a simple portal and blog, and we > want to stay away from making something substantial that requires regular > maintenance and care, and an actual server. We can achieve all the > functionality of comments / social media, etc by integrating a blogging > platform into a site that works on Github pages. Question b (sites > included) and c (organization vision) needs discussion from everyone, and > for the rest, here are my thoughts: > Sure, sorry I am not saying that you should try and develop in Django. I am just saying it is more flexible if you want to build a more interactive websites than a static blog. > > a) What the portal is about? We need to reach consensus. This is currently >> vague. >> >> A simple portal that gives nipy a brand, links to its products, and > integrates some platform for us to easily write about it. If something more > substantial than that is desired, then we first need to resolve where it > will be hosted and who takes responsibility for its life. > Yes, we need a hangout to decide these things and see who wants to help with the actual work. This doesn't need to be all on your shoulders for example. > > >> c) How the website and e-mail lists/forums will benefit and promote the >> work and the vision of this organization. >> >> For the work - the website blog will afford all the things that blogs > afford: sharing ideas, examples, links, social media integration, etc. > Okay then why to post in this blog and not an individual projects's website? > > >> d) Make some decisions on the technologies that we can use to support a, >> b, c. >> >> Again, this is more about hosting and responsibility. > Okay. > > >> (b) is critical because for example I saw that you added in the website >> projects which are not currently under our >> github organization https://github.com/nipy. I think we need consensus >> to take such a decisions. >> >> You should consider all current content on the site as Lorem Ipsum etc. I > simply reproduced what is on the current site and did not make any > "decisions." As I said earlier, content and template come *after* getting > the site functioning. > This is were we disagree maybe. From my experience and discussion with web designers I realized that you actually need to have a much better idea of what is the content you have before creating the website. > > >> (c) is also much related to Matthew's e-mail for supporting or not >> Neurostars for answering questions about the NIPY >> projects. This information and whatever we decide must be highlighted >> clearly in the portal. >> >> Lorem,.. ipsum... > > :) > :) > > > > > >> >> >> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >> wrote: >> >>> exactly :) >>> >>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>> >>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: >>> >>>> Sorry - didn't see that one for some reason. >>>> >>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>> vsochat at stanford.edu> wrote: >>>> >>>>> Hi everyone! >>>>> >>>>> I thought more about this on my walk - here is a reasonable game plan! >>>>> I will do the work to put together a solution that integrates Ariel's >>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>> non developer friendly integrated blog. I think this could meet all of our >>>>> goals and be a solution that better integrates social aspects of our >>>>> community - github just doesn't specialize in blogging but many services >>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>> >>>> >>>> +1 >>>> >>>> Bada-boum! >>>> >>>> >>>>> I will send out an update likely during weekend time when I've tested >>>>> some things. >>>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>>>> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>> vsochat at stanford.edu> wrote: >>>>> >> Hi Group, >>>>> >> >>>>> >> Ben and I are having some discussion on the higher level goals of >>>>> the site, >>>>> >> and want to bring everyone in. In summary, we want something that >>>>> is easy to >>>>> >> contribute content to, and has continuous integration for previewing >>>>> >> updates. I am wondering, what was wrong with the initial look of >>>>> the site? >>>>> >> Was it that sphinx is hard to update? >>>>> > >>>>> > Actually, I think that sphinx is a very good option, and most other >>>>> > scientific Python sites use sphinx for their main pages. >>>>> > >>>>> > The particular template that we were using was a little dated and >>>>> > ugly, but I bet that could be improved. >>>>> > >>>>> > Most if not all developers are perfectly capable of building the >>>>> > sphinx documentation locally to preview it, but we can also do what >>>>> > other projects are doing, and build / publish the docs in some >>>>> > temporary place for each commit, using an entry in the travis-ci >>>>> > matrix of jobs. >>>>> > >>>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>>> > because it is very easy to get a rendered version to look at with a >>>>> > git push, and although that is generally desirable, I think building >>>>> / >>>>> > reviewing locally is at least as important. >>>>> > >>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>> > Python developers. >>>>> > >>>>> > Thanks very much for doing all this work by the way - it's very >>>>> > helpful, and I'm sorry that we are going round and round. >>>>> > >>>>> > See you, >>>>> > >>>>> > Matthew >>>>> > _______________________________________________ >>>>> > Neuroimaging mailing list >>>>> > Neuroimaging at python.org >>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Wed Aug 26 21:38:19 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 12:38:19 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Whoops: On Wed, Aug 26, 2015 at 12:16 PM, Ariel Rokem wrote: > Hi Eleftherios, > > On Wed, Aug 26, 2015 at 11:52 AM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> Hi Vanessa, >> >> I think we need to setup a hangout to discuss about this. Before we move >> forward with more coding. >> Figuring out the content will make designing the website much easier. >> >> By the way thank you for all the hard work. It's really inspiring. >> >> One important issue is what the portal will be about. And that is not >> currently clear. >> >> If the purpose is only to provide links to the other websites then we can >> just use the technology that >> we already have using sphinx and/or bootstrap/css or pelican. >> >> If the purpose is to make something that is really dynamic and people can >> add comments on the fly >> I think we really need something like django. >> >> But anyway. Can all the interested parties meet and discuss these >> following important issues: >> >> a) What the portal is about? We need to reach consensus. This is >> currently vague. >> > > See above: "...to create a community portal on that page, where a large > number of projects in this space could be represented through a (semi-) > rational organization. Something with a front page that tells the beginner > that there are many paths through this particular garden, and guides them > along to what they need" > > >> b) Which projects are currently under the neuroimaging in python >> umbrella? Projects that do not share the >> same vision should not be promoted. I think. But maybe others think >> differently. I would like to hear the >> opinions on that. >> >> > I think this vision should be inclusive. See more below for clarification. > > >> c) How the website and e-mail lists/forums will benefit and promote the >> work and the vision of this organization. >> >> d) Make some decisions on the technologies that we can use to support a, >> b, c. >> >> Maybe points b and c are not clear. So here are some clarifications. >> >> (b) is critical because for example I saw that you added in the website >> projects which are not currently under our >> github organization https://github.com/nipy. I think we need consensus >> to take such a decisions. >> > > Yes - I think that a "neuroimaging in python" website should definitely > include projects that are under that particular github organization. See > also response to (a) above and "many paths". > >> >> Meant to say: "... website should definitely include projects that are *not* under that particular github organization" (e.g. nilearn, etc.). I carefully wrote a statement of principles, so that we can look at a project and get a rough estimate whether it fits in or not (not based on whether it is under some specific github org): http://nipy.org/code-of-conduct/ For example, if a project is not released under a permissive open-source license ("open" and "collaborative"), it probably doesn't belong there. > (c) is also much related to Matthew's e-mail for supporting or not >> Neurostars for answering questions about the NIPY >> projects. This information and whatever we decide must be highlighted >> clearly in the portal. >> >> My feeling is that we really need such a meeting and that the discussion >> in the e-mail list was not that helpful. >> > > -1 to a meeting on this. Those take too much time, don't typically lead to > decision making by consensus, and don't leave any trace, so don't > facilitate consistent follow up. I strongly feel that a public email forum > like this is exactly the right place to discuss these things. How would you > feel if you discovered that the website was changed in some way that you > don't like in a meeting that you hadn't attended? Actually, we already know > how you feel about that... ;D > > Cheers, > > Ariel > > I know you specifically were happy to hangout as I suggested in a previous >> e-mail. >> >> I hope you can suggest a time and then resolve this and move on to a >> better future. >> >> Best regards, >> Eleftherios >> >> >> >> >> >> >> >> >> >> >> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >> wrote: >> >>> exactly :) >>> >>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>> >>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: >>> >>>> Sorry - didn't see that one for some reason. >>>> >>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>> vsochat at stanford.edu> wrote: >>>> >>>>> Hi everyone! >>>>> >>>>> I thought more about this on my walk - here is a reasonable game plan! >>>>> I will do the work to put together a solution that integrates Ariel's >>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>> non developer friendly integrated blog. I think this could meet all of our >>>>> goals and be a solution that better integrates social aspects of our >>>>> community - github just doesn't specialize in blogging but many services >>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>> >>>> >>>> +1 >>>> >>>> Bada-boum! >>>> >>>> >>>>> I will send out an update likely during weekend time when I've tested >>>>> some things. >>>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>>>> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>> vsochat at stanford.edu> wrote: >>>>> >> Hi Group, >>>>> >> >>>>> >> Ben and I are having some discussion on the higher level goals of >>>>> the site, >>>>> >> and want to bring everyone in. In summary, we want something that >>>>> is easy to >>>>> >> contribute content to, and has continuous integration for previewing >>>>> >> updates. I am wondering, what was wrong with the initial look of >>>>> the site? >>>>> >> Was it that sphinx is hard to update? >>>>> > >>>>> > Actually, I think that sphinx is a very good option, and most other >>>>> > scientific Python sites use sphinx for their main pages. >>>>> > >>>>> > The particular template that we were using was a little dated and >>>>> > ugly, but I bet that could be improved. >>>>> > >>>>> > Most if not all developers are perfectly capable of building the >>>>> > sphinx documentation locally to preview it, but we can also do what >>>>> > other projects are doing, and build / publish the docs in some >>>>> > temporary place for each commit, using an entry in the travis-ci >>>>> > matrix of jobs. >>>>> > >>>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>>> > because it is very easy to get a rendered version to look at with a >>>>> > git push, and although that is generally desirable, I think building >>>>> / >>>>> > reviewing locally is at least as important. >>>>> > >>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>> > Python developers. >>>>> > >>>>> > Thanks very much for doing all this work by the way - it's very >>>>> > helpful, and I'm sorry that we are going round and round. >>>>> > >>>>> > See you, >>>>> > >>>>> > Matthew >>>>> > _______________________________________________ >>>>> > Neuroimaging mailing list >>>>> > Neuroimaging at python.org >>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Wed Aug 26 21:42:56 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 15:42:56 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Ariel, >> a) What the portal is about? We need to reach consensus. This is >> currently vague. >> > > See above: "...to create a community portal on that page, where a large > number of projects in this space could be represented through a (semi-) > rational organization. Something with a front page that tells the beginner > that there are many paths through this particular garden, and guides them > along to what they need" > > Okay this answer here is very vague. Can you list the projects that you think that they have to be highlighted in the portal? > b) Which projects are currently under the neuroimaging in python umbrella? >> Projects that do not share the >> same vision should not be promoted. I think. But maybe others think >> differently. I would like to hear the >> opinions on that. >> >> > I think this vision should be inclusive. See more below for clarification. > > >> c) How the website and e-mail lists/forums will benefit and promote the >> work and the vision of this organization. >> >> d) Make some decisions on the technologies that we can use to support a, >> b, c. >> >> Maybe points b and c are not clear. So here are some clarifications. >> >> (b) is critical because for example I saw that you added in the website >> projects which are not currently under our >> github organization https://github.com/nipy. I think we need consensus >> to take such a decisions. >> > > Yes - I think that a "neuroimaging in python" website should definitely > include projects that are under that particular github organization. See > also response to (a) above and "many paths". > >> >> Wait this is not clear. See above. > (c) is also much related to Matthew's e-mail for supporting or not >> Neurostars for answering questions about the NIPY >> projects. This information and whatever we decide must be highlighted >> clearly in the portal. >> >> My feeling is that we really need such a meeting and that the discussion >> in the e-mail list was not that helpful. >> > > -1 to a meeting on this. Those take too much time, don't typically lead to > decision making by consensus, and don't leave any trace, so don't > facilitate consistent follow up. I strongly feel that a public email forum > like this is exactly the right place to discuss these things. How would you > feel if you discovered that the website was changed in some way that you > don't like in a meeting that you hadn't attended? Actually, we already know > how you feel about that... ;D > > I disagree. We very rarely have any hangouts/meetings for the projects. I personally don't like to have many meetings but for some things I would like to have a few. Especially the lead developers from the different projects should have some meetings to discuss issues of the organization. For example the last hangout where it was decided to split the nipy library to different smaller libraries had to happen. And it was quick and helpful. Cheers, Eleftherios > Cheers, > > Ariel > > I know you specifically were happy to hangout as I suggested in a previous >> e-mail. >> >> I hope you can suggest a time and then resolve this and move on to a >> better future. >> >> Best regards, >> Eleftherios >> >> >> >> >> >> >> >> >> >> >> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >> wrote: >> >>> exactly :) >>> >>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>> >>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: >>> >>>> Sorry - didn't see that one for some reason. >>>> >>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>> vsochat at stanford.edu> wrote: >>>> >>>>> Hi everyone! >>>>> >>>>> I thought more about this on my walk - here is a reasonable game plan! >>>>> I will do the work to put together a solution that integrates Ariel's >>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>> non developer friendly integrated blog. I think this could meet all of our >>>>> goals and be a solution that better integrates social aspects of our >>>>> community - github just doesn't specialize in blogging but many services >>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>> >>>> >>>> +1 >>>> >>>> Bada-boum! >>>> >>>> >>>>> I will send out an update likely during weekend time when I've tested >>>>> some things. >>>>> >>>>> Best, >>>>> >>>>> Vanessa >>>>> >>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>>>> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>> vsochat at stanford.edu> wrote: >>>>> >> Hi Group, >>>>> >> >>>>> >> Ben and I are having some discussion on the higher level goals of >>>>> the site, >>>>> >> and want to bring everyone in. In summary, we want something that >>>>> is easy to >>>>> >> contribute content to, and has continuous integration for previewing >>>>> >> updates. I am wondering, what was wrong with the initial look of >>>>> the site? >>>>> >> Was it that sphinx is hard to update? >>>>> > >>>>> > Actually, I think that sphinx is a very good option, and most other >>>>> > scientific Python sites use sphinx for their main pages. >>>>> > >>>>> > The particular template that we were using was a little dated and >>>>> > ugly, but I bet that could be improved. >>>>> > >>>>> > Most if not all developers are perfectly capable of building the >>>>> > sphinx documentation locally to preview it, but we can also do what >>>>> > other projects are doing, and build / publish the docs in some >>>>> > temporary place for each commit, using an entry in the travis-ci >>>>> > matrix of jobs. >>>>> > >>>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>>> > because it is very easy to get a rendered version to look at with a >>>>> > git push, and although that is generally desirable, I think building >>>>> / >>>>> > reviewing locally is at least as important. >>>>> > >>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>> > Python developers. >>>>> > >>>>> > Thanks very much for doing all this work by the way - it's very >>>>> > helpful, and I'm sorry that we are going round and round. >>>>> > >>>>> > See you, >>>>> > >>>>> > Matthew >>>>> > _______________________________________________ >>>>> > Neuroimaging mailing list >>>>> > Neuroimaging at python.org >>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Wed Aug 26 21:59:02 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 15:59:02 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Ariel, >>> Meant to say: "... website should definitely include projects that are > *not* under that particular github organization" (e.g. nilearn, etc.). I > carefully wrote a statement of principles, so that we can look at a project > and get a rough estimate whether it fits in or not (not based on whether it > is under some specific github org): http://nipy.org/code-of-conduct/ > > For example, if a project is not released under a permissive open-source > license ("open" and "collaborative"), it probably doesn't belong there. > > >> >>> I think this is then something that is not relevant to this list or to nipy. If you want to promote projects that are out of the nipy umbrella you need to create a new website otherwise you need to go and ask them if they want to be listed under nipy.org. Maybe they don't want. Maybe nilearn doesn't want to be under the nipy umbrella. Maybe they don't want to have nothing to do with us and that is why they made a new github organization. So, yeah. I am against promoting in nipy.org projects that have not agreed to be part of nipy.org Best, Eleftherios -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Wed Aug 26 22:08:45 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 16:08:45 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Vanessa, On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat wrote: > Eleftherios, it's good that you express concern because that means that > you care about nipy, and we can work together to ensure that the vision is > properly reflected in this site. It's typically not a straight path to > converge on the right solution, and I think that it's ok we are needing to > try different things. If it isn't too troubling to you, please let me > implement what I have in mind, and then we can move forward with discussion > on the points of content. > > Sure, be happy to prepare whatever you think will help the discussion. Can I ask you to summarize quickly here the next steps of development that you have in mind? Best, Eleftherios > On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat > wrote: > >> Hi Eleftherios, >> >> A framework like Django is too heavy for a simple portal and blog, and we >> want to stay away from making something substantial that requires regular >> maintenance and care, and an actual server. We can achieve all the >> functionality of comments / social media, etc by integrating a blogging >> platform into a site that works on Github pages. Question b (sites >> included) and c (organization vision) needs discussion from everyone, and >> for the rest, here are my thoughts: >> >> a) What the portal is about? We need to reach consensus. This is >>> currently vague. >>> >>> A simple portal that gives nipy a brand, links to its products, and >> integrates some platform for us to easily write about it. If something more >> substantial than that is desired, then we first need to resolve where it >> will be hosted and who takes responsibility for its life. >> >> >>> c) How the website and e-mail lists/forums will benefit and promote the >>> work and the vision of this organization. >>> >>> For the work - the website blog will afford all the things that blogs >> afford: sharing ideas, examples, links, social media integration, etc. >> >> >>> d) Make some decisions on the technologies that we can use to support a, >>> b, c. >>> >>> Again, this is more about hosting and responsibility. >> >> >>> (b) is critical because for example I saw that you added in the website >>> projects which are not currently under our >>> github organization https://github.com/nipy. I think we need consensus >>> to take such a decisions. >>> >>> You should consider all current content on the site as Lorem Ipsum etc. >> I simply reproduced what is on the current site and did not make any >> "decisions." As I said earlier, content and template come *after* getting >> the site functioning. >> >> >>> (c) is also much related to Matthew's e-mail for supporting or not >>> Neurostars for answering questions about the NIPY >>> projects. This information and whatever we decide must be highlighted >>> clearly in the portal. >>> >>> Lorem,.. ipsum... >> >> :) >> >> >> >> >> >>> >>> >>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >>> wrote: >>> >>>> exactly :) >>>> >>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>> >>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: >>>> >>>>> Sorry - didn't see that one for some reason. >>>>> >>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>> vsochat at stanford.edu> wrote: >>>>> >>>>>> Hi everyone! >>>>>> >>>>>> I thought more about this on my walk - here is a reasonable game >>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>> goals and be a solution that better integrates social aspects of our >>>>>> community - github just doesn't specialize in blogging but many services >>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>> >>>>> >>>>> +1 >>>>> >>>>> Bada-boum! >>>>> >>>>> >>>>>> I will send out an update likely during weekend time when I've tested >>>>>> some things. >>>>>> >>>>>> Best, >>>>>> >>>>>> Vanessa >>>>>> >>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>>>>> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>> vsochat at stanford.edu> wrote: >>>>>> >> Hi Group, >>>>>> >> >>>>>> >> Ben and I are having some discussion on the higher level goals of >>>>>> the site, >>>>>> >> and want to bring everyone in. In summary, we want something that >>>>>> is easy to >>>>>> >> contribute content to, and has continuous integration for >>>>>> previewing >>>>>> >> updates. I am wondering, what was wrong with the initial look of >>>>>> the site? >>>>>> >> Was it that sphinx is hard to update? >>>>>> > >>>>>> > Actually, I think that sphinx is a very good option, and most other >>>>>> > scientific Python sites use sphinx for their main pages. >>>>>> > >>>>>> > The particular template that we were using was a little dated and >>>>>> > ugly, but I bet that could be improved. >>>>>> > >>>>>> > Most if not all developers are perfectly capable of building the >>>>>> > sphinx documentation locally to preview it, but we can also do what >>>>>> > other projects are doing, and build / publish the docs in some >>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>> > matrix of jobs. >>>>>> > >>>>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>>>> > because it is very easy to get a rendered version to look at with a >>>>>> > git push, and although that is generally desirable, I think >>>>>> building / >>>>>> > reviewing locally is at least as important. >>>>>> > >>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>> > Python developers. >>>>>> > >>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>> > >>>>>> > See you, >>>>>> > >>>>>> > Matthew >>>>>> > _______________________________________________ >>>>>> > Neuroimaging mailing list >>>>>> > Neuroimaging at python.org >>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Wed Aug 26 23:10:46 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 14:10:46 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: On Wed, Aug 26, 2015 at 12:42 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hi Ariel, > > >>> a) What the portal is about? We need to reach consensus. This is >>> currently vague. >>> >> >> See above: "...to create a community portal on that page, where a large >> number of projects in this space could be represented through a (semi-) >> rational organization. Something with a front page that tells the beginner >> that there are many paths through this particular garden, and guides them >> along to what they need" >> >> > > Okay this answer here is very vague. Can you list the projects that you > think that they have to be highlighted in the portal? > Yes: http://nipy.org/project-directory/ BUT: I intended for it to be open-ended, and changeable through a PR. And it's definitely up for discussion. For example, I might go in one day and add this one: http://cni.github.io/MRS/. Seems like a legitimate addition: It's not under the "nipy" github org, but it is a neuroimaging software project, written in python, released under a permissive open source license, and should be helpful for some people (if they do MRS). Any reason not to add that one (or things like it?). Does that example clarify what I mean? > > >> b) Which projects are currently under the neuroimaging in python >>> umbrella? Projects that do not share the >>> same vision should not be promoted. I think. But maybe others think >>> differently. I would like to hear the >>> opinions on that. >>> >>> >> I think this vision should be inclusive. See more below for clarification. >> >> >>> c) How the website and e-mail lists/forums will benefit and promote the >>> work and the vision of this organization. >>> >>> d) Make some decisions on the technologies that we can use to support a, >>> b, c. >>> >>> Maybe points b and c are not clear. So here are some clarifications. >>> >>> (b) is critical because for example I saw that you added in the website >>> projects which are not currently under our >>> github organization https://github.com/nipy. I think we need consensus >>> to take such a decisions. >>> >> >> Yes - I think that a "neuroimaging in python" website should definitely >> include projects that are under that particular github organization. See >> also response to (a) above and "many paths". >> >>> >>> Wait this is not clear. See above. > > >> (c) is also much related to Matthew's e-mail for supporting or not >>> Neurostars for answering questions about the NIPY >>> projects. This information and whatever we decide must be highlighted >>> clearly in the portal. >>> >>> My feeling is that we really need such a meeting and that the discussion >>> in the e-mail list was not that helpful. >>> >> >> -1 to a meeting on this. Those take too much time, don't typically lead >> to decision making by consensus, and don't leave any trace, so don't >> facilitate consistent follow up. I strongly feel that a public email forum >> like this is exactly the right place to discuss these things. How would you >> feel if you discovered that the website was changed in some way that you >> don't like in a meeting that you hadn't attended? Actually, we already know >> how you feel about that... ;D >> >> > I disagree. We very rarely have any hangouts/meetings for the projects. I > personally don't like to have many meetings but for some things I would > like to have a few. Especially the lead developers from the different > projects should have some meetings to discuss issues of the organization. > For example the last hangout where it was decided to split the nipy library > to different smaller libraries had to happen. And it was quick and helpful. > > Cheers, > Eleftherios > > >> Cheers, >> >> Ariel >> >> I know you specifically were happy to hangout as I suggested in a >>> previous e-mail. >>> >>> I hope you can suggest a time and then resolve this and move on to a >>> better future. >>> >>> Best regards, >>> Eleftherios >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >>> wrote: >>> >>>> exactly :) >>>> >>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>> >>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem wrote: >>>> >>>>> Sorry - didn't see that one for some reason. >>>>> >>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>> vsochat at stanford.edu> wrote: >>>>> >>>>>> Hi everyone! >>>>>> >>>>>> I thought more about this on my walk - here is a reasonable game >>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>> goals and be a solution that better integrates social aspects of our >>>>>> community - github just doesn't specialize in blogging but many services >>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>> >>>>> >>>>> +1 >>>>> >>>>> Bada-boum! >>>>> >>>>> >>>>>> I will send out an update likely during weekend time when I've tested >>>>>> some things. >>>>>> >>>>>> Best, >>>>>> >>>>>> Vanessa >>>>>> >>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett >>>>>> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>> vsochat at stanford.edu> wrote: >>>>>> >> Hi Group, >>>>>> >> >>>>>> >> Ben and I are having some discussion on the higher level goals of >>>>>> the site, >>>>>> >> and want to bring everyone in. In summary, we want something that >>>>>> is easy to >>>>>> >> contribute content to, and has continuous integration for >>>>>> previewing >>>>>> >> updates. I am wondering, what was wrong with the initial look of >>>>>> the site? >>>>>> >> Was it that sphinx is hard to update? >>>>>> > >>>>>> > Actually, I think that sphinx is a very good option, and most other >>>>>> > scientific Python sites use sphinx for their main pages. >>>>>> > >>>>>> > The particular template that we were using was a little dated and >>>>>> > ugly, but I bet that could be improved. >>>>>> > >>>>>> > Most if not all developers are perfectly capable of building the >>>>>> > sphinx documentation locally to preview it, but we can also do what >>>>>> > other projects are doing, and build / publish the docs in some >>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>> > matrix of jobs. >>>>>> > >>>>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>>>> > because it is very easy to get a rendered version to look at with a >>>>>> > git push, and although that is generally desirable, I think >>>>>> building / >>>>>> > reviewing locally is at least as important. >>>>>> > >>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>> > Python developers. >>>>>> > >>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>> > >>>>>> > See you, >>>>>> > >>>>>> > Matthew >>>>>> > _______________________________________________ >>>>>> > Neuroimaging mailing list >>>>>> > Neuroimaging at python.org >>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Wed Aug 26 23:53:52 2015 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 26 Aug 2015 23:53:52 +0200 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: Message-ID: <20150826215352.GA891212@phare.normalesup.org> On Wed, Aug 26, 2015 at 04:32:39PM +0100, Matthew Brett wrote: > Actually, I think that sphinx is a very good option, and most other > scientific Python sites use sphinx for their main pages. +1 > The particular template that we were using was a little dated and > ugly, but I bet that could be improved. It wasn't that bad, honestly. I'd even say that it was pretty good. Ga?l From gael.varoquaux at normalesup.org Wed Aug 26 23:57:15 2015 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 26 Aug 2015 23:57:15 +0200 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: <20150826215715.GB891212@phare.normalesup.org> On Wed, Aug 26, 2015 at 03:59:02PM -0400, Eleftherios Garyfallidis wrote: > I think this is then something that is not relevant to this list or to > nipy. If you want to promote projects that are out of the nipy umbrella > you need to create a new website otherwise you need to go and ask them > if they want to be listed under nipy.org. Maybe they don't want. Maybe > nilearn doesn't want to be under the nipy umbrella. Maybe they don't > want to have nothing to do with us and that is why they made a new > github organization.? We'd love too. It's just that from a project management perspective, having a different organization for each project just make more sense (sperate administration rights, specific github page repo, easyness to create multiple messy repos). Ga?l From arokem at gmail.com Thu Aug 27 00:02:38 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 15:02:38 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hey Eleftherios, On Wed, Aug 26, 2015 at 12:59 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hi Ariel, > > >>>> Meant to say: "... website should definitely include projects that are >> *not* under that particular github organization" (e.g. nilearn, etc.). I >> carefully wrote a statement of principles, so that we can look at a project >> and get a rough estimate whether it fits in or not (not based on whether it >> is under some specific github org): http://nipy.org/code-of-conduct/ >> >> For example, if a project is not released under a permissive open-source >> license ("open" and "collaborative"), it probably doesn't belong there. >> >> >>> >>>> > I think this is then something that is not relevant to this list or to > nipy. If you want to promote projects that are out of the nipy umbrella you > need to create a new website otherwise you need to go and ask them if they > want to be listed under nipy.org. Maybe they don't want. Maybe nilearn > doesn't want to be under the nipy umbrella. Maybe they don't want to have > nothing to do with us and that is why they made a new github organization. > > I don't think that we need to ask anyone for permission to link to their website. That said my expectation was that generally developers would "opt in" through a PR to add their project to the projects directory. > So, yeah. I am against promoting in nipy.org projects that have not > agreed to be part of nipy.org > > Best, > Eleftherios > > > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 27 00:03:16 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 15:03:16 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: <20150826215715.GB891212@phare.normalesup.org> References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> <20150826215715.GB891212@phare.normalesup.org> Message-ID: Hey Gael, On Wed, Aug 26, 2015 at 2:57 PM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > On Wed, Aug 26, 2015 at 03:59:02PM -0400, Eleftherios Garyfallidis wrote: > > I think this is then something that is not relevant to this list or to > > nipy. If you want to promote projects that are out of the nipy umbrella > > you need to create a new website otherwise you need to go and ask them > > if they want to be listed under nipy.org. Maybe they don't want. Maybe > > nilearn doesn't want to be under the nipy umbrella. Maybe they don't > > want to have nothing to do with us and that is why they made a new > > github organization. > > We'd love too. It's just that from a project management perspective, > having a different organization for each project just make more sense > (sperate administration rights, specific github page repo, easyness to > create multiple messy repos). > All that said, happy to hear that your happy for nilearn to be part of this list. It makes sense. > Ga?l > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 27 00:05:23 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 15:05:23 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hey Eleftherios, On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hi Vanessa, > > On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat > wrote: > >> Eleftherios, it's good that you express concern because that means that >> you care about nipy, and we can work together to ensure that the vision is >> properly reflected in this site. It's typically not a straight path to >> converge on the right solution, and I think that it's ok we are needing to >> try different things. If it isn't too troubling to you, please let me >> implement what I have in mind, and then we can move forward with discussion >> on the points of content. >> >> > Sure, be happy to prepare whatever you think will help the discussion. Can > I ask you to summarize quickly here the next steps of development that you > have in mind? > I think that question has been answered here: https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html > Best, > Eleftherios > > > >> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat >> wrote: >> >>> Hi Eleftherios, >>> >>> A framework like Django is too heavy for a simple portal and blog, and >>> we want to stay away from making something substantial that requires >>> regular maintenance and care, and an actual server. We can achieve all the >>> functionality of comments / social media, etc by integrating a blogging >>> platform into a site that works on Github pages. Question b (sites >>> included) and c (organization vision) needs discussion from everyone, and >>> for the rest, here are my thoughts: >>> >>> a) What the portal is about? We need to reach consensus. This is >>>> currently vague. >>>> >>>> A simple portal that gives nipy a brand, links to its products, and >>> integrates some platform for us to easily write about it. If something more >>> substantial than that is desired, then we first need to resolve where it >>> will be hosted and who takes responsibility for its life. >>> >>> >>>> c) How the website and e-mail lists/forums will benefit and promote the >>>> work and the vision of this organization. >>>> >>>> For the work - the website blog will afford all the things that blogs >>> afford: sharing ideas, examples, links, social media integration, etc. >>> >>> >>>> d) Make some decisions on the technologies that we can use to support >>>> a, b, c. >>>> >>>> Again, this is more about hosting and responsibility. >>> >>> >>>> (b) is critical because for example I saw that you added in the website >>>> projects which are not currently under our >>>> github organization https://github.com/nipy. I think we need consensus >>>> to take such a decisions. >>>> >>>> You should consider all current content on the site as Lorem Ipsum etc. >>> I simply reproduced what is on the current site and did not make any >>> "decisions." As I said earlier, content and template come *after* getting >>> the site functioning. >>> >>> >>>> (c) is also much related to Matthew's e-mail for supporting or not >>>> Neurostars for answering questions about the NIPY >>>> projects. This information and whatever we decide must be highlighted >>>> clearly in the portal. >>>> >>>> Lorem,.. ipsum... >>> >>> :) >>> >>> >>> >>> >>> >>>> >>>> >>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >>>> wrote: >>>> >>>>> exactly :) >>>>> >>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>> >>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>> wrote: >>>>> >>>>>> Sorry - didn't see that one for some reason. >>>>>> >>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>> vsochat at stanford.edu> wrote: >>>>>> >>>>>>> Hi everyone! >>>>>>> >>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> Bada-boum! >>>>>> >>>>>> >>>>>>> I will send out an update likely during weekend time when I've >>>>>>> tested some things. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Vanessa >>>>>>> >>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>> matthew.brett at gmail.com> wrote: >>>>>>> > >>>>>>> > Hi, >>>>>>> > >>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >> Hi Group, >>>>>>> >> >>>>>>> >> Ben and I are having some discussion on the higher level goals of >>>>>>> the site, >>>>>>> >> and want to bring everyone in. In summary, we want something that >>>>>>> is easy to >>>>>>> >> contribute content to, and has continuous integration for >>>>>>> previewing >>>>>>> >> updates. I am wondering, what was wrong with the initial look of >>>>>>> the site? >>>>>>> >> Was it that sphinx is hard to update? >>>>>>> > >>>>>>> > Actually, I think that sphinx is a very good option, and most other >>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>> > >>>>>>> > The particular template that we were using was a little dated and >>>>>>> > ugly, but I bet that could be improved. >>>>>>> > >>>>>>> > Most if not all developers are perfectly capable of building the >>>>>>> > sphinx documentation locally to preview it, but we can also do what >>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>>> > matrix of jobs. >>>>>>> > >>>>>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>>>>> > because it is very easy to get a rendered version to look at with a >>>>>>> > git push, and although that is generally desirable, I think >>>>>>> building / >>>>>>> > reviewing locally is at least as important. >>>>>>> > >>>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>>> > Python developers. >>>>>>> > >>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>> > >>>>>>> > See you, >>>>>>> > >>>>>>> > Matthew >>>>>>> > _______________________________________________ >>>>>>> > Neuroimaging mailing list >>>>>>> > Neuroimaging at python.org >>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Thu Aug 27 00:17:29 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 18:17:29 -0400 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi all, My initial personal point of view was to use one mailing list both for users and developers. That is neuroimaging at python.org (previously nipy-devel...) Then I saw that this list was not attracting enough questions. This is probably because we didn't promote this list enough. And maybe that should have been the first thing to do. Which we clearly didn't do. Then I thought okay the neuroimaging at python.org list is for developers and expert users and neurostars.org is for users who don't want to touch development and need feedback. But I have to say that there are some features in neurostars which can be dangerous. One of them is that people who answer questions get different status and reputation points. For example, the status of the person answering often says "trusted". This is misleading information. I think we need to be smarter here. There are no experts. We are research projects. We want a community which does not promote expertise but promotes understanding and good scientific practice. The focus of neurostars should be exactly that. I see that neurostars is still in a beta and I am wondering if we can change some of its settings. It is true that neurostars has attracted very quickly a relatively large audience. So, I am not sure if we should stop using it or not. But I will suggest something different. Can we continue using Neurostars with some different setup so that it promotes more understanding/discussion rather than expertise? To be more clear. Here is a summary of the important problems that StackOverflow has which also Neurostars can potentially have: This is from http://michael.richter.name/blogs/awhy-i-no-longer-contribute-to-stackoverflow which was posted previously in this thread. Thanx for posting this. The problems with StackOverflow are summarized in this list: 1. Poor pedagogy 2. Poor reward system 3. Poor community If we can change/block some of the functionality of neurostars maybe we can avoid those issues and build a strong community. If not then maybe we should consider using the current mailing list. I would like also to remind that we made nipy.org to reach a much higher level of community participation. So, please don't take this lightly. If we can improve neurostars to reach that goal we shall do it. If that is not possible with this technology then maybe just continue using what we currently have. I mean the list. So who are the stars in Neurostars? If the stars are the experts (us). Not very interesting. If the stars is everyone who helps in improving understanding and learning without looking for credits and points then this is much more interesting. Is there a way to promote this direction more? Also about something else. Because neurostars has become quite popular I think it will be difficult to do what Matthew says. Forward traffic in the mailing list. I am afraid we are past that point. Or we will have to do that in coordination for a long time. So, maybe improve what we have is the way to go. Sorry for the long e-mail. Let me know what you think. I hope this was helpful in some way. Best regards, Eleftherios On Tue, Aug 25, 2015 at 2:05 PM, Michael Hanke wrote: > Hey, > > On Tue, Aug 25, 2015 at 7:53 PM, Matthew Brett > wrote: > >> For the communities - it's surely reasonable to refer questions to the >> > chosen forum of the project - for example, I think I'm right in saying >> there's no controversy that nipype wants user questions to neurostars. >> I guess it's more complex to direct people who have more general >> neuroimaging questions. > > > Not just that. For nipype, imagine a user sees that the package install > fails. _I_ don't want > them to go to neurostars -- even if nipype wants that. I want that bug, > because it is fairly clear that _I_ should deal with > it. I can do that better and quicker, if there is a single forum (or even > better a bug tracker) for all these bugs > -- regardless of the actual software in question. For everything else, I > prefer a pass-through of some > kind that neither burdens me, nor the user. > > Michael > > -- > Michael Hanke > http://mih.voxindeserto.de > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Thu Aug 27 00:25:27 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 18:25:27 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: So another push for Jekyll? On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: > Hey Eleftherios, > > On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> Hi Vanessa, >> >> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >> wrote: >> >>> Eleftherios, it's good that you express concern because that means that >>> you care about nipy, and we can work together to ensure that the vision is >>> properly reflected in this site. It's typically not a straight path to >>> converge on the right solution, and I think that it's ok we are needing to >>> try different things. If it isn't too troubling to you, please let me >>> implement what I have in mind, and then we can move forward with discussion >>> on the points of content. >>> >>> >> Sure, be happy to prepare whatever you think will help the discussion. >> Can I ask you to summarize quickly here the next steps of development that >> you have in mind? >> > > I think that question has been answered here: > https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html > > >> Best, >> Eleftherios >> >> >> >>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat >>> wrote: >>> >>>> Hi Eleftherios, >>>> >>>> A framework like Django is too heavy for a simple portal and blog, and >>>> we want to stay away from making something substantial that requires >>>> regular maintenance and care, and an actual server. We can achieve all the >>>> functionality of comments / social media, etc by integrating a blogging >>>> platform into a site that works on Github pages. Question b (sites >>>> included) and c (organization vision) needs discussion from everyone, and >>>> for the rest, here are my thoughts: >>>> >>>> a) What the portal is about? We need to reach consensus. This is >>>>> currently vague. >>>>> >>>>> A simple portal that gives nipy a brand, links to its products, and >>>> integrates some platform for us to easily write about it. If something more >>>> substantial than that is desired, then we first need to resolve where it >>>> will be hosted and who takes responsibility for its life. >>>> >>>> >>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>> the work and the vision of this organization. >>>>> >>>>> For the work - the website blog will afford all the things that blogs >>>> afford: sharing ideas, examples, links, social media integration, etc. >>>> >>>> >>>>> d) Make some decisions on the technologies that we can use to support >>>>> a, b, c. >>>>> >>>>> Again, this is more about hosting and responsibility. >>>> >>>> >>>>> (b) is critical because for example I saw that you added in the >>>>> website projects which are not currently under our >>>>> github organization https://github.com/nipy. I think we need >>>>> consensus to take such a decisions. >>>>> >>>>> You should consider all current content on the site as Lorem Ipsum >>>> etc. I simply reproduced what is on the current site and did not make any >>>> "decisions." As I said earlier, content and template come *after* getting >>>> the site functioning. >>>> >>>> >>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>> Neurostars for answering questions about the NIPY >>>>> projects. This information and whatever we decide must be highlighted >>>>> clearly in the portal. >>>>> >>>>> Lorem,.. ipsum... >>>> >>>> :) >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >>>>> wrote: >>>>> >>>>>> exactly :) >>>>>> >>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>> >>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>> wrote: >>>>>> >>>>>>> Sorry - didn't see that one for some reason. >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> Hi everyone! >>>>>>>> >>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> Bada-boum! >>>>>>> >>>>>>> >>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>> tested some things. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Vanessa >>>>>>>> >>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>> > >>>>>>>> > Hi, >>>>>>>> > >>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >> Hi Group, >>>>>>>> >> >>>>>>>> >> Ben and I are having some discussion on the higher level goals >>>>>>>> of the site, >>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>> that is easy to >>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>> previewing >>>>>>>> >> updates. I am wondering, what was wrong with the initial look of >>>>>>>> the site? >>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>> > >>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>> other >>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>> > >>>>>>>> > The particular template that we were using was a little dated and >>>>>>>> > ugly, but I bet that could be improved. >>>>>>>> > >>>>>>>> > Most if not all developers are perfectly capable of building the >>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>> what >>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>>>> > matrix of jobs. >>>>>>>> > >>>>>>>> > I think Ariel was particularly attracted to Jekyll / github pages, >>>>>>>> > because it is very easy to get a rendered version to look at with >>>>>>>> a >>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>> building / >>>>>>>> > reviewing locally is at least as important. >>>>>>>> > >>>>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>>>> > Python developers. >>>>>>>> > >>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>> > >>>>>>>> > See you, >>>>>>>> > >>>>>>>> > Matthew >>>>>>>> > _______________________________________________ >>>>>>>> > Neuroimaging mailing list >>>>>>>> > Neuroimaging at python.org >>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 27 00:29:36 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 15:29:36 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > So another push for Jekyll? > > Yep. And if that turns out to be unsuccessful - sphinx. Big Bada-boum! > > On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: > >> Hey Eleftherios, >> >> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >> garyfallidis at gmail.com> wrote: >> >>> Hi Vanessa, >>> >>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>> wrote: >>> >>>> Eleftherios, it's good that you express concern because that means that >>>> you care about nipy, and we can work together to ensure that the vision is >>>> properly reflected in this site. It's typically not a straight path to >>>> converge on the right solution, and I think that it's ok we are needing to >>>> try different things. If it isn't too troubling to you, please let me >>>> implement what I have in mind, and then we can move forward with discussion >>>> on the points of content. >>>> >>>> >>> Sure, be happy to prepare whatever you think will help the discussion. >>> Can I ask you to summarize quickly here the next steps of development that >>> you have in mind? >>> >> >> I think that question has been answered here: >> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >> >> >>> Best, >>> Eleftherios >>> >>> >>> >>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat >>>> wrote: >>>> >>>>> Hi Eleftherios, >>>>> >>>>> A framework like Django is too heavy for a simple portal and blog, and >>>>> we want to stay away from making something substantial that requires >>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>> functionality of comments / social media, etc by integrating a blogging >>>>> platform into a site that works on Github pages. Question b (sites >>>>> included) and c (organization vision) needs discussion from everyone, and >>>>> for the rest, here are my thoughts: >>>>> >>>>> a) What the portal is about? We need to reach consensus. This is >>>>>> currently vague. >>>>>> >>>>>> A simple portal that gives nipy a brand, links to its products, and >>>>> integrates some platform for us to easily write about it. If something more >>>>> substantial than that is desired, then we first need to resolve where it >>>>> will be hosted and who takes responsibility for its life. >>>>> >>>>> >>>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>>> the work and the vision of this organization. >>>>>> >>>>>> For the work - the website blog will afford all the things that blogs >>>>> afford: sharing ideas, examples, links, social media integration, etc. >>>>> >>>>> >>>>>> d) Make some decisions on the technologies that we can use to support >>>>>> a, b, c. >>>>>> >>>>>> Again, this is more about hosting and responsibility. >>>>> >>>>> >>>>>> (b) is critical because for example I saw that you added in the >>>>>> website projects which are not currently under our >>>>>> github organization https://github.com/nipy. I think we need >>>>>> consensus to take such a decisions. >>>>>> >>>>>> You should consider all current content on the site as Lorem Ipsum >>>>> etc. I simply reproduced what is on the current site and did not make any >>>>> "decisions." As I said earlier, content and template come *after* getting >>>>> the site functioning. >>>>> >>>>> >>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>> Neurostars for answering questions about the NIPY >>>>>> projects. This information and whatever we decide must be highlighted >>>>>> clearly in the portal. >>>>>> >>>>>> Lorem,.. ipsum... >>>>> >>>>> :) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >>>>> > wrote: >>>>>> >>>>>>> exactly :) >>>>>>> >>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>> wrote: >>>>>>> >>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> Hi everyone! >>>>>>>>> >>>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>> >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> Bada-boum! >>>>>>>> >>>>>>>> >>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>> tested some things. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Vanessa >>>>>>>>> >>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>> > >>>>>>>>> > Hi, >>>>>>>>> > >>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >> Hi Group, >>>>>>>>> >> >>>>>>>>> >> Ben and I are having some discussion on the higher level goals >>>>>>>>> of the site, >>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>> that is easy to >>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>> previewing >>>>>>>>> >> updates. I am wondering, what was wrong with the initial look >>>>>>>>> of the site? >>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>> > >>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>> other >>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>> > >>>>>>>>> > The particular template that we were using was a little dated and >>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>> > >>>>>>>>> > Most if not all developers are perfectly capable of building the >>>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>>> what >>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>>>>> > matrix of jobs. >>>>>>>>> > >>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>> pages, >>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>> with a >>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>> building / >>>>>>>>> > reviewing locally is at least as important. >>>>>>>>> > >>>>>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>>>>> > Python developers. >>>>>>>>> > >>>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>> > >>>>>>>>> > See you, >>>>>>>>> > >>>>>>>>> > Matthew >>>>>>>>> > _______________________________________________ >>>>>>>>> > Neuroimaging mailing list >>>>>>>>> > Neuroimaging at python.org >>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 27 00:40:35 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 15:40:35 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: On Wed, Aug 26, 2015 at 3:29 PM, Ariel Rokem wrote: > > > On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> So another push for Jekyll? >> >> > Yep. And if that turns out to be unsuccessful - sphinx. > > Big Bada-boum! > Sorry - unless you have any other suggestions on how to go about this (apart from a hangout to discuss this)? > > >> >> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >> >>> Hey Eleftherios, >>> >>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>> garyfallidis at gmail.com> wrote: >>> >>>> Hi Vanessa, >>>> >>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>> wrote: >>>> >>>>> Eleftherios, it's good that you express concern because that means >>>>> that you care about nipy, and we can work together to ensure that the >>>>> vision is properly reflected in this site. It's typically not a straight >>>>> path to converge on the right solution, and I think that it's ok we are >>>>> needing to try different things. If it isn't too troubling to you, please >>>>> let me implement what I have in mind, and then we can move forward with >>>>> discussion on the points of content. >>>>> >>>>> >>>> Sure, be happy to prepare whatever you think will help the discussion. >>>> Can I ask you to summarize quickly here the next steps of development that >>>> you have in mind? >>>> >>> >>> I think that question has been answered here: >>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>> >>> >>>> Best, >>>> Eleftherios >>>> >>>> >>>> >>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat >>>> > wrote: >>>>> >>>>>> Hi Eleftherios, >>>>>> >>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>> and we want to stay away from making something substantial that requires >>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>> platform into a site that works on Github pages. Question b (sites >>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>> for the rest, here are my thoughts: >>>>>> >>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>> currently vague. >>>>>>> >>>>>>> A simple portal that gives nipy a brand, links to its products, and >>>>>> integrates some platform for us to easily write about it. If something more >>>>>> substantial than that is desired, then we first need to resolve where it >>>>>> will be hosted and who takes responsibility for its life. >>>>>> >>>>>> >>>>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>>>> the work and the vision of this organization. >>>>>>> >>>>>>> For the work - the website blog will afford all the things that >>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>> >>>>>> >>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>> support a, b, c. >>>>>>> >>>>>>> Again, this is more about hosting and responsibility. >>>>>> >>>>>> >>>>>>> (b) is critical because for example I saw that you added in the >>>>>>> website projects which are not currently under our >>>>>>> github organization https://github.com/nipy. I think we need >>>>>>> consensus to take such a decisions. >>>>>>> >>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>> the site functioning. >>>>>> >>>>>> >>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>> Neurostars for answering questions about the NIPY >>>>>>> projects. This information and whatever we decide must be >>>>>>> highlighted clearly in the portal. >>>>>>> >>>>>>> Lorem,.. ipsum... >>>>>> >>>>>> :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> exactly :) >>>>>>>> >>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >>>>>>>>>> Hi everyone! >>>>>>>>>> >>>>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>> >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Bada-boum! >>>>>>>>> >>>>>>>>> >>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>> tested some things. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Vanessa >>>>>>>>>> >>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>> > >>>>>>>>>> > Hi, >>>>>>>>>> > >>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >> Hi Group, >>>>>>>>>> >> >>>>>>>>>> >> Ben and I are having some discussion on the higher level goals >>>>>>>>>> of the site, >>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>> that is easy to >>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>> previewing >>>>>>>>>> >> updates. I am wondering, what was wrong with the initial look >>>>>>>>>> of the site? >>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>> > >>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>> other >>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>> > >>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>> and >>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>> > >>>>>>>>>> > Most if not all developers are perfectly capable of building the >>>>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>>>> what >>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>>>>>> > matrix of jobs. >>>>>>>>>> > >>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>> pages, >>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>> with a >>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>> building / >>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>> > >>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>>>>>> > Python developers. >>>>>>>>>> > >>>>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>> > >>>>>>>>>> > See you, >>>>>>>>>> > >>>>>>>>>> > Matthew >>>>>>>>>> > _______________________________________________ >>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Thu Aug 27 00:43:20 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 18:43:20 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: If you go back in the thread you will see that you have neglected many peoples suggestion that there is no reason to use non-pythonic tools for this task. So, you are basically wasting Vanessa's time and ignoring other peoples expertise on web development. The Jekyll idea is by default unsuccessful even if it works. Too much of a hassle to move to ruby for the specific task. There is no win with Jekyll here. I hope you can prove me wrong. On Wed, Aug 26, 2015 at 6:40 PM, Ariel Rokem wrote: > > > On Wed, Aug 26, 2015 at 3:29 PM, Ariel Rokem wrote: > >> >> >> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >> garyfallidis at gmail.com> wrote: >> >>> So another push for Jekyll? >>> >>> >> Yep. And if that turns out to be unsuccessful - sphinx. >> >> Big Bada-boum! >> > > Sorry - unless you have any other suggestions on how to go about this > (apart from a hangout to discuss this)? > > >> >> >>> >>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>> >>>> Hey Eleftherios, >>>> >>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>> garyfallidis at gmail.com> wrote: >>>> >>>>> Hi Vanessa, >>>>> >>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>>> wrote: >>>>> >>>>>> Eleftherios, it's good that you express concern because that means >>>>>> that you care about nipy, and we can work together to ensure that the >>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>> let me implement what I have in mind, and then we can move forward with >>>>>> discussion on the points of content. >>>>>> >>>>>> >>>>> Sure, be happy to prepare whatever you think will help the discussion. >>>>> Can I ask you to summarize quickly here the next steps of development that >>>>> you have in mind? >>>>> >>>> >>>> I think that question has been answered here: >>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>> >>>> >>>>> Best, >>>>> Eleftherios >>>>> >>>>> >>>>> >>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>> vsochat at stanford.edu> wrote: >>>>>> >>>>>>> Hi Eleftherios, >>>>>>> >>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>> and we want to stay away from making something substantial that requires >>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>> for the rest, here are my thoughts: >>>>>>> >>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>> currently vague. >>>>>>>> >>>>>>>> A simple portal that gives nipy a brand, links to its products, and >>>>>>> integrates some platform for us to easily write about it. If something more >>>>>>> substantial than that is desired, then we first need to resolve where it >>>>>>> will be hosted and who takes responsibility for its life. >>>>>>> >>>>>>> >>>>>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>>>>> the work and the vision of this organization. >>>>>>>> >>>>>>>> For the work - the website blog will afford all the things that >>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>> >>>>>>> >>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>> support a, b, c. >>>>>>>> >>>>>>>> Again, this is more about hosting and responsibility. >>>>>>> >>>>>>> >>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>> website projects which are not currently under our >>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>> consensus to take such a decisions. >>>>>>>> >>>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>>> the site functioning. >>>>>>> >>>>>>> >>>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>>> Neurostars for answering questions about the NIPY >>>>>>>> projects. This information and whatever we decide must be >>>>>>>> highlighted clearly in the portal. >>>>>>>> >>>>>>>> Lorem,.. ipsum... >>>>>>> >>>>>>> :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> exactly :) >>>>>>>>> >>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >>>>>>>>>>> Hi everyone! >>>>>>>>>>> >>>>>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> Bada-boum! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>> tested some things. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> >>>>>>>>>>> Vanessa >>>>>>>>>>> >>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>> > >>>>>>>>>>> > Hi, >>>>>>>>>>> > >>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>> >> Hi Group, >>>>>>>>>>> >> >>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>> goals of the site, >>>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>>> that is easy to >>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>> previewing >>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial look >>>>>>>>>>> of the site? >>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>> > >>>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>>> other >>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>> > >>>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>>> and >>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>> > >>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>> the >>>>>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>>>>> what >>>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>> travis-ci >>>>>>>>>>> > matrix of jobs. >>>>>>>>>>> > >>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>> pages, >>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>> with a >>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>> building / >>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>> > >>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back >>>>>>>>>>> to >>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>> most >>>>>>>>>>> > Python developers. >>>>>>>>>>> > >>>>>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>> > >>>>>>>>>>> > See you, >>>>>>>>>>> > >>>>>>>>>>> > Matthew >>>>>>>>>>> > _______________________________________________ >>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Vanessa Villamia Sochat >>>>>>>>> Stanford University >>>>>>>>> (603) 321-0676 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Thu Aug 27 00:44:00 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 15:44:00 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: *Continuous integration:* https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html *Gihub pages:* http://vsoch.github.io/nipy-jekyll/ All things seem to be in working order :) On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > So another push for Jekyll? > > > On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: > >> Hey Eleftherios, >> >> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >> garyfallidis at gmail.com> wrote: >> >>> Hi Vanessa, >>> >>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>> wrote: >>> >>>> Eleftherios, it's good that you express concern because that means that >>>> you care about nipy, and we can work together to ensure that the vision is >>>> properly reflected in this site. It's typically not a straight path to >>>> converge on the right solution, and I think that it's ok we are needing to >>>> try different things. If it isn't too troubling to you, please let me >>>> implement what I have in mind, and then we can move forward with discussion >>>> on the points of content. >>>> >>>> >>> Sure, be happy to prepare whatever you think will help the discussion. >>> Can I ask you to summarize quickly here the next steps of development that >>> you have in mind? >>> >> >> I think that question has been answered here: >> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >> >> >>> Best, >>> Eleftherios >>> >>> >>> >>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat >>>> wrote: >>>> >>>>> Hi Eleftherios, >>>>> >>>>> A framework like Django is too heavy for a simple portal and blog, and >>>>> we want to stay away from making something substantial that requires >>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>> functionality of comments / social media, etc by integrating a blogging >>>>> platform into a site that works on Github pages. Question b (sites >>>>> included) and c (organization vision) needs discussion from everyone, and >>>>> for the rest, here are my thoughts: >>>>> >>>>> a) What the portal is about? We need to reach consensus. This is >>>>>> currently vague. >>>>>> >>>>>> A simple portal that gives nipy a brand, links to its products, and >>>>> integrates some platform for us to easily write about it. If something more >>>>> substantial than that is desired, then we first need to resolve where it >>>>> will be hosted and who takes responsibility for its life. >>>>> >>>>> >>>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>>> the work and the vision of this organization. >>>>>> >>>>>> For the work - the website blog will afford all the things that blogs >>>>> afford: sharing ideas, examples, links, social media integration, etc. >>>>> >>>>> >>>>>> d) Make some decisions on the technologies that we can use to support >>>>>> a, b, c. >>>>>> >>>>>> Again, this is more about hosting and responsibility. >>>>> >>>>> >>>>>> (b) is critical because for example I saw that you added in the >>>>>> website projects which are not currently under our >>>>>> github organization https://github.com/nipy. I think we need >>>>>> consensus to take such a decisions. >>>>>> >>>>>> You should consider all current content on the site as Lorem Ipsum >>>>> etc. I simply reproduced what is on the current site and did not make any >>>>> "decisions." As I said earlier, content and template come *after* getting >>>>> the site functioning. >>>>> >>>>> >>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>> Neurostars for answering questions about the NIPY >>>>>> projects. This information and whatever we decide must be highlighted >>>>>> clearly in the portal. >>>>>> >>>>>> Lorem,.. ipsum... >>>>> >>>>> :) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat >>>>> > wrote: >>>>>> >>>>>>> exactly :) >>>>>>> >>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>> wrote: >>>>>>> >>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> Hi everyone! >>>>>>>>> >>>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>> >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> Bada-boum! >>>>>>>> >>>>>>>> >>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>> tested some things. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Vanessa >>>>>>>>> >>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>> > >>>>>>>>> > Hi, >>>>>>>>> > >>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >> Hi Group, >>>>>>>>> >> >>>>>>>>> >> Ben and I are having some discussion on the higher level goals >>>>>>>>> of the site, >>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>> that is easy to >>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>> previewing >>>>>>>>> >> updates. I am wondering, what was wrong with the initial look >>>>>>>>> of the site? >>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>> > >>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>> other >>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>> > >>>>>>>>> > The particular template that we were using was a little dated and >>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>> > >>>>>>>>> > Most if not all developers are perfectly capable of building the >>>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>>> what >>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>>>>> > matrix of jobs. >>>>>>>>> > >>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>> pages, >>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>> with a >>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>> building / >>>>>>>>> > reviewing locally is at least as important. >>>>>>>>> > >>>>>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>>>>> > Python developers. >>>>>>>>> > >>>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>> > >>>>>>>>> > See you, >>>>>>>>> > >>>>>>>>> > Matthew >>>>>>>>> > _______________________________________________ >>>>>>>>> > Neuroimaging mailing list >>>>>>>>> > Neuroimaging at python.org >>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 27 00:57:18 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 15:57:18 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat wrote: > *Continuous integration:* > > https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html > > *Gihub pages:* > http://vsoch.github.io/nipy-jekyll/ > > All things seem to be in working order :) > > Whoa. Chapeau! What's your more general sense? Is this going to be a PITA to maintain over time? I share the worries expressed by others here, and the desire to keep the maintenance requirements for this kind of thing low (see my inability to be helpful on this...). On the other hand, I am sure your learnings about this will be useful to many outside of this mailing list. > On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> So another push for Jekyll? >> >> >> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >> >>> Hey Eleftherios, >>> >>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>> garyfallidis at gmail.com> wrote: >>> >>>> Hi Vanessa, >>>> >>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>> wrote: >>>> >>>>> Eleftherios, it's good that you express concern because that means >>>>> that you care about nipy, and we can work together to ensure that the >>>>> vision is properly reflected in this site. It's typically not a straight >>>>> path to converge on the right solution, and I think that it's ok we are >>>>> needing to try different things. If it isn't too troubling to you, please >>>>> let me implement what I have in mind, and then we can move forward with >>>>> discussion on the points of content. >>>>> >>>>> >>>> Sure, be happy to prepare whatever you think will help the discussion. >>>> Can I ask you to summarize quickly here the next steps of development that >>>> you have in mind? >>>> >>> >>> I think that question has been answered here: >>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>> >>> >>>> Best, >>>> Eleftherios >>>> >>>> >>>> >>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat >>>> > wrote: >>>>> >>>>>> Hi Eleftherios, >>>>>> >>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>> and we want to stay away from making something substantial that requires >>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>> platform into a site that works on Github pages. Question b (sites >>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>> for the rest, here are my thoughts: >>>>>> >>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>> currently vague. >>>>>>> >>>>>>> A simple portal that gives nipy a brand, links to its products, and >>>>>> integrates some platform for us to easily write about it. If something more >>>>>> substantial than that is desired, then we first need to resolve where it >>>>>> will be hosted and who takes responsibility for its life. >>>>>> >>>>>> >>>>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>>>> the work and the vision of this organization. >>>>>>> >>>>>>> For the work - the website blog will afford all the things that >>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>> >>>>>> >>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>> support a, b, c. >>>>>>> >>>>>>> Again, this is more about hosting and responsibility. >>>>>> >>>>>> >>>>>>> (b) is critical because for example I saw that you added in the >>>>>>> website projects which are not currently under our >>>>>>> github organization https://github.com/nipy. I think we need >>>>>>> consensus to take such a decisions. >>>>>>> >>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>> the site functioning. >>>>>> >>>>>> >>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>> Neurostars for answering questions about the NIPY >>>>>>> projects. This information and whatever we decide must be >>>>>>> highlighted clearly in the portal. >>>>>>> >>>>>>> Lorem,.. ipsum... >>>>>> >>>>>> :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> exactly :) >>>>>>>> >>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >>>>>>>>>> Hi everyone! >>>>>>>>>> >>>>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>> >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Bada-boum! >>>>>>>>> >>>>>>>>> >>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>> tested some things. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Vanessa >>>>>>>>>> >>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>> > >>>>>>>>>> > Hi, >>>>>>>>>> > >>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >> Hi Group, >>>>>>>>>> >> >>>>>>>>>> >> Ben and I are having some discussion on the higher level goals >>>>>>>>>> of the site, >>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>> that is easy to >>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>> previewing >>>>>>>>>> >> updates. I am wondering, what was wrong with the initial look >>>>>>>>>> of the site? >>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>> > >>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>> other >>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>> > >>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>> and >>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>> > >>>>>>>>>> > Most if not all developers are perfectly capable of building the >>>>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>>>> what >>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>>>>>> > matrix of jobs. >>>>>>>>>> > >>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>> pages, >>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>> with a >>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>> building / >>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>> > >>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>>>>>> > Python developers. >>>>>>>>>> > >>>>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>> > >>>>>>>>>> > See you, >>>>>>>>>> > >>>>>>>>>> > Matthew >>>>>>>>>> > _______________________________________________ >>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 27 01:06:11 2015 From: arokem at gmail.com (Ariel Rokem) Date: Wed, 26 Aug 2015 16:06:11 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hey Eleftherios, On Wed, Aug 26, 2015 at 3:43 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > If you go back in the thread you will see that you have neglected many > peoples suggestion that there is no reason > to use non-pythonic tools for this task. So, you are basically wasting > Vanessa's time and ignoring other peoples expertise > on web development. > I don't think that I ignored anyone's suggestions (for example: https://mail.python.org/pipermail/neuroimaging/2015-August/000257.html), but I apologize if I neglected to respond in full to all the suggestions that were made. Vanessa apparently couldn't be stopped, even if I tried to :-) > The Jekyll idea is by default unsuccessful even if it works. Too much of a > hassle to move to ruby for the specific task. > There is no win with Jekyll here. I hope you can prove me wrong. > > On Wed, Aug 26, 2015 at 6:40 PM, Ariel Rokem wrote: > >> >> >> On Wed, Aug 26, 2015 at 3:29 PM, Ariel Rokem wrote: >> >>> >>> >>> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >>> garyfallidis at gmail.com> wrote: >>> >>>> So another push for Jekyll? >>>> >>>> >>> Yep. And if that turns out to be unsuccessful - sphinx. >>> >>> Big Bada-boum! >>> >> >> Sorry - unless you have any other suggestions on how to go about this >> (apart from a hangout to discuss this)? >> >> >>> >>> >>>> >>>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>>> >>>>> Hey Eleftherios, >>>>> >>>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>>> garyfallidis at gmail.com> wrote: >>>>> >>>>>> Hi Vanessa, >>>>>> >>>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>>> > wrote: >>>>>> >>>>>>> Eleftherios, it's good that you express concern because that means >>>>>>> that you care about nipy, and we can work together to ensure that the >>>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>>> let me implement what I have in mind, and then we can move forward with >>>>>>> discussion on the points of content. >>>>>>> >>>>>>> >>>>>> Sure, be happy to prepare whatever you think will help the >>>>>> discussion. Can I ask you to summarize quickly here the next steps of >>>>>> development that you have in mind? >>>>>> >>>>> >>>>> I think that question has been answered here: >>>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>>> >>>>> >>>>>> Best, >>>>>> Eleftherios >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> Hi Eleftherios, >>>>>>>> >>>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>>> and we want to stay away from making something substantial that requires >>>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>>> for the rest, here are my thoughts: >>>>>>>> >>>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>>> currently vague. >>>>>>>>> >>>>>>>>> A simple portal that gives nipy a brand, links to its products, >>>>>>>> and integrates some platform for us to easily write about it. If something >>>>>>>> more substantial than that is desired, then we first need to resolve where >>>>>>>> it will be hosted and who takes responsibility for its life. >>>>>>>> >>>>>>>> >>>>>>>>> c) How the website and e-mail lists/forums will benefit and >>>>>>>>> promote the work and the vision of this organization. >>>>>>>>> >>>>>>>>> For the work - the website blog will afford all the things that >>>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>>> >>>>>>>> >>>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>>> support a, b, c. >>>>>>>>> >>>>>>>>> Again, this is more about hosting and responsibility. >>>>>>>> >>>>>>>> >>>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>>> website projects which are not currently under our >>>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>>> consensus to take such a decisions. >>>>>>>>> >>>>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>>>> the site functioning. >>>>>>>> >>>>>>>> >>>>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>>>> Neurostars for answering questions about the NIPY >>>>>>>>> projects. This information and whatever we decide must be >>>>>>>>> highlighted clearly in the portal. >>>>>>>>> >>>>>>>>> Lorem,.. ipsum... >>>>>>>> >>>>>>>> :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >>>>>>>>>> exactly :) >>>>>>>>>> >>>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi everyone! >>>>>>>>>>>> >>>>>>>>>>>> I thought more about this on my walk - here is a reasonable >>>>>>>>>>>> game plan! I will do the work to put together a solution that integrates >>>>>>>>>>>> Ariel's original vision with ghpages, the parts of Jekyll that do work, and >>>>>>>>>>>> a more non developer friendly integrated blog. I think this could meet all >>>>>>>>>>>> of our goals and be a solution that better integrates social aspects of our >>>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>> Bada-boum! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>>> tested some things. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> Vanessa >>>>>>>>>>>> >>>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Hi, >>>>>>>>>>>> > >>>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>> >> Hi Group, >>>>>>>>>>>> >> >>>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>>> goals of the site, >>>>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>>>> that is easy to >>>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>>> previewing >>>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial >>>>>>>>>>>> look of the site? >>>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>>> > >>>>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>>>> other >>>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>>> > >>>>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>>>> and >>>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>>> > >>>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>>> the >>>>>>>>>>>> > sphinx documentation locally to preview it, but we can also >>>>>>>>>>>> do what >>>>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>>> travis-ci >>>>>>>>>>>> > matrix of jobs. >>>>>>>>>>>> > >>>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>>> pages, >>>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>>> with a >>>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>>> building / >>>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>>> > >>>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back >>>>>>>>>>>> to >>>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>>> most >>>>>>>>>>>> > Python developers. >>>>>>>>>>>> > >>>>>>>>>>>> > Thanks very much for doing all this work by the way - it's >>>>>>>>>>>> very >>>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>>> > >>>>>>>>>>>> > See you, >>>>>>>>>>>> > >>>>>>>>>>>> > Matthew >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>> Stanford University >>>>>>>>>> (603) 321-0676 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Thu Aug 27 01:13:28 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 16:13:28 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: This should be fairly easy to maintain. The main "package" pages are jekyll, meaning anyone can push a PR to the repo, preview on circle, and then deploy to github pages with approved changes. Developers know how to use github. The hidden blog is hosted at tumblr, which means that: - anyone can contribute content. We can let it get pushed or put it in a queue for approval. - posts can be done on mobile, or from email. In html, markdown, or standard text editor. - we can choose to "hide" the neuroimaging.tumblr.com url if we want, but it's really not so bad. - looks spiffy on mobile too :) - posts can be associated with authors, but don't need to be. - people can ask questions on posts, share posts, like them, etc. - integrated notifications, social media, apps, all the standard stuff you get with a platform like this. Tumblr has an API :) We kill lots of birds with a snakey thought stone. The site has CI, hosted for free on ghpages, and is an easy workflow for developers to update or add their packages. The site is also better integrated into the non-developer community, because anyone can contribute content easily without github, and we still have control over that content. If there is a huge redesign of the site, then the template would need to be updated on tumblr, but that really comes down to copy pasting the base code into the template editor. This was the idea that I had this morning. On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat wrote: > *Continuous integration:* > > https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html > > *Gihub pages:* > http://vsoch.github.io/nipy-jekyll/ > > All things seem to be in working order :) > > > > On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> So another push for Jekyll? >> >> >> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >> >>> Hey Eleftherios, >>> >>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>> garyfallidis at gmail.com> wrote: >>> >>>> Hi Vanessa, >>>> >>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>> wrote: >>>> >>>>> Eleftherios, it's good that you express concern because that means >>>>> that you care about nipy, and we can work together to ensure that the >>>>> vision is properly reflected in this site. It's typically not a straight >>>>> path to converge on the right solution, and I think that it's ok we are >>>>> needing to try different things. If it isn't too troubling to you, please >>>>> let me implement what I have in mind, and then we can move forward with >>>>> discussion on the points of content. >>>>> >>>>> >>>> Sure, be happy to prepare whatever you think will help the discussion. >>>> Can I ask you to summarize quickly here the next steps of development that >>>> you have in mind? >>>> >>> >>> I think that question has been answered here: >>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>> >>> >>>> Best, >>>> Eleftherios >>>> >>>> >>>> >>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat >>>> > wrote: >>>>> >>>>>> Hi Eleftherios, >>>>>> >>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>> and we want to stay away from making something substantial that requires >>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>> platform into a site that works on Github pages. Question b (sites >>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>> for the rest, here are my thoughts: >>>>>> >>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>> currently vague. >>>>>>> >>>>>>> A simple portal that gives nipy a brand, links to its products, and >>>>>> integrates some platform for us to easily write about it. If something more >>>>>> substantial than that is desired, then we first need to resolve where it >>>>>> will be hosted and who takes responsibility for its life. >>>>>> >>>>>> >>>>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>>>> the work and the vision of this organization. >>>>>>> >>>>>>> For the work - the website blog will afford all the things that >>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>> >>>>>> >>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>> support a, b, c. >>>>>>> >>>>>>> Again, this is more about hosting and responsibility. >>>>>> >>>>>> >>>>>>> (b) is critical because for example I saw that you added in the >>>>>>> website projects which are not currently under our >>>>>>> github organization https://github.com/nipy. I think we need >>>>>>> consensus to take such a decisions. >>>>>>> >>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>> the site functioning. >>>>>> >>>>>> >>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>> Neurostars for answering questions about the NIPY >>>>>>> projects. This information and whatever we decide must be >>>>>>> highlighted clearly in the portal. >>>>>>> >>>>>>> Lorem,.. ipsum... >>>>>> >>>>>> :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> exactly :) >>>>>>>> >>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >>>>>>>>>> Hi everyone! >>>>>>>>>> >>>>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>> >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Bada-boum! >>>>>>>>> >>>>>>>>> >>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>> tested some things. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Vanessa >>>>>>>>>> >>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>> > >>>>>>>>>> > Hi, >>>>>>>>>> > >>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >> Hi Group, >>>>>>>>>> >> >>>>>>>>>> >> Ben and I are having some discussion on the higher level goals >>>>>>>>>> of the site, >>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>> that is easy to >>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>> previewing >>>>>>>>>> >> updates. I am wondering, what was wrong with the initial look >>>>>>>>>> of the site? >>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>> > >>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>> other >>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>> > >>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>> and >>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>> > >>>>>>>>>> > Most if not all developers are perfectly capable of building the >>>>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>>>> what >>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>> > temporary place for each commit, using an entry in the travis-ci >>>>>>>>>> > matrix of jobs. >>>>>>>>>> > >>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>> pages, >>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>> with a >>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>> building / >>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>> > >>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back to >>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to most >>>>>>>>>> > Python developers. >>>>>>>>>> > >>>>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>> > >>>>>>>>>> > See you, >>>>>>>>>> > >>>>>>>>>> > Matthew >>>>>>>>>> > _______________________________________________ >>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Thu Aug 27 01:28:19 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 16:28:19 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: My suggestions for moving forward: 1) Feedback and desires for the template and look, best as issues on the repo. Ironically, we've been so focused on getting it working that I don't consider the style complete, and there were good suggestions that I haven't even looked at yet! If you have a style or element preference, please share, and it would be great to provide an example. First we fix those details. 2) Then content (specific packages, pages that are not posts, and where we tell users to ask for help, etc). I'm pretty indifferent about these things, and will be happy to go with the consensus. I can write documentation for the "contribute" page for the different flavors of contributors. 3) It would be good for others to then give the different kinds of contribution a try, and get feedback on those workflows. 4) Then when the CI, ghpages, blogging / site workflow, and documentation are properly in order, we deploy our little nipy. I'll start a first round of edits (step 1) this weekend. On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat wrote: > This should be fairly easy to maintain. The main "package" pages are > jekyll, meaning anyone can push a PR to the repo, preview on circle, and > then deploy to github pages with approved changes. Developers know how to > use github. > > The hidden blog is hosted at tumblr, which means that: > > - anyone can contribute content. We can let it get pushed or put it in a > queue for approval. > - posts can be done on mobile, or from email. In html, markdown, or > standard text editor. > - we can choose to "hide" the neuroimaging.tumblr.com url if we want, but > it's really not so bad. > - looks spiffy on mobile too :) > - posts can be associated with authors, but don't need to be. > - people can ask questions on posts, share posts, like them, etc. > - integrated notifications, social media, apps, all the standard stuff you > get with a platform like this. Tumblr has an API :) > > We kill lots of birds with a snakey thought stone. The site has CI, hosted > for free on ghpages, and is an easy workflow for developers to update or > add their packages. The site is also better integrated into the > non-developer community, because anyone can contribute content easily > without github, and we still have control over that content. > > If there is a huge redesign of the site, then the template would need to > be updated on tumblr, but that really comes down to copy pasting the base > code into the template editor. This was the idea that I had this morning. > > > On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat > wrote: > >> *Continuous integration:* >> >> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >> >> *Gihub pages:* >> http://vsoch.github.io/nipy-jekyll/ >> >> All things seem to be in working order :) >> >> >> >> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >> garyfallidis at gmail.com> wrote: >> >>> So another push for Jekyll? >>> >>> >>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>> >>>> Hey Eleftherios, >>>> >>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>> garyfallidis at gmail.com> wrote: >>>> >>>>> Hi Vanessa, >>>>> >>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>>> wrote: >>>>> >>>>>> Eleftherios, it's good that you express concern because that means >>>>>> that you care about nipy, and we can work together to ensure that the >>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>> let me implement what I have in mind, and then we can move forward with >>>>>> discussion on the points of content. >>>>>> >>>>>> >>>>> Sure, be happy to prepare whatever you think will help the discussion. >>>>> Can I ask you to summarize quickly here the next steps of development that >>>>> you have in mind? >>>>> >>>> >>>> I think that question has been answered here: >>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>> >>>> >>>>> Best, >>>>> Eleftherios >>>>> >>>>> >>>>> >>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>> vsochat at stanford.edu> wrote: >>>>>> >>>>>>> Hi Eleftherios, >>>>>>> >>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>> and we want to stay away from making something substantial that requires >>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>> for the rest, here are my thoughts: >>>>>>> >>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>> currently vague. >>>>>>>> >>>>>>>> A simple portal that gives nipy a brand, links to its products, and >>>>>>> integrates some platform for us to easily write about it. If something more >>>>>>> substantial than that is desired, then we first need to resolve where it >>>>>>> will be hosted and who takes responsibility for its life. >>>>>>> >>>>>>> >>>>>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>>>>> the work and the vision of this organization. >>>>>>>> >>>>>>>> For the work - the website blog will afford all the things that >>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>> >>>>>>> >>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>> support a, b, c. >>>>>>>> >>>>>>>> Again, this is more about hosting and responsibility. >>>>>>> >>>>>>> >>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>> website projects which are not currently under our >>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>> consensus to take such a decisions. >>>>>>>> >>>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>>> the site functioning. >>>>>>> >>>>>>> >>>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>>> Neurostars for answering questions about the NIPY >>>>>>>> projects. This information and whatever we decide must be >>>>>>>> highlighted clearly in the portal. >>>>>>>> >>>>>>>> Lorem,.. ipsum... >>>>>>> >>>>>>> :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> exactly :) >>>>>>>>> >>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >>>>>>>>>>> Hi everyone! >>>>>>>>>>> >>>>>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> Bada-boum! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>> tested some things. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> >>>>>>>>>>> Vanessa >>>>>>>>>>> >>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>> > >>>>>>>>>>> > Hi, >>>>>>>>>>> > >>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>> >> Hi Group, >>>>>>>>>>> >> >>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>> goals of the site, >>>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>>> that is easy to >>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>> previewing >>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial look >>>>>>>>>>> of the site? >>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>> > >>>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>>> other >>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>> > >>>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>>> and >>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>> > >>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>> the >>>>>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>>>>> what >>>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>> travis-ci >>>>>>>>>>> > matrix of jobs. >>>>>>>>>>> > >>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>> pages, >>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>> with a >>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>> building / >>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>> > >>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back >>>>>>>>>>> to >>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>> most >>>>>>>>>>> > Python developers. >>>>>>>>>>> > >>>>>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>> > >>>>>>>>>>> > See you, >>>>>>>>>>> > >>>>>>>>>>> > Matthew >>>>>>>>>>> > _______________________________________________ >>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Vanessa Villamia Sochat >>>>>>>>> Stanford University >>>>>>>>> (603) 321-0676 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Thu Aug 27 01:42:18 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Wed, 26 Aug 2015 16:42:18 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: I would suggest that, before working on #1-3, work on the documentation for the workflow, and any weirdness about the templates to work around bugs. Given the fears about the workflow and the need to work around Jekyll / CI bugs, I think we should make it clear what the current workflow entails. The docs don't have to be super-pretty, but I think at least a complete sketch of the workflow would be great to document and discuss while you start moving forward with the rest. Would you be up for doing that, Vanessa? I assume it wouldn't be too complex--just a few details about how to build on each system (not what's underneath the hood, just what the user has to do), and any requirements of template writing that are constrained by that. Thanks, Ben On Wed, Aug 26, 2015 at 4:28 PM, vanessa sochat wrote: > My suggestions for moving forward: > > > 1) > > Feedback and desires for the template and look, best as issues on the > repo. Ironically, we've been so focused on getting it working that I don't > consider the style complete, and there were good suggestions that I haven't > even looked at yet! If you have a style or element preference, please > share, and it would be great to provide an example. First we fix those > details. > > 2) > > Then content (specific packages, pages that are not posts, and where we > tell users to ask for help, etc). I'm pretty indifferent about these > things, and will be happy to go with the consensus. I can write > documentation for the "contribute" page for the different flavors of > contributors. > > 3) > > It would be good for others to then give the different kinds of > contribution a try, and get feedback on those workflows. > > 4) > > Then when the CI, ghpages, blogging / site workflow, and documentation are > properly in order, we deploy our little nipy. > > > I'll start a first round of edits (step 1) this weekend. > > > On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat > wrote: > >> This should be fairly easy to maintain. The main "package" pages are >> jekyll, meaning anyone can push a PR to the repo, preview on circle, and >> then deploy to github pages with approved changes. Developers know how to >> use github. >> >> The hidden blog is hosted at tumblr, which means that: >> >> - anyone can contribute content. We can let it get pushed or put it in a >> queue for approval. >> - posts can be done on mobile, or from email. In html, markdown, or >> standard text editor. >> - we can choose to "hide" the neuroimaging.tumblr.com url if we want, >> but it's really not so bad. >> - looks spiffy on mobile too :) >> - posts can be associated with authors, but don't need to be. >> - people can ask questions on posts, share posts, like them, etc. >> - integrated notifications, social media, apps, all the standard stuff >> you get with a platform like this. Tumblr has an API :) >> >> We kill lots of birds with a snakey thought stone. The site has CI, >> hosted for free on ghpages, and is an easy workflow for developers to >> update or add their packages. The site is also better integrated into the >> non-developer community, because anyone can contribute content easily >> without github, and we still have control over that content. >> >> If there is a huge redesign of the site, then the template would need to >> be updated on tumblr, but that really comes down to copy pasting the base >> code into the template editor. This was the idea that I had this morning. >> >> >> On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat >> wrote: >> >>> *Continuous integration:* >>> >>> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >>> >>> *Gihub pages:* >>> http://vsoch.github.io/nipy-jekyll/ >>> >>> All things seem to be in working order :) >>> >>> >>> >>> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >>> garyfallidis at gmail.com> wrote: >>> >>>> So another push for Jekyll? >>>> >>>> >>>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>>> >>>>> Hey Eleftherios, >>>>> >>>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>>> garyfallidis at gmail.com> wrote: >>>>> >>>>>> Hi Vanessa, >>>>>> >>>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>>> > wrote: >>>>>> >>>>>>> Eleftherios, it's good that you express concern because that means >>>>>>> that you care about nipy, and we can work together to ensure that the >>>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>>> let me implement what I have in mind, and then we can move forward with >>>>>>> discussion on the points of content. >>>>>>> >>>>>>> >>>>>> Sure, be happy to prepare whatever you think will help the >>>>>> discussion. Can I ask you to summarize quickly here the next steps of >>>>>> development that you have in mind? >>>>>> >>>>> >>>>> I think that question has been answered here: >>>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>>> >>>>> >>>>>> Best, >>>>>> Eleftherios >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> Hi Eleftherios, >>>>>>>> >>>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>>> and we want to stay away from making something substantial that requires >>>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>>> for the rest, here are my thoughts: >>>>>>>> >>>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>>> currently vague. >>>>>>>>> >>>>>>>>> A simple portal that gives nipy a brand, links to its products, >>>>>>>> and integrates some platform for us to easily write about it. If something >>>>>>>> more substantial than that is desired, then we first need to resolve where >>>>>>>> it will be hosted and who takes responsibility for its life. >>>>>>>> >>>>>>>> >>>>>>>>> c) How the website and e-mail lists/forums will benefit and >>>>>>>>> promote the work and the vision of this organization. >>>>>>>>> >>>>>>>>> For the work - the website blog will afford all the things that >>>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>>> >>>>>>>> >>>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>>> support a, b, c. >>>>>>>>> >>>>>>>>> Again, this is more about hosting and responsibility. >>>>>>>> >>>>>>>> >>>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>>> website projects which are not currently under our >>>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>>> consensus to take such a decisions. >>>>>>>>> >>>>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>>>> the site functioning. >>>>>>>> >>>>>>>> >>>>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>>>> Neurostars for answering questions about the NIPY >>>>>>>>> projects. This information and whatever we decide must be >>>>>>>>> highlighted clearly in the portal. >>>>>>>>> >>>>>>>>> Lorem,.. ipsum... >>>>>>>> >>>>>>>> :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >>>>>>>>>> exactly :) >>>>>>>>>> >>>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi everyone! >>>>>>>>>>>> >>>>>>>>>>>> I thought more about this on my walk - here is a reasonable >>>>>>>>>>>> game plan! I will do the work to put together a solution that integrates >>>>>>>>>>>> Ariel's original vision with ghpages, the parts of Jekyll that do work, and >>>>>>>>>>>> a more non developer friendly integrated blog. I think this could meet all >>>>>>>>>>>> of our goals and be a solution that better integrates social aspects of our >>>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>> Bada-boum! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>>> tested some things. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> Vanessa >>>>>>>>>>>> >>>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Hi, >>>>>>>>>>>> > >>>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>> >> Hi Group, >>>>>>>>>>>> >> >>>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>>> goals of the site, >>>>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>>>> that is easy to >>>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>>> previewing >>>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial >>>>>>>>>>>> look of the site? >>>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>>> > >>>>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>>>> other >>>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>>> > >>>>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>>>> and >>>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>>> > >>>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>>> the >>>>>>>>>>>> > sphinx documentation locally to preview it, but we can also >>>>>>>>>>>> do what >>>>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>>> travis-ci >>>>>>>>>>>> > matrix of jobs. >>>>>>>>>>>> > >>>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>>> pages, >>>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>>> with a >>>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>>> building / >>>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>>> > >>>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back >>>>>>>>>>>> to >>>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>>> most >>>>>>>>>>>> > Python developers. >>>>>>>>>>>> > >>>>>>>>>>>> > Thanks very much for doing all this work by the way - it's >>>>>>>>>>>> very >>>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>>> > >>>>>>>>>>>> > See you, >>>>>>>>>>>> > >>>>>>>>>>>> > Matthew >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>> Stanford University >>>>>>>>>> (603) 321-0676 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Thu Aug 27 01:43:41 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 19:43:41 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Vanessa, The website is beautiful. Thank you again for your work. I subscribed to tumblr too. Are parts of this that were possible only with Jekyll? And if yes which ones? I am not suggesting to change the technology again. But I would like to know where Jekyll helped at the end. Cheers, Eleftherios On Wed, Aug 26, 2015 at 7:28 PM, vanessa sochat wrote: > My suggestions for moving forward: > > > 1) > > Feedback and desires for the template and look, best as issues on the > repo. Ironically, we've been so focused on getting it working that I don't > consider the style complete, and there were good suggestions that I haven't > even looked at yet! If you have a style or element preference, please > share, and it would be great to provide an example. First we fix those > details. > > 2) > > Then content (specific packages, pages that are not posts, and where we > tell users to ask for help, etc). I'm pretty indifferent about these > things, and will be happy to go with the consensus. I can write > documentation for the "contribute" page for the different flavors of > contributors. > > 3) > > It would be good for others to then give the different kinds of > contribution a try, and get feedback on those workflows. > > 4) > > Then when the CI, ghpages, blogging / site workflow, and documentation are > properly in order, we deploy our little nipy. > > > I'll start a first round of edits (step 1) this weekend. > > > On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat > wrote: > >> This should be fairly easy to maintain. The main "package" pages are >> jekyll, meaning anyone can push a PR to the repo, preview on circle, and >> then deploy to github pages with approved changes. Developers know how to >> use github. >> >> The hidden blog is hosted at tumblr, which means that: >> >> - anyone can contribute content. We can let it get pushed or put it in a >> queue for approval. >> - posts can be done on mobile, or from email. In html, markdown, or >> standard text editor. >> - we can choose to "hide" the neuroimaging.tumblr.com url if we want, >> but it's really not so bad. >> - looks spiffy on mobile too :) >> - posts can be associated with authors, but don't need to be. >> - people can ask questions on posts, share posts, like them, etc. >> - integrated notifications, social media, apps, all the standard stuff >> you get with a platform like this. Tumblr has an API :) >> >> We kill lots of birds with a snakey thought stone. The site has CI, >> hosted for free on ghpages, and is an easy workflow for developers to >> update or add their packages. The site is also better integrated into the >> non-developer community, because anyone can contribute content easily >> without github, and we still have control over that content. >> >> If there is a huge redesign of the site, then the template would need to >> be updated on tumblr, but that really comes down to copy pasting the base >> code into the template editor. This was the idea that I had this morning. >> >> >> On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat >> wrote: >> >>> *Continuous integration:* >>> >>> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >>> >>> *Gihub pages:* >>> http://vsoch.github.io/nipy-jekyll/ >>> >>> All things seem to be in working order :) >>> >>> >>> >>> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >>> garyfallidis at gmail.com> wrote: >>> >>>> So another push for Jekyll? >>>> >>>> >>>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>>> >>>>> Hey Eleftherios, >>>>> >>>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>>> garyfallidis at gmail.com> wrote: >>>>> >>>>>> Hi Vanessa, >>>>>> >>>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>>> > wrote: >>>>>> >>>>>>> Eleftherios, it's good that you express concern because that means >>>>>>> that you care about nipy, and we can work together to ensure that the >>>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>>> let me implement what I have in mind, and then we can move forward with >>>>>>> discussion on the points of content. >>>>>>> >>>>>>> >>>>>> Sure, be happy to prepare whatever you think will help the >>>>>> discussion. Can I ask you to summarize quickly here the next steps of >>>>>> development that you have in mind? >>>>>> >>>>> >>>>> I think that question has been answered here: >>>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>>> >>>>> >>>>>> Best, >>>>>> Eleftherios >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> Hi Eleftherios, >>>>>>>> >>>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>>> and we want to stay away from making something substantial that requires >>>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>>> for the rest, here are my thoughts: >>>>>>>> >>>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>>> currently vague. >>>>>>>>> >>>>>>>>> A simple portal that gives nipy a brand, links to its products, >>>>>>>> and integrates some platform for us to easily write about it. If something >>>>>>>> more substantial than that is desired, then we first need to resolve where >>>>>>>> it will be hosted and who takes responsibility for its life. >>>>>>>> >>>>>>>> >>>>>>>>> c) How the website and e-mail lists/forums will benefit and >>>>>>>>> promote the work and the vision of this organization. >>>>>>>>> >>>>>>>>> For the work - the website blog will afford all the things that >>>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>>> >>>>>>>> >>>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>>> support a, b, c. >>>>>>>>> >>>>>>>>> Again, this is more about hosting and responsibility. >>>>>>>> >>>>>>>> >>>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>>> website projects which are not currently under our >>>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>>> consensus to take such a decisions. >>>>>>>>> >>>>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>>>> the site functioning. >>>>>>>> >>>>>>>> >>>>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>>>> Neurostars for answering questions about the NIPY >>>>>>>>> projects. This information and whatever we decide must be >>>>>>>>> highlighted clearly in the portal. >>>>>>>>> >>>>>>>>> Lorem,.. ipsum... >>>>>>>> >>>>>>>> :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >>>>>>>>>> exactly :) >>>>>>>>>> >>>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi everyone! >>>>>>>>>>>> >>>>>>>>>>>> I thought more about this on my walk - here is a reasonable >>>>>>>>>>>> game plan! I will do the work to put together a solution that integrates >>>>>>>>>>>> Ariel's original vision with ghpages, the parts of Jekyll that do work, and >>>>>>>>>>>> a more non developer friendly integrated blog. I think this could meet all >>>>>>>>>>>> of our goals and be a solution that better integrates social aspects of our >>>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>> Bada-boum! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>>> tested some things. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> Vanessa >>>>>>>>>>>> >>>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Hi, >>>>>>>>>>>> > >>>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>> >> Hi Group, >>>>>>>>>>>> >> >>>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>>> goals of the site, >>>>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>>>> that is easy to >>>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>>> previewing >>>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial >>>>>>>>>>>> look of the site? >>>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>>> > >>>>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>>>> other >>>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>>> > >>>>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>>>> and >>>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>>> > >>>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>>> the >>>>>>>>>>>> > sphinx documentation locally to preview it, but we can also >>>>>>>>>>>> do what >>>>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>>> travis-ci >>>>>>>>>>>> > matrix of jobs. >>>>>>>>>>>> > >>>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>>> pages, >>>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>>> with a >>>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>>> building / >>>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>>> > >>>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back >>>>>>>>>>>> to >>>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>>> most >>>>>>>>>>>> > Python developers. >>>>>>>>>>>> > >>>>>>>>>>>> > Thanks very much for doing all this work by the way - it's >>>>>>>>>>>> very >>>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>>> > >>>>>>>>>>>> > See you, >>>>>>>>>>>> > >>>>>>>>>>>> > Matthew >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>> Stanford University >>>>>>>>>> (603) 321-0676 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Thu Aug 27 01:43:27 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 16:43:27 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Sure thing! I'll do that first then. On Wed, Aug 26, 2015 at 4:42 PM, Ben Cipollini wrote: > I would suggest that, before working on #1-3, work on the documentation > for the workflow, and any weirdness about the templates to work around > bugs. Given the fears about the workflow and the need to work around Jekyll > / CI bugs, I think we should make it clear what the current workflow > entails. > > The docs don't have to be super-pretty, but I think at least a complete > sketch of the workflow would be great to document and discuss while you > start moving forward with the rest. > > Would you be up for doing that, Vanessa? I assume it wouldn't be too > complex--just a few details about how to build on each system (not what's > underneath the hood, just what the user has to do), and any requirements of > template writing that are constrained by that. > > Thanks, > Ben > > On Wed, Aug 26, 2015 at 4:28 PM, vanessa sochat > wrote: > >> My suggestions for moving forward: >> >> >> 1) >> >> Feedback and desires for the template and look, best as issues on the >> repo. Ironically, we've been so focused on getting it working that I don't >> consider the style complete, and there were good suggestions that I haven't >> even looked at yet! If you have a style or element preference, please >> share, and it would be great to provide an example. First we fix those >> details. >> >> 2) >> >> Then content (specific packages, pages that are not posts, and where we >> tell users to ask for help, etc). I'm pretty indifferent about these >> things, and will be happy to go with the consensus. I can write >> documentation for the "contribute" page for the different flavors of >> contributors. >> >> 3) >> >> It would be good for others to then give the different kinds of >> contribution a try, and get feedback on those workflows. >> >> 4) >> >> Then when the CI, ghpages, blogging / site workflow, and documentation >> are properly in order, we deploy our little nipy. >> >> >> I'll start a first round of edits (step 1) this weekend. >> >> >> On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat >> wrote: >> >>> This should be fairly easy to maintain. The main "package" pages are >>> jekyll, meaning anyone can push a PR to the repo, preview on circle, and >>> then deploy to github pages with approved changes. Developers know how to >>> use github. >>> >>> The hidden blog is hosted at tumblr, which means that: >>> >>> - anyone can contribute content. We can let it get pushed or put it in a >>> queue for approval. >>> - posts can be done on mobile, or from email. In html, markdown, or >>> standard text editor. >>> - we can choose to "hide" the neuroimaging.tumblr.com url if we want, >>> but it's really not so bad. >>> - looks spiffy on mobile too :) >>> - posts can be associated with authors, but don't need to be. >>> - people can ask questions on posts, share posts, like them, etc. >>> - integrated notifications, social media, apps, all the standard stuff >>> you get with a platform like this. Tumblr has an API :) >>> >>> We kill lots of birds with a snakey thought stone. The site has CI, >>> hosted for free on ghpages, and is an easy workflow for developers to >>> update or add their packages. The site is also better integrated into the >>> non-developer community, because anyone can contribute content easily >>> without github, and we still have control over that content. >>> >>> If there is a huge redesign of the site, then the template would need to >>> be updated on tumblr, but that really comes down to copy pasting the base >>> code into the template editor. This was the idea that I had this morning. >>> >>> >>> On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat >>> wrote: >>> >>>> *Continuous integration:* >>>> >>>> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >>>> >>>> *Gihub pages:* >>>> http://vsoch.github.io/nipy-jekyll/ >>>> >>>> All things seem to be in working order :) >>>> >>>> >>>> >>>> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >>>> garyfallidis at gmail.com> wrote: >>>> >>>>> So another push for Jekyll? >>>>> >>>>> >>>>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>>>> >>>>>> Hey Eleftherios, >>>>>> >>>>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>>>> garyfallidis at gmail.com> wrote: >>>>>> >>>>>>> Hi Vanessa, >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> Eleftherios, it's good that you express concern because that means >>>>>>>> that you care about nipy, and we can work together to ensure that the >>>>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>>>> let me implement what I have in mind, and then we can move forward with >>>>>>>> discussion on the points of content. >>>>>>>> >>>>>>>> >>>>>>> Sure, be happy to prepare whatever you think will help the >>>>>>> discussion. Can I ask you to summarize quickly here the next steps of >>>>>>> development that you have in mind? >>>>>>> >>>>>> >>>>>> I think that question has been answered here: >>>>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>>>> >>>>>> >>>>>>> Best, >>>>>>> Eleftherios >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> Hi Eleftherios, >>>>>>>>> >>>>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>>>> and we want to stay away from making something substantial that requires >>>>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>>>> for the rest, here are my thoughts: >>>>>>>>> >>>>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>>>> currently vague. >>>>>>>>>> >>>>>>>>>> A simple portal that gives nipy a brand, links to its products, >>>>>>>>> and integrates some platform for us to easily write about it. If something >>>>>>>>> more substantial than that is desired, then we first need to resolve where >>>>>>>>> it will be hosted and who takes responsibility for its life. >>>>>>>>> >>>>>>>>> >>>>>>>>>> c) How the website and e-mail lists/forums will benefit and >>>>>>>>>> promote the work and the vision of this organization. >>>>>>>>>> >>>>>>>>>> For the work - the website blog will afford all the things that >>>>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>>>> >>>>>>>>> >>>>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>>>> support a, b, c. >>>>>>>>>> >>>>>>>>>> Again, this is more about hosting and responsibility. >>>>>>>>> >>>>>>>>> >>>>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>>>> website projects which are not currently under our >>>>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>>>> consensus to take such a decisions. >>>>>>>>>> >>>>>>>>>> You should consider all current content on the site as Lorem >>>>>>>>> Ipsum etc. I simply reproduced what is on the current site and did not make >>>>>>>>> any "decisions." As I said earlier, content and template come >>>>>>>>> *after* getting the site functioning. >>>>>>>>> >>>>>>>>> >>>>>>>>>> (c) is also much related to Matthew's e-mail for supporting or >>>>>>>>>> not Neurostars for answering questions about the NIPY >>>>>>>>>> projects. This information and whatever we decide must be >>>>>>>>>> highlighted clearly in the portal. >>>>>>>>>> >>>>>>>>>> Lorem,.. ipsum... >>>>>>>>> >>>>>>>>> :) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >>>>>>>>>>> exactly :) >>>>>>>>>>> >>>>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi everyone! >>>>>>>>>>>>> >>>>>>>>>>>>> I thought more about this on my walk - here is a reasonable >>>>>>>>>>>>> game plan! I will do the work to put together a solution that integrates >>>>>>>>>>>>> Ariel's original vision with ghpages, the parts of Jekyll that do work, and >>>>>>>>>>>>> a more non developer friendly integrated blog. I think this could meet all >>>>>>>>>>>>> of our goals and be a solution that better integrates social aspects of our >>>>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>>> Bada-boum! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>>>> tested some things. >>>>>>>>>>>>> >>>>>>>>>>>>> Best, >>>>>>>>>>>>> >>>>>>>>>>>>> Vanessa >>>>>>>>>>>>> >>>>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Hi, >>>>>>>>>>>>> > >>>>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>>> >> Hi Group, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>>>> goals of the site, >>>>>>>>>>>>> >> and want to bring everyone in. In summary, we want >>>>>>>>>>>>> something that is easy to >>>>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>>>> previewing >>>>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial >>>>>>>>>>>>> look of the site? >>>>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>>>> > >>>>>>>>>>>>> > Actually, I think that sphinx is a very good option, and >>>>>>>>>>>>> most other >>>>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>>>> > >>>>>>>>>>>>> > The particular template that we were using was a little >>>>>>>>>>>>> dated and >>>>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>>>> the >>>>>>>>>>>>> > sphinx documentation locally to preview it, but we can also >>>>>>>>>>>>> do what >>>>>>>>>>>>> > other projects are doing, and build / publish the docs in >>>>>>>>>>>>> some >>>>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>>>> travis-ci >>>>>>>>>>>>> > matrix of jobs. >>>>>>>>>>>>> > >>>>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>>>> pages, >>>>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>>>> with a >>>>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>>>> building / >>>>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>>>> > >>>>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go >>>>>>>>>>>>> back to >>>>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>>>> most >>>>>>>>>>>>> > Python developers. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thanks very much for doing all this work by the way - it's >>>>>>>>>>>>> very >>>>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>>>> > >>>>>>>>>>>>> > See you, >>>>>>>>>>>>> > >>>>>>>>>>>>> > Matthew >>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>>> Stanford University >>>>>>>>>>> (603) 321-0676 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Vanessa Villamia Sochat >>>>>>>>> Stanford University >>>>>>>>> (603) 321-0676 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Thu Aug 27 01:50:21 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Wed, 26 Aug 2015 16:50:21 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Jekyll is serving as a template engine to render the pages and links, and the menu and d3 are dynamically generated from the data file . I'm sure it would be possible to achieve that kind of functionality with any other engine, given the data and templating is transformed into said engine (as I did to go from the original flask --> jekyll). On Wed, Aug 26, 2015 at 4:43 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hi Vanessa, > > The website is beautiful. Thank you again for your work. I subscribed to > tumblr too. > > Are parts of this that were possible only with Jekyll? And if yes which > ones? > > I am not suggesting to change the technology again. But I would like to > know where Jekyll helped at the end. > > Cheers, > Eleftherios > > > > > > > On Wed, Aug 26, 2015 at 7:28 PM, vanessa sochat > wrote: > >> My suggestions for moving forward: >> >> >> 1) >> >> Feedback and desires for the template and look, best as issues on the >> repo. Ironically, we've been so focused on getting it working that I don't >> consider the style complete, and there were good suggestions that I haven't >> even looked at yet! If you have a style or element preference, please >> share, and it would be great to provide an example. First we fix those >> details. >> >> 2) >> >> Then content (specific packages, pages that are not posts, and where we >> tell users to ask for help, etc). I'm pretty indifferent about these >> things, and will be happy to go with the consensus. I can write >> documentation for the "contribute" page for the different flavors of >> contributors. >> >> 3) >> >> It would be good for others to then give the different kinds of >> contribution a try, and get feedback on those workflows. >> >> 4) >> >> Then when the CI, ghpages, blogging / site workflow, and documentation >> are properly in order, we deploy our little nipy. >> >> >> I'll start a first round of edits (step 1) this weekend. >> >> >> On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat >> wrote: >> >>> This should be fairly easy to maintain. The main "package" pages are >>> jekyll, meaning anyone can push a PR to the repo, preview on circle, and >>> then deploy to github pages with approved changes. Developers know how to >>> use github. >>> >>> The hidden blog is hosted at tumblr, which means that: >>> >>> - anyone can contribute content. We can let it get pushed or put it in a >>> queue for approval. >>> - posts can be done on mobile, or from email. In html, markdown, or >>> standard text editor. >>> - we can choose to "hide" the neuroimaging.tumblr.com url if we want, >>> but it's really not so bad. >>> - looks spiffy on mobile too :) >>> - posts can be associated with authors, but don't need to be. >>> - people can ask questions on posts, share posts, like them, etc. >>> - integrated notifications, social media, apps, all the standard stuff >>> you get with a platform like this. Tumblr has an API :) >>> >>> We kill lots of birds with a snakey thought stone. The site has CI, >>> hosted for free on ghpages, and is an easy workflow for developers to >>> update or add their packages. The site is also better integrated into the >>> non-developer community, because anyone can contribute content easily >>> without github, and we still have control over that content. >>> >>> If there is a huge redesign of the site, then the template would need to >>> be updated on tumblr, but that really comes down to copy pasting the base >>> code into the template editor. This was the idea that I had this morning. >>> >>> >>> On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat >>> wrote: >>> >>>> *Continuous integration:* >>>> >>>> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >>>> >>>> *Gihub pages:* >>>> http://vsoch.github.io/nipy-jekyll/ >>>> >>>> All things seem to be in working order :) >>>> >>>> >>>> >>>> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >>>> garyfallidis at gmail.com> wrote: >>>> >>>>> So another push for Jekyll? >>>>> >>>>> >>>>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>>>> >>>>>> Hey Eleftherios, >>>>>> >>>>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>>>> garyfallidis at gmail.com> wrote: >>>>>> >>>>>>> Hi Vanessa, >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> Eleftherios, it's good that you express concern because that means >>>>>>>> that you care about nipy, and we can work together to ensure that the >>>>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>>>> let me implement what I have in mind, and then we can move forward with >>>>>>>> discussion on the points of content. >>>>>>>> >>>>>>>> >>>>>>> Sure, be happy to prepare whatever you think will help the >>>>>>> discussion. Can I ask you to summarize quickly here the next steps of >>>>>>> development that you have in mind? >>>>>>> >>>>>> >>>>>> I think that question has been answered here: >>>>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>>>> >>>>>> >>>>>>> Best, >>>>>>> Eleftherios >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> Hi Eleftherios, >>>>>>>>> >>>>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>>>> and we want to stay away from making something substantial that requires >>>>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>>>> for the rest, here are my thoughts: >>>>>>>>> >>>>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>>>> currently vague. >>>>>>>>>> >>>>>>>>>> A simple portal that gives nipy a brand, links to its products, >>>>>>>>> and integrates some platform for us to easily write about it. If something >>>>>>>>> more substantial than that is desired, then we first need to resolve where >>>>>>>>> it will be hosted and who takes responsibility for its life. >>>>>>>>> >>>>>>>>> >>>>>>>>>> c) How the website and e-mail lists/forums will benefit and >>>>>>>>>> promote the work and the vision of this organization. >>>>>>>>>> >>>>>>>>>> For the work - the website blog will afford all the things that >>>>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>>>> >>>>>>>>> >>>>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>>>> support a, b, c. >>>>>>>>>> >>>>>>>>>> Again, this is more about hosting and responsibility. >>>>>>>>> >>>>>>>>> >>>>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>>>> website projects which are not currently under our >>>>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>>>> consensus to take such a decisions. >>>>>>>>>> >>>>>>>>>> You should consider all current content on the site as Lorem >>>>>>>>> Ipsum etc. I simply reproduced what is on the current site and did not make >>>>>>>>> any "decisions." As I said earlier, content and template come >>>>>>>>> *after* getting the site functioning. >>>>>>>>> >>>>>>>>> >>>>>>>>>> (c) is also much related to Matthew's e-mail for supporting or >>>>>>>>>> not Neurostars for answering questions about the NIPY >>>>>>>>>> projects. This information and whatever we decide must be >>>>>>>>>> highlighted clearly in the portal. >>>>>>>>>> >>>>>>>>>> Lorem,.. ipsum... >>>>>>>>> >>>>>>>>> :) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >>>>>>>>>>> exactly :) >>>>>>>>>>> >>>>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi everyone! >>>>>>>>>>>>> >>>>>>>>>>>>> I thought more about this on my walk - here is a reasonable >>>>>>>>>>>>> game plan! I will do the work to put together a solution that integrates >>>>>>>>>>>>> Ariel's original vision with ghpages, the parts of Jekyll that do work, and >>>>>>>>>>>>> a more non developer friendly integrated blog. I think this could meet all >>>>>>>>>>>>> of our goals and be a solution that better integrates social aspects of our >>>>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>>> Bada-boum! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>>>> tested some things. >>>>>>>>>>>>> >>>>>>>>>>>>> Best, >>>>>>>>>>>>> >>>>>>>>>>>>> Vanessa >>>>>>>>>>>>> >>>>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Hi, >>>>>>>>>>>>> > >>>>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>>> >> Hi Group, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>>>> goals of the site, >>>>>>>>>>>>> >> and want to bring everyone in. In summary, we want >>>>>>>>>>>>> something that is easy to >>>>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>>>> previewing >>>>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial >>>>>>>>>>>>> look of the site? >>>>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>>>> > >>>>>>>>>>>>> > Actually, I think that sphinx is a very good option, and >>>>>>>>>>>>> most other >>>>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>>>> > >>>>>>>>>>>>> > The particular template that we were using was a little >>>>>>>>>>>>> dated and >>>>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>>>> the >>>>>>>>>>>>> > sphinx documentation locally to preview it, but we can also >>>>>>>>>>>>> do what >>>>>>>>>>>>> > other projects are doing, and build / publish the docs in >>>>>>>>>>>>> some >>>>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>>>> travis-ci >>>>>>>>>>>>> > matrix of jobs. >>>>>>>>>>>>> > >>>>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>>>> pages, >>>>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>>>> with a >>>>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>>>> building / >>>>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>>>> > >>>>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go >>>>>>>>>>>>> back to >>>>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>>>> most >>>>>>>>>>>>> > Python developers. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thanks very much for doing all this work by the way - it's >>>>>>>>>>>>> very >>>>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>>>> > >>>>>>>>>>>>> > See you, >>>>>>>>>>>>> > >>>>>>>>>>>>> > Matthew >>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>>> Stanford University >>>>>>>>>>> (603) 321-0676 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Vanessa Villamia Sochat >>>>>>>>> Stanford University >>>>>>>>> (603) 321-0676 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyfallidis at gmail.com Thu Aug 27 01:59:01 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Wed, 26 Aug 2015 19:59:01 -0400 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Okay. This is what I thought. So jekyll is not really necessary here. You can clearly use flask which you have played with previously. Or I can help with pelican to do the same. If you want to try that. Some food for thought here. Cool! On Wed, Aug 26, 2015 at 7:50 PM, vanessa sochat wrote: > Jekyll is serving as a template engine to render the pages and links, and > the menu and d3 are dynamically generated from the data file > . > I'm sure it would be possible to achieve that kind of functionality with > any other engine, given the data and templating is transformed into said > engine (as I did to go from the original flask > --> jekyll). > > On Wed, Aug 26, 2015 at 4:43 PM, Eleftherios Garyfallidis < > garyfallidis at gmail.com> wrote: > >> Hi Vanessa, >> >> The website is beautiful. Thank you again for your work. I subscribed to >> tumblr too. >> >> Are parts of this that were possible only with Jekyll? And if yes which >> ones? >> >> I am not suggesting to change the technology again. But I would like to >> know where Jekyll helped at the end. >> >> Cheers, >> Eleftherios >> >> >> >> >> >> >> On Wed, Aug 26, 2015 at 7:28 PM, vanessa sochat >> wrote: >> >>> My suggestions for moving forward: >>> >>> >>> 1) >>> >>> Feedback and desires for the template and look, best as issues on the >>> repo. Ironically, we've been so focused on getting it working that I don't >>> consider the style complete, and there were good suggestions that I haven't >>> even looked at yet! If you have a style or element preference, please >>> share, and it would be great to provide an example. First we fix those >>> details. >>> >>> 2) >>> >>> Then content (specific packages, pages that are not posts, and where we >>> tell users to ask for help, etc). I'm pretty indifferent about these >>> things, and will be happy to go with the consensus. I can write >>> documentation for the "contribute" page for the different flavors of >>> contributors. >>> >>> 3) >>> >>> It would be good for others to then give the different kinds of >>> contribution a try, and get feedback on those workflows. >>> >>> 4) >>> >>> Then when the CI, ghpages, blogging / site workflow, and documentation >>> are properly in order, we deploy our little nipy. >>> >>> >>> I'll start a first round of edits (step 1) this weekend. >>> >>> >>> On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat >>> wrote: >>> >>>> This should be fairly easy to maintain. The main "package" pages are >>>> jekyll, meaning anyone can push a PR to the repo, preview on circle, and >>>> then deploy to github pages with approved changes. Developers know how to >>>> use github. >>>> >>>> The hidden blog is hosted at tumblr, which means that: >>>> >>>> - anyone can contribute content. We can let it get pushed or put it in >>>> a queue for approval. >>>> - posts can be done on mobile, or from email. In html, markdown, or >>>> standard text editor. >>>> - we can choose to "hide" the neuroimaging.tumblr.com url if we want, >>>> but it's really not so bad. >>>> - looks spiffy on mobile too :) >>>> - posts can be associated with authors, but don't need to be. >>>> - people can ask questions on posts, share posts, like them, etc. >>>> - integrated notifications, social media, apps, all the standard stuff >>>> you get with a platform like this. Tumblr has an API :) >>>> >>>> We kill lots of birds with a snakey thought stone. The site has CI, >>>> hosted for free on ghpages, and is an easy workflow for developers to >>>> update or add their packages. The site is also better integrated into the >>>> non-developer community, because anyone can contribute content easily >>>> without github, and we still have control over that content. >>>> >>>> If there is a huge redesign of the site, then the template would need >>>> to be updated on tumblr, but that really comes down to copy pasting the >>>> base code into the template editor. This was the idea that I had this >>>> morning. >>>> >>>> >>>> On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat >>>> wrote: >>>> >>>>> *Continuous integration:* >>>>> >>>>> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >>>>> >>>>> *Gihub pages:* >>>>> http://vsoch.github.io/nipy-jekyll/ >>>>> >>>>> All things seem to be in working order :) >>>>> >>>>> >>>>> >>>>> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >>>>> garyfallidis at gmail.com> wrote: >>>>> >>>>>> So another push for Jekyll? >>>>>> >>>>>> >>>>>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem >>>>>> wrote: >>>>>> >>>>>>> Hey Eleftherios, >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>>>>> garyfallidis at gmail.com> wrote: >>>>>>> >>>>>>>> Hi Vanessa, >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> Eleftherios, it's good that you express concern because that means >>>>>>>>> that you care about nipy, and we can work together to ensure that the >>>>>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>>>>> let me implement what I have in mind, and then we can move forward with >>>>>>>>> discussion on the points of content. >>>>>>>>> >>>>>>>>> >>>>>>>> Sure, be happy to prepare whatever you think will help the >>>>>>>> discussion. Can I ask you to summarize quickly here the next steps of >>>>>>>> development that you have in mind? >>>>>>>> >>>>>>> >>>>>>> I think that question has been answered here: >>>>>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>>>>> >>>>>>> >>>>>>>> Best, >>>>>>>> Eleftherios >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >>>>>>>>>> Hi Eleftherios, >>>>>>>>>> >>>>>>>>>> A framework like Django is too heavy for a simple portal and >>>>>>>>>> blog, and we want to stay away from making something substantial that >>>>>>>>>> requires regular maintenance and care, and an actual server. We can achieve >>>>>>>>>> all the functionality of comments / social media, etc by integrating a >>>>>>>>>> blogging platform into a site that works on Github pages. Question b (sites >>>>>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>>>>> for the rest, here are my thoughts: >>>>>>>>>> >>>>>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>>>>> currently vague. >>>>>>>>>>> >>>>>>>>>>> A simple portal that gives nipy a brand, links to its products, >>>>>>>>>> and integrates some platform for us to easily write about it. If something >>>>>>>>>> more substantial than that is desired, then we first need to resolve where >>>>>>>>>> it will be hosted and who takes responsibility for its life. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> c) How the website and e-mail lists/forums will benefit and >>>>>>>>>>> promote the work and the vision of this organization. >>>>>>>>>>> >>>>>>>>>>> For the work - the website blog will afford all the things that >>>>>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>>>>> support a, b, c. >>>>>>>>>>> >>>>>>>>>>> Again, this is more about hosting and responsibility. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>>>>> website projects which are not currently under our >>>>>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>>>>> consensus to take such a decisions. >>>>>>>>>>> >>>>>>>>>>> You should consider all current content on the site as Lorem >>>>>>>>>> Ipsum etc. I simply reproduced what is on the current site and did not make >>>>>>>>>> any "decisions." As I said earlier, content and template come >>>>>>>>>> *after* getting the site functioning. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> (c) is also much related to Matthew's e-mail for supporting or >>>>>>>>>>> not Neurostars for answering questions about the NIPY >>>>>>>>>>> projects. This information and whatever we decide must be >>>>>>>>>>> highlighted clearly in the portal. >>>>>>>>>>> >>>>>>>>>>> Lorem,.. ipsum... >>>>>>>>>> >>>>>>>>>> :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>> >>>>>>>>>>>> exactly :) >>>>>>>>>>>> >>>>>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi everyone! >>>>>>>>>>>>>> >>>>>>>>>>>>>> I thought more about this on my walk - here is a reasonable >>>>>>>>>>>>>> game plan! I will do the work to put together a solution that integrates >>>>>>>>>>>>>> Ariel's original vision with ghpages, the parts of Jekyll that do work, and >>>>>>>>>>>>>> a more non developer friendly integrated blog. I think this could meet all >>>>>>>>>>>>>> of our goals and be a solution that better integrates social aspects of our >>>>>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> +1 >>>>>>>>>>>>> >>>>>>>>>>>>> Bada-boum! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I will send out an update likely during weekend time when >>>>>>>>>>>>>> I've tested some things. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Vanessa >>>>>>>>>>>>>> >>>>>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Hi, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>>>> >> Hi Group, >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>>>>> goals of the site, >>>>>>>>>>>>>> >> and want to bring everyone in. In summary, we want >>>>>>>>>>>>>> something that is easy to >>>>>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>>>>> previewing >>>>>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial >>>>>>>>>>>>>> look of the site? >>>>>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Actually, I think that sphinx is a very good option, and >>>>>>>>>>>>>> most other >>>>>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > The particular template that we were using was a little >>>>>>>>>>>>>> dated and >>>>>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Most if not all developers are perfectly capable of >>>>>>>>>>>>>> building the >>>>>>>>>>>>>> > sphinx documentation locally to preview it, but we can also >>>>>>>>>>>>>> do what >>>>>>>>>>>>>> > other projects are doing, and build / publish the docs in >>>>>>>>>>>>>> some >>>>>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>>>>> travis-ci >>>>>>>>>>>>>> > matrix of jobs. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>>>>> pages, >>>>>>>>>>>>>> > because it is very easy to get a rendered version to look >>>>>>>>>>>>>> at with a >>>>>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>>>>> building / >>>>>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go >>>>>>>>>>>>>> back to >>>>>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>>>>> most >>>>>>>>>>>>>> > Python developers. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Thanks very much for doing all this work by the way - it's >>>>>>>>>>>>>> very >>>>>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > See you, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Matthew >>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>>>> Stanford University >>>>>>>>>>>> (603) 321-0676 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>> Stanford University >>>>>>>>>> (603) 321-0676 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Vanessa Villamia Sochat >>>>>>>>> Stanford University >>>>>>>>> (603) 321-0676 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Vanessa Villamia Sochat >>>>> Stanford University >>>>> (603) 321-0676 >>>>> >>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Thu Aug 27 02:04:03 2015 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Wed, 26 Aug 2015 17:04:03 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: Message-ID: <87vbc1lhqk.fsf@berkeley.edu> Hi Vanessa, On 2015-08-26 08:21:39, vanessa sochat wrote: > That would mean the continuous integration would function fine > for the main site pages (likely updates would be few), the > hosting could be on github pages, and a more common activity > like pulling out your smartphone and writing a quick blog post > from a conference would be easy, better integrated with social > media, etc. A person who is in the community and not familiar > with github would be much better empowered to contribute! Perhaps we can all agree on a set of basic requirements for the website, and then use any platform that satisfies them. E.g.: - Data (like project list) is stored in a parsable, plain text format (markdown or yaml) - A blog post can be added via pull-request and is stored in a plain text format (markdown, rst) - The website should automatically update upon merge of a PR - The toolchain runs on Python (The above are simply the list I would have written--not meant to be prescriptive.) St?fan From satra at mit.edu Thu Aug 27 03:32:32 2015 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 26 Aug 2015 21:32:32 -0400 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: hi eleftherios, i will address the neurostars settings issue. we can definitely change the settings such that 'trusted' is turned off (i didn't realize that was being used), and we can also consider not displaying any points (that was not the intent of the site). it may take a few iterations to ensure no one else has any objections. biostars is also part of a community effort, so please put this in the issues there as well. cheers, satra On Wed, Aug 26, 2015 at 6:17 PM, Eleftherios Garyfallidis < garyfallidis at gmail.com> wrote: > Hi all, > > My initial personal point of view was to use one mailing list both for > users and developers. That is neuroimaging at python.org (previously > nipy-devel...) > Then I saw that this list was not attracting enough questions. This is > probably because we didn't promote this list enough. And maybe that > should have been the first thing to do. Which we clearly didn't do. > > Then I thought okay the neuroimaging at python.org list is for developers > and expert users and neurostars.org > is for users who don't want to touch development and need feedback. > > > But I have to say that there are some features in neurostars which can be > dangerous. One of them is that people who answer questions get > different status and reputation points. For example, the status of the > person answering often says "trusted". This is misleading information. > > I think we need to be smarter here. There are no experts. We are research > projects. We want a community which does not promote > expertise but promotes understanding and good scientific practice. The > focus of neurostars should be exactly that. > > I see that neurostars is still in a beta and I am wondering if we can > change some of its settings. > > It is true that neurostars has attracted very quickly a relatively large > audience. So, I am not sure if we should stop using it or not. But I will > suggest something different. > > Can we continue using Neurostars with some different setup so that it > promotes more understanding/discussion rather than expertise? > > To be more clear. Here is a summary of the important problems that > StackOverflow has which also Neurostars can potentially have: > > This is from > http://michael.richter.name/blogs/awhy-i-no-longer-contribute-to-stackoverflow > which was posted previously in this thread. Thanx for > posting this. > > The problems with StackOverflow are summarized in this list: > > 1. Poor pedagogy > 2. Poor reward system > 3. Poor community > > If we can change/block some of the functionality of neurostars maybe we > can avoid those issues and build a strong community. > If not then maybe we should consider using the current mailing list. > > I would like also to remind that we made nipy.org to reach a much higher > level of community participation. So, please don't take > this lightly. If we can improve neurostars to reach that goal we shall do > it. If that is not possible with this technology then maybe > just continue using what we currently have. I mean the list. > > So who are the stars in Neurostars? If the stars are the experts (us). Not > very interesting. If the stars is everyone who helps in improving > understanding and learning without looking for credits and points then > this is much more interesting. Is there a way to promote this > direction more? > > Also about something else. Because neurostars has become quite popular I > think it will be difficult to do what Matthew says. Forward traffic in the > mailing list. > I am afraid we are past that point. Or we will have to do that in > coordination for a long time. So, maybe improve what we have is the way to > go. > > Sorry for the long e-mail. Let me know what you think. I hope this was > helpful in some way. > > Best regards, > Eleftherios > > > > > > On Tue, Aug 25, 2015 at 2:05 PM, Michael Hanke > wrote: > >> Hey, >> >> On Tue, Aug 25, 2015 at 7:53 PM, Matthew Brett >> wrote: >> >>> For the communities - it's surely reasonable to refer questions to the >>> >> chosen forum of the project - for example, I think I'm right in saying >>> there's no controversy that nipype wants user questions to neurostars. >>> I guess it's more complex to direct people who have more general >>> neuroimaging questions. >> >> >> Not just that. For nipype, imagine a user sees that the package install >> fails. _I_ don't want >> them to go to neurostars -- even if nipype wants that. I want that bug, >> because it is fairly clear that _I_ should deal with >> it. I can do that better and quicker, if there is a single forum (or even >> better a bug tracker) for all these bugs >> -- regardless of the actual software in question. For everything else, I >> prefer a pass-through of some >> kind that neither burdens me, nor the user. >> >> Michael >> >> -- >> Michael Hanke >> http://mih.voxindeserto.de >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at gmail.com Wed Aug 26 18:14:43 2015 From: vsochat at gmail.com (Vanessa) Date: Wed, 26 Aug 2015 09:14:43 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: Message-ID: <7AB6DF89-F8EE-42F9-B7E0-8845FC4E8B6D@gmail.com> Hi everyone! I thought more about this on my walk - here is a reasonable game plan! I will do the work to put together a solution that integrates Ariel's original vision with ghpages, the parts of Jekyll that do work, and a more non developer friendly integrated blog. I think this could meet all of our goals and be a solution that better integrates social aspects of our community - github just doesn't specialize in blogging but many services do. If that does not work, then we can go to spinx. Boum! I will send out an update likely during weekend time when I've tested some things. Best, Vanessa > On Aug 26, 2015, at 8:32 AM, Matthew Brett wrote: > > Hi, > >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat wrote: >> Hi Group, >> >> Ben and I are having some discussion on the higher level goals of the site, >> and want to bring everyone in. In summary, we want something that is easy to >> contribute content to, and has continuous integration for previewing >> updates. I am wondering, what was wrong with the initial look of the site? >> Was it that sphinx is hard to update? > > Actually, I think that sphinx is a very good option, and most other > scientific Python sites use sphinx for their main pages. > > The particular template that we were using was a little dated and > ugly, but I bet that could be improved. > > Most if not all developers are perfectly capable of building the > sphinx documentation locally to preview it, but we can also do what > other projects are doing, and build / publish the docs in some > temporary place for each commit, using an entry in the travis-ci > matrix of jobs. > > I think Ariel was particularly attracted to Jekyll / github pages, > because it is very easy to get a rendered version to look at with a > git push, and although that is generally desirable, I think building / > reviewing locally is at least as important. > > So - if it were entirely up to me - I would prefer we go back to > sphinx, on the basis that it is a very familiar workflow to most > Python developers. > > Thanks very much for doing all this work by the way - it's very > helpful, and I'm sorry that we are going round and round. > > See you, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From matthew.brett at gmail.com Thu Aug 27 10:16:33 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 27 Aug 2015 09:16:33 +0100 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, On Wed, Aug 26, 2015 at 11:17 PM, Eleftherios Garyfallidis wrote: > Hi all, > > My initial personal point of view was to use one mailing list both for users > and developers. That is neuroimaging at python.org (previously nipy-devel...) > Then I saw that this list was not attracting enough questions. This is > probably because we didn't promote this list enough. And maybe that > should have been the first thing to do. Which we clearly didn't do. Of course, there will always be a spectrum of users, from "just tell me how to use it without it giving me an error message" to "I want to write new stuff for the package". We were discussing this on the phone yesterday, but for me the question is - what do we hold as the model for users in general? Do we hold that all users should expect to contribute to the discussion of how to build and maintain the package, or do we think that some users can be safely left to - just use the package. As you know - I think we're running into severe trouble in neuroimaging, as the software becomes easier to use, and there are more methods available, without any matching increase in training. So we have more and more people using software that they do not understand. Inevitably, this means more bad science. The only way to avoid that, it to change the culture. We want to switch from the classic model of "we are experts, trust us, use the software" to "we are all learning how to do this. We are learning by building. Come join in this difficult task". This is why I feel so strongly that we should not separate user and developer questions. > Then I thought okay the neuroimaging at python.org list is for developers and > expert users and neurostars.org > is for users who don't want to touch development and need feedback. Hence - I want to say to these type of users - "this is not a model we support. Science is the disbelief in the opinion of experts. We won't stop you doing this, but neither will we imply this is a way of working that we encourage or expect." > But I have to say that there are some features in neurostars which can be > dangerous. One of them is that people who answer questions get > different status and reputation points. For example, the status of the > person answering often says "trusted". This is misleading information. > > I think we need to be smarter here. There are no experts. We are research > projects. We want a community which does not promote > expertise but promotes understanding and good scientific practice. The focus > of neurostars should be exactly that. > > I see that neurostars is still in a beta and I am wondering if we can change > some of its settings. > > It is true that neurostars has attracted very quickly a relatively large > audience. So, I am not sure if we should stop using it or not. But I will > suggest something different. > > Can we continue using Neurostars with some different setup so that it > promotes more understanding/discussion rather than expertise? > > To be more clear. Here is a summary of the important problems that > StackOverflow has which also Neurostars can potentially have: > > This is from > http://michael.richter.name/blogs/awhy-i-no-longer-contribute-to-stackoverflow > which was posted previously in this thread. Thanx for > posting this. > > The problems with StackOverflow are summarized in this list: > > Poor pedagogy > Poor reward system > Poor community I'm afraid I believe these features are structural to the stackoverflow "approved answer" model. What we need is a model that encourages discussion, and the expectation that the beginner should expect to become a peer. This is what mailing lists are very good at, and approved answer models are very bad at. See you, Matthew From matthew.brett at gmail.com Thu Aug 27 12:09:11 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 27 Aug 2015 11:09:11 +0100 Subject: [Neuroimaging] Cannot edit some NIfTI header fields In-Reply-To: <1440527183.21438.21.camel@mail.ru> References: <1440527183.21438.21.camel@mail.ru> Message-ID: Hi, Thanks for re-posting, that's kind of you. On Tue, Aug 25, 2015 at 7:26 PM, Horea Christian wrote: > Hi, I am experiencing some issues with editing my NIfTI headers. > > Apparently I can save some tags after I edit them, but not others. > > I have pasted all my outputs here: https://neurostars.org/p/3362/ > > Can you help me out? > > I have received the following suggestion: > >>Just guessing, but I wonder if you are trying to edit the fields >>supporting the affines, and then saving the image? > >>If you are doing this, then the image save takes the image affine and >>applies it to the header, overwriting any changes you made the qform >>fields, including pixdim. > >>If you want to change the qform / sform affine in the image header, >>use the ``img.set_qform`` and `img.set_sform`` methods. > > > I have looked into these functions, and I cannot figure out how I could > use them to effect the changes I waqnt in the header. The most > important thing right now would be to be able to edit pixdim[3]. For > some reason this is set to the slice spacing (which is 0.5mm) but I > want it set to (and I believe it *should* be set to) the slice > thickness, which is 0.3mm. I don't think that pixdim[3] is meant to be slice thickness - but did you have some reference to say that is should be? I ask because the pixdims are often used to construct the image affine, and this definitely does refer to the slice spacing rather than the slice thickness. In particular, the pixdims are used to construct the 'qform' affine, and therefore also get set when setting the qform affine. In fact, you're running into trouble here because the image object takes some care to set the qform and sform affine into the header, on save, unless you tell it not to somehow. In this case, your simplest option is to: * tell the image that the qform is not defined, and therefore should not be set when saving the image; * set the pixdims as you like. Something like: img.set_qform(None) img.header['pixdim'][3] = 0.3 nib.save(img, 'my_image.nii') Does that work? Cheers, Matthew From krzysztof.gorgolewski at gmail.com Thu Aug 27 12:43:55 2015 From: krzysztof.gorgolewski at gmail.com (Chris Filo Gorgolewski) Date: Thu, 27 Aug 2015 20:43:55 +1000 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, My 3 cents: Matthew, Bertrand - I would encourage you to give neurostars a try. It really helps building the community and makes questions more discoverable. There are some rough edges, but nothing we cannot work around. Just remind yourselves how often do you find solutions to technical issue on stackoverflow or similar services and then imagine that such knowledge would've been hidden on some mailing lists with poor google indexing. Best, Chris On Thu, Aug 27, 2015 at 6:16 PM, Matthew Brett wrote: > Hi, > > On Wed, Aug 26, 2015 at 11:17 PM, Eleftherios Garyfallidis > wrote: > > Hi all, > > > > My initial personal point of view was to use one mailing list both for > users > > and developers. That is neuroimaging at python.org (previously > nipy-devel...) > > Then I saw that this list was not attracting enough questions. This is > > probably because we didn't promote this list enough. And maybe that > > should have been the first thing to do. Which we clearly didn't do. > > Of course, there will always be a spectrum of users, from "just tell > me how to use it without it giving me an error message" to "I want to > write new stuff for the package". > > We were discussing this on the phone yesterday, but for me the > question is - what do we hold as the model for users in general? Do > we hold that all users should expect to contribute to the discussion > of how to build and maintain the package, or do we think that some > users can be safely left to - just use the package. > > As you know - I think we're running into severe trouble in > neuroimaging, as the software becomes easier to use, and there are > more methods available, without any matching increase in training. > So we have more and more people using software that they do not > understand. Inevitably, this means more bad science. > > The only way to avoid that, it to change the culture. We want to > switch from the classic model of "we are experts, trust us, use the > software" to "we are all learning how to do this. We are learning by > building. Come join in this difficult task". > > This is why I feel so strongly that we should not separate user and > developer questions. > > > Then I thought okay the neuroimaging at python.org list is for developers > and > > expert users and neurostars.org > > is for users who don't want to touch development and need feedback. > > Hence - I want to say to these type of users - "this is not a model we > support. Science is the disbelief in the opinion of experts. We > won't stop you doing this, but neither will we imply this is a way of > working that we encourage or expect." > > > But I have to say that there are some features in neurostars which can be > > dangerous. One of them is that people who answer questions get > > different status and reputation points. For example, the status of the > > person answering often says "trusted". This is misleading information. > > > > I think we need to be smarter here. There are no experts. We are research > > projects. We want a community which does not promote > > expertise but promotes understanding and good scientific practice. The > focus > > of neurostars should be exactly that. > > > > I see that neurostars is still in a beta and I am wondering if we can > change > > some of its settings. > > > > It is true that neurostars has attracted very quickly a relatively large > > audience. So, I am not sure if we should stop using it or not. But I will > > suggest something different. > > > > Can we continue using Neurostars with some different setup so that it > > promotes more understanding/discussion rather than expertise? > > > > To be more clear. Here is a summary of the important problems that > > StackOverflow has which also Neurostars can potentially have: > > > > This is from > > > http://michael.richter.name/blogs/awhy-i-no-longer-contribute-to-stackoverflow > > which was posted previously in this thread. Thanx for > > posting this. > > > > The problems with StackOverflow are summarized in this list: > > > > Poor pedagogy > > Poor reward system > > Poor community > > I'm afraid I believe these features are structural to the > stackoverflow "approved answer" model. What we need is a model that > encourages discussion, and the expectation that the beginner should > expect to become a peer. This is what mailing lists are very good at, > and approved answer models are very bad at. > > See you, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Aug 27 12:50:20 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 27 Aug 2015 11:50:20 +0100 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi Chris, On Thu, Aug 27, 2015 at 11:43 AM, Chris Filo Gorgolewski wrote: > Hi, > My 3 cents: Matthew, Bertrand - I would encourage you to give neurostars a > try. It really helps building the community and makes questions more > discoverable. There are some rough edges, but nothing we cannot work around. But my assertion (of course possibly false) is that the problems I'm talking about are structural to the approved answer format. Do you think that's possible? > Just remind yourselves how often do you find solutions to technical issue on > stackoverflow or similar services and then imagine that such knowledge > would've been hidden on some mailing lists with poor google indexing. I do often find answers on StackOverflow, but often on mailing lists - as far as I can see, google indexing has been pretty good in guiding me to the right answer on a mailing list. StackOverflow is the place often end up if I want to fix a compilation error and I don't much care why the error happened, but I don't think that's a good model for the nipy projects. See you, Matthew From krzysztof.gorgolewski at gmail.com Thu Aug 27 13:36:00 2015 From: krzysztof.gorgolewski at gmail.com (Chris Filo Gorgolewski) Date: Thu, 27 Aug 2015 21:36:00 +1000 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: On Thu, Aug 27, 2015 at 8:50 PM, Matthew Brett wrote: > Hi Chris, > > On Thu, Aug 27, 2015 at 11:43 AM, Chris Filo Gorgolewski > wrote: > > Hi, > > My 3 cents: Matthew, Bertrand - I would encourage you to give neurostars > a > > try. It really helps building the community and makes questions more > > discoverable. There are some rough edges, but nothing we cannot work > around. > > But my assertion (of course possibly false) is that the problems I'm > talking about are structural to the approved answer format. Do you > think that's possible? > I don't think anyone pays attention to the "approved answer" on neurostars right now since it's rarely used and there are only few cases with multiple answers. However even if we turn off the "approved answer" feature it would work better than a mailing list. At least in my opinion. Best, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Aug 27 14:43:40 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 27 Aug 2015 13:43:40 +0100 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, On Thu, Aug 27, 2015 at 12:36 PM, Chris Filo Gorgolewski wrote: > On Thu, Aug 27, 2015 at 8:50 PM, Matthew Brett > wrote: >> >> Hi Chris, >> >> On Thu, Aug 27, 2015 at 11:43 AM, Chris Filo Gorgolewski >> wrote: >> > Hi, >> > My 3 cents: Matthew, Bertrand - I would encourage you to give neurostars >> > a >> > try. It really helps building the community and makes questions more >> > discoverable. There are some rough edges, but nothing we cannot work >> > around. >> >> But my assertion (of course possibly false) is that the problems I'm >> talking about are structural to the approved answer format. Do you >> think that's possible? > > I don't think anyone pays attention to the "approved answer" on neurostars > right now since it's rarely used and there are only few cases with multiple > answers. However even if we turn off the "approved answer" feature it would > work better than a mailing list. At least in my opinion. Sure, I understand that it is in some sense more effective in getting searchable answers to the consumer, I don't think that's controversial. My question is - could it have other and undesirable effects? Cheers, Matthew From michael.hanke at gmail.com Thu Aug 27 15:08:19 2015 From: michael.hanke at gmail.com (Michael Hanke) Date: Thu, 27 Aug 2015 15:08:19 +0200 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: <46828206.9840802.1440517367148.JavaMail.zimbra@inria.fr> Message-ID: Hi, On Thu, Aug 27, 2015 at 2:43 PM, Matthew Brett wrote: > Sure, I understand that it is in some sense more effective in getting > searchable answers to the consumer, I don't think that's > controversial. My question is - could it have other and undesirable > effects? > Yes, it does. It is not uncommon that I have to correct information obtain from "somewhere on the internet" to help solve somebodies problem. But it seems that when help is needed "passive search" is way more frequent than active outreach. And then the question is: will a "random" search hit in a mailing list archive be more effective than a (somewhat) vetted answer on a Q&A site? I don't know... But at least theoretically, it is easier to update an answer on a QA site long after the original post was made, than it is to revive an old thread and do a post-mortem change of the original conclusion in the light of new insight. However, neither of that seems to make it more likely that people become a more active participant in a community. Michael -- Michael Hanke http://mih.voxindeserto.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Thu Aug 27 18:06:07 2015 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 27 Aug 2015 09:06:07 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Vanessa, On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat wrote: > This should be fairly easy to maintain. The main "package" pages are > jekyll, meaning anyone can push a PR to the repo, preview on circle, and > then deploy to github pages with approved changes. Developers know how to > use github. > > The hidden blog is hosted at tumblr, which means that: > Slick! I noticed the little tumblr features appearing ("folllow neuroimaging"), and thought that was some magic you put in without even noticing that I was redirected to the tumblr URL. I don't mind it. Two questions regarding that: 1. Blog posts would just be posted to this, right? No PR/review mechanism here? Is the main motivation to reduce the barrier to entry, or is this still about the CI jekyll baseurl business? Otherwise, we could still have the blog be part of the main site. As I understand it (and I might easily be wrong) Jekyll doesn't really make a distinction between "regular" pages and "blog posts" when generating the site from markdown files. 2. Commenting? Could that easily be enabled on tumblr? > - anyone can contribute content. We can let it get pushed or put it in a > queue for approval. > - posts can be done on mobile, or from email. In html, markdown, or > standard text editor. > - we can choose to "hide" the neuroimaging.tumblr.com url if we want, but > it's really not so bad. > - looks spiffy on mobile too :) > - posts can be associated with authors, but don't need to be. > - people can ask questions on posts, share posts, like them, etc. > - integrated notifications, social media, apps, all the standard stuff you > get with a platform like this. Tumblr has an API :) > > We kill lots of birds with a snakey thought stone. The site has CI, hosted > for free on ghpages, and is an easy workflow for developers to update or > add their packages. The site is also better integrated into the > non-developer community, because anyone can contribute content easily > without github, and we still have control over that content. > > If there is a huge redesign of the site, then the template would need to > be updated on tumblr, but that really comes down to copy pasting the base > code into the template editor. This was the idea that I had this morning. > > > On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat > wrote: > >> *Continuous integration:* >> >> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >> >> *Gihub pages:* >> http://vsoch.github.io/nipy-jekyll/ >> >> All things seem to be in working order :) >> >> >> >> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >> garyfallidis at gmail.com> wrote: >> >>> So another push for Jekyll? >>> >>> >>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>> >>>> Hey Eleftherios, >>>> >>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>> garyfallidis at gmail.com> wrote: >>>> >>>>> Hi Vanessa, >>>>> >>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>>> wrote: >>>>> >>>>>> Eleftherios, it's good that you express concern because that means >>>>>> that you care about nipy, and we can work together to ensure that the >>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>> let me implement what I have in mind, and then we can move forward with >>>>>> discussion on the points of content. >>>>>> >>>>>> >>>>> Sure, be happy to prepare whatever you think will help the discussion. >>>>> Can I ask you to summarize quickly here the next steps of development that >>>>> you have in mind? >>>>> >>>> >>>> I think that question has been answered here: >>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>> >>>> >>>>> Best, >>>>> Eleftherios >>>>> >>>>> >>>>> >>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>> vsochat at stanford.edu> wrote: >>>>>> >>>>>>> Hi Eleftherios, >>>>>>> >>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>> and we want to stay away from making something substantial that requires >>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>> for the rest, here are my thoughts: >>>>>>> >>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>> currently vague. >>>>>>>> >>>>>>>> A simple portal that gives nipy a brand, links to its products, and >>>>>>> integrates some platform for us to easily write about it. If something more >>>>>>> substantial than that is desired, then we first need to resolve where it >>>>>>> will be hosted and who takes responsibility for its life. >>>>>>> >>>>>>> >>>>>>>> c) How the website and e-mail lists/forums will benefit and promote >>>>>>>> the work and the vision of this organization. >>>>>>>> >>>>>>>> For the work - the website blog will afford all the things that >>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>> >>>>>>> >>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>> support a, b, c. >>>>>>>> >>>>>>>> Again, this is more about hosting and responsibility. >>>>>>> >>>>>>> >>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>> website projects which are not currently under our >>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>> consensus to take such a decisions. >>>>>>>> >>>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>>> the site functioning. >>>>>>> >>>>>>> >>>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>>> Neurostars for answering questions about the NIPY >>>>>>>> projects. This information and whatever we decide must be >>>>>>>> highlighted clearly in the portal. >>>>>>>> >>>>>>>> Lorem,.. ipsum... >>>>>>> >>>>>>> :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> exactly :) >>>>>>>>> >>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >>>>>>>>>>> Hi everyone! >>>>>>>>>>> >>>>>>>>>>> I thought more about this on my walk - here is a reasonable game >>>>>>>>>>> plan! I will do the work to put together a solution that integrates Ariel's >>>>>>>>>>> original vision with ghpages, the parts of Jekyll that do work, and a more >>>>>>>>>>> non developer friendly integrated blog. I think this could meet all of our >>>>>>>>>>> goals and be a solution that better integrates social aspects of our >>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> Bada-boum! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>> tested some things. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> >>>>>>>>>>> Vanessa >>>>>>>>>>> >>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>> > >>>>>>>>>>> > Hi, >>>>>>>>>>> > >>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>> >> Hi Group, >>>>>>>>>>> >> >>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>> goals of the site, >>>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>>> that is easy to >>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>> previewing >>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial look >>>>>>>>>>> of the site? >>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>> > >>>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>>> other >>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>> > >>>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>>> and >>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>> > >>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>> the >>>>>>>>>>> > sphinx documentation locally to preview it, but we can also do >>>>>>>>>>> what >>>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>> travis-ci >>>>>>>>>>> > matrix of jobs. >>>>>>>>>>> > >>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>> pages, >>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>> with a >>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>> building / >>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>> > >>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back >>>>>>>>>>> to >>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>> most >>>>>>>>>>> > Python developers. >>>>>>>>>>> > >>>>>>>>>>> > Thanks very much for doing all this work by the way - it's very >>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>> > >>>>>>>>>>> > See you, >>>>>>>>>>> > >>>>>>>>>>> > Matthew >>>>>>>>>>> > _______________________________________________ >>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Vanessa Villamia Sochat >>>>>>>>> Stanford University >>>>>>>>> (603) 321-0676 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Vanessa Villamia Sochat >>>>>> Stanford University >>>>>> (603) 321-0676 >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> > > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Thu Aug 27 19:04:39 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Thu, 27 Aug 2015 10:04:39 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: 1. Blog posts would be posted via tumblr. There is a PR mechanism - posts are submitted on our submit page , and there is some mechanism for reviewing submissions, or giving specific users free access to post what they like. ? We can also block if needed. *Pages vs. Posts* Jekyll will render almost anything (.md, .html, etc) not in a standard directory as a page, and so posts and pages are not much different in regard to format. The distinction is that to get pagination to work (i.e., the "blogroll") a custom configuration is needed for a special posts folder , and the files are expected to be named with a date format. This is where we ran into trouble in satisfying the need for CI, ghpages, and local development to work. If you remember this original post: https://mail.python.org/pipermail/neuroimaging/2015-August/000307.html much discussion came after that, and both Ben and I spent days trying to get something (even hacky) to work. To answer your question, the first move to an external platform was because the function just wouldn't work with Jekyll. However, after thinking about it, in making a choice that submitting a PR to a github repo is required to contribute, we are making a very strong statement about who we want to contribute. I'm not sure that we want to do that. If you want to take jekyll posts for a spin and see if you can get it working, I think it would be useful if we wanted some kind of "developer-only" posts. My general sense is that one of the goals of the site is to make it easier for contribution from the larger community, and so *only* having developer-friendly posts seems unwise. *Post content discussion is needed* It would be good to have discussion about what kind of posts we would want shared on nipy - for example I build little fun tools and think (and write) about methods all the time and post on my blog. I would guess other researchers might write things up from conferences, or even little tutorials. Some of that content could be really great to add to the nipy site for others to find. 2. Yes, there is commenting - two flavors. People can ask general questions , I just enabled that to show you. We can also enable comments for posts via disqus . On Thu, Aug 27, 2015 at 9:06 AM, Ariel Rokem wrote: > Hi Vanessa, > > On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat > wrote: > >> This should be fairly easy to maintain. The main "package" pages are >> jekyll, meaning anyone can push a PR to the repo, preview on circle, and >> then deploy to github pages with approved changes. Developers know how to >> use github. >> >> The hidden blog is hosted at tumblr, which means that: >> > > Slick! I noticed the little tumblr features appearing ("folllow > neuroimaging"), and thought that was some magic you put in without even > noticing that I was redirected to the tumblr URL. I don't mind it. > > Two questions regarding that: > > 1. Blog posts would just be posted to this, right? No PR/review mechanism > here? Is the main motivation to reduce the barrier to entry, or is this > still about the CI jekyll baseurl business? Otherwise, we could still have > the blog be part of the main site. As I understand it (and I might easily > be wrong) Jekyll doesn't really make a distinction between "regular" pages > and "blog posts" when generating the site from markdown files. > > 2. Commenting? Could that easily be enabled on tumblr? > > > >> - anyone can contribute content. We can let it get pushed or put it in a >> queue for approval. >> - posts can be done on mobile, or from email. In html, markdown, or >> standard text editor. >> - we can choose to "hide" the neuroimaging.tumblr.com url if we want, >> but it's really not so bad. >> - looks spiffy on mobile too :) >> - posts can be associated with authors, but don't need to be. >> - people can ask questions on posts, share posts, like them, etc. >> - integrated notifications, social media, apps, all the standard stuff >> you get with a platform like this. Tumblr has an API :) >> >> We kill lots of birds with a snakey thought stone. The site has CI, >> hosted for free on ghpages, and is an easy workflow for developers to >> update or add their packages. The site is also better integrated into the >> non-developer community, because anyone can contribute content easily >> without github, and we still have control over that content. >> >> If there is a huge redesign of the site, then the template would need to >> be updated on tumblr, but that really comes down to copy pasting the base >> code into the template editor. This was the idea that I had this morning. >> >> >> On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat >> wrote: >> >>> *Continuous integration:* >>> >>> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >>> >>> *Gihub pages:* >>> http://vsoch.github.io/nipy-jekyll/ >>> >>> All things seem to be in working order :) >>> >>> >>> >>> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >>> garyfallidis at gmail.com> wrote: >>> >>>> So another push for Jekyll? >>>> >>>> >>>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>>> >>>>> Hey Eleftherios, >>>>> >>>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>>> garyfallidis at gmail.com> wrote: >>>>> >>>>>> Hi Vanessa, >>>>>> >>>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat >>>>> > wrote: >>>>>> >>>>>>> Eleftherios, it's good that you express concern because that means >>>>>>> that you care about nipy, and we can work together to ensure that the >>>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>>> let me implement what I have in mind, and then we can move forward with >>>>>>> discussion on the points of content. >>>>>>> >>>>>>> >>>>>> Sure, be happy to prepare whatever you think will help the >>>>>> discussion. Can I ask you to summarize quickly here the next steps of >>>>>> development that you have in mind? >>>>>> >>>>> >>>>> I think that question has been answered here: >>>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>>> >>>>> >>>>>> Best, >>>>>> Eleftherios >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> Hi Eleftherios, >>>>>>>> >>>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>>> and we want to stay away from making something substantial that requires >>>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>>> for the rest, here are my thoughts: >>>>>>>> >>>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>>> currently vague. >>>>>>>>> >>>>>>>>> A simple portal that gives nipy a brand, links to its products, >>>>>>>> and integrates some platform for us to easily write about it. If something >>>>>>>> more substantial than that is desired, then we first need to resolve where >>>>>>>> it will be hosted and who takes responsibility for its life. >>>>>>>> >>>>>>>> >>>>>>>>> c) How the website and e-mail lists/forums will benefit and >>>>>>>>> promote the work and the vision of this organization. >>>>>>>>> >>>>>>>>> For the work - the website blog will afford all the things that >>>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>>> >>>>>>>> >>>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>>> support a, b, c. >>>>>>>>> >>>>>>>>> Again, this is more about hosting and responsibility. >>>>>>>> >>>>>>>> >>>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>>> website projects which are not currently under our >>>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>>> consensus to take such a decisions. >>>>>>>>> >>>>>>>>> You should consider all current content on the site as Lorem Ipsum >>>>>>>> etc. I simply reproduced what is on the current site and did not make any >>>>>>>> "decisions." As I said earlier, content and template come *after* getting >>>>>>>> the site functioning. >>>>>>>> >>>>>>>> >>>>>>>>> (c) is also much related to Matthew's e-mail for supporting or not >>>>>>>>> Neurostars for answering questions about the NIPY >>>>>>>>> projects. This information and whatever we decide must be >>>>>>>>> highlighted clearly in the portal. >>>>>>>>> >>>>>>>>> Lorem,.. ipsum... >>>>>>>> >>>>>>>> :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>> >>>>>>>>>> exactly :) >>>>>>>>>> >>>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi everyone! >>>>>>>>>>>> >>>>>>>>>>>> I thought more about this on my walk - here is a reasonable >>>>>>>>>>>> game plan! I will do the work to put together a solution that integrates >>>>>>>>>>>> Ariel's original vision with ghpages, the parts of Jekyll that do work, and >>>>>>>>>>>> a more non developer friendly integrated blog. I think this could meet all >>>>>>>>>>>> of our goals and be a solution that better integrates social aspects of our >>>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>> Bada-boum! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>>> tested some things. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> Vanessa >>>>>>>>>>>> >>>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Hi, >>>>>>>>>>>> > >>>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>> >> Hi Group, >>>>>>>>>>>> >> >>>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>>> goals of the site, >>>>>>>>>>>> >> and want to bring everyone in. In summary, we want something >>>>>>>>>>>> that is easy to >>>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>>> previewing >>>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial >>>>>>>>>>>> look of the site? >>>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>>> > >>>>>>>>>>>> > Actually, I think that sphinx is a very good option, and most >>>>>>>>>>>> other >>>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>>> > >>>>>>>>>>>> > The particular template that we were using was a little dated >>>>>>>>>>>> and >>>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>>> > >>>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>>> the >>>>>>>>>>>> > sphinx documentation locally to preview it, but we can also >>>>>>>>>>>> do what >>>>>>>>>>>> > other projects are doing, and build / publish the docs in some >>>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>>> travis-ci >>>>>>>>>>>> > matrix of jobs. >>>>>>>>>>>> > >>>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>>> pages, >>>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>>> with a >>>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>>> building / >>>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>>> > >>>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go back >>>>>>>>>>>> to >>>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>>> most >>>>>>>>>>>> > Python developers. >>>>>>>>>>>> > >>>>>>>>>>>> > Thanks very much for doing all this work by the way - it's >>>>>>>>>>>> very >>>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>>> > >>>>>>>>>>>> > See you, >>>>>>>>>>>> > >>>>>>>>>>>> > Matthew >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>> Stanford University >>>>>>>>>> (603) 321-0676 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Neuroimaging mailing list >>>>>>>>> Neuroimaging at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Vanessa Villamia Sochat >>>>>>> Stanford University >>>>>>> (603) 321-0676 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >> >> >> >> -- >> Vanessa Villamia Sochat >> Stanford University >> (603) 321-0676 >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: submissions.png Type: image/png Size: 38786 bytes Desc: not available URL: From arokem at gmail.com Thu Aug 27 20:41:06 2015 From: arokem at gmail.com (Ariel Rokem) Date: Thu, 27 Aug 2015 11:41:06 -0700 Subject: [Neuroimaging] Site Discussion In-Reply-To: References: <1CC52DCE-F7A5-4C41-8D51-25785E010311@stanford.edu> Message-ID: Hi Vanessa, On Thu, Aug 27, 2015 at 10:04 AM, vanessa sochat wrote: > 1. Blog posts would be posted via tumblr. There is a PR mechanism - posts > are submitted on our submit page , > and there is some mechanism for reviewing submissions, or giving specific > users free access to post what they like. > > > ? > > We can also block if needed. > > OK - seems good. > *Pages vs. Posts* > Jekyll will render almost anything (.md, .html, etc) not in a standard > directory as a page, and so posts and pages are not much different in > regard to format. The distinction is that to get pagination to work (i.e., > the "blogroll") a custom configuration is needed for a special posts > folder , and the files are expected to > be named with a date format. This is where we ran into trouble in > satisfying the need for CI, ghpages, and local development to work. If you > remember this original post: > > https://mail.python.org/pipermail/neuroimaging/2015-August/000307.html > > THANK YOU for explaining that again, slowly :-) Makes sense. I am 100% on board with moving blogging activities to an external platform - tumblr seems fine. > much discussion came after that, and both Ben and I spent days > trying to get > something (even hacky) to work. To answer your question, the first move to > an external platform was because the function just wouldn't work with > Jekyll. However, after thinking about it, in making a choice that > submitting a PR to a github repo is required to contribute, we are making a > very strong statement about who we want to contribute. I'm not sure that we > want to do that. If you want to take jekyll posts for a spin and see if you > can get it working, I think it would be useful if we wanted some kind of > "developer-only" posts. My general sense is that one of the goals of the > site is to make it easier for contribution from the larger community, and > so *only* having developer-friendly posts seems unwise. > *Post content discussion is needed* > It would be good to have discussion about what kind of posts we would want > shared on nipy - for example I build little fun tools and think (and write) > about methods all the time and post on my blog. I would guess other > researchers might write things up from conferences, or even little > tutorials. Some of that content could be really great to add to the nipy > site for others to find. > I think that I would probably write here every once in a while. The example of embedding nbviewer is compelling to me. I might post a notebook with some small observation about neuroimaging in python, as I run into these. I haven't been particularly consistent as a blogger in the past, though, so that's a tentative promise. A post that I would definitely write up almost immediately: GSoC is coming to an end, and I would like to write a summary blog-post from the point of view of mentoring one of the dipy projects. Saying something about the joys and trials of the experience, and talk about things we need to think about next time we do this. > 2. Yes, there is commenting - two flavors. People can ask general > questions , I just enabled that to > show you. We can also enable comments for posts via disqus > . > That's good If I didn't know better I'd suggest we direct people from neurostars to the "ask me anything" box ;-D => maybe we should disable that one. I think that we really just want the option for people to comment on the specific contents of a particular post. Thanks again for all your efforts in thinking/doing on this! Ariel > > On Thu, Aug 27, 2015 at 9:06 AM, Ariel Rokem wrote: > >> Hi Vanessa, >> >> On Wed, Aug 26, 2015 at 4:13 PM, vanessa sochat >> wrote: >> >>> This should be fairly easy to maintain. The main "package" pages are >>> jekyll, meaning anyone can push a PR to the repo, preview on circle, and >>> then deploy to github pages with approved changes. Developers know how to >>> use github. >>> >>> The hidden blog is hosted at tumblr, which means that: >>> >> >> Slick! I noticed the little tumblr features appearing ("folllow >> neuroimaging"), and thought that was some magic you put in without even >> noticing that I was redirected to the tumblr URL. I don't mind it. >> >> Two questions regarding that: >> >> 1. Blog posts would just be posted to this, right? No PR/review mechanism >> here? Is the main motivation to reduce the barrier to entry, or is this >> still about the CI jekyll baseurl business? Otherwise, we could still have >> the blog be part of the main site. As I understand it (and I might easily >> be wrong) Jekyll doesn't really make a distinction between "regular" pages >> and "blog posts" when generating the site from markdown files. >> >> 2. Commenting? Could that easily be enabled on tumblr? >> >> >> >>> - anyone can contribute content. We can let it get pushed or put it in a >>> queue for approval. >>> - posts can be done on mobile, or from email. In html, markdown, or >>> standard text editor. >>> - we can choose to "hide" the neuroimaging.tumblr.com url if we want, >>> but it's really not so bad. >>> - looks spiffy on mobile too :) >>> - posts can be associated with authors, but don't need to be. >>> - people can ask questions on posts, share posts, like them, etc. >>> - integrated notifications, social media, apps, all the standard stuff >>> you get with a platform like this. Tumblr has an API :) >>> >>> We kill lots of birds with a snakey thought stone. The site has CI, >>> hosted for free on ghpages, and is an easy workflow for developers to >>> update or add their packages. The site is also better integrated into the >>> non-developer community, because anyone can contribute content easily >>> without github, and we still have control over that content. >>> >>> If there is a huge redesign of the site, then the template would need to >>> be updated on tumblr, but that really comes down to copy pasting the base >>> code into the template editor. This was the idea that I had this morning. >>> >>> >>> On Wed, Aug 26, 2015 at 3:44 PM, vanessa sochat >>> wrote: >>> >>>> *Continuous integration:* >>>> >>>> https://circle-artifacts.com/gh/vsoch/nipy-jekyll/68/artifacts/0/home/ubuntu/nipy-jekyll/_site/index.html >>>> >>>> *Gihub pages:* >>>> http://vsoch.github.io/nipy-jekyll/ >>>> >>>> All things seem to be in working order :) >>>> >>>> >>>> >>>> On Wed, Aug 26, 2015 at 3:25 PM, Eleftherios Garyfallidis < >>>> garyfallidis at gmail.com> wrote: >>>> >>>>> So another push for Jekyll? >>>>> >>>>> >>>>> On Wed, Aug 26, 2015 at 6:05 PM, Ariel Rokem wrote: >>>>> >>>>>> Hey Eleftherios, >>>>>> >>>>>> On Wed, Aug 26, 2015 at 1:08 PM, Eleftherios Garyfallidis < >>>>>> garyfallidis at gmail.com> wrote: >>>>>> >>>>>>> Hi Vanessa, >>>>>>> >>>>>>> On Wed, Aug 26, 2015 at 3:20 PM, vanessa sochat < >>>>>>> vsochat at stanford.edu> wrote: >>>>>>> >>>>>>>> Eleftherios, it's good that you express concern because that means >>>>>>>> that you care about nipy, and we can work together to ensure that the >>>>>>>> vision is properly reflected in this site. It's typically not a straight >>>>>>>> path to converge on the right solution, and I think that it's ok we are >>>>>>>> needing to try different things. If it isn't too troubling to you, please >>>>>>>> let me implement what I have in mind, and then we can move forward with >>>>>>>> discussion on the points of content. >>>>>>>> >>>>>>>> >>>>>>> Sure, be happy to prepare whatever you think will help the >>>>>>> discussion. Can I ask you to summarize quickly here the next steps of >>>>>>> development that you have in mind? >>>>>>> >>>>>> >>>>>> I think that question has been answered here: >>>>>> https://mail.python.org/pipermail/neuroimaging/2015-August/000380.html >>>>>> >>>>>> >>>>>>> Best, >>>>>>> Eleftherios >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Wed, Aug 26, 2015 at 12:09 PM, vanessa sochat < >>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>> >>>>>>>>> Hi Eleftherios, >>>>>>>>> >>>>>>>>> A framework like Django is too heavy for a simple portal and blog, >>>>>>>>> and we want to stay away from making something substantial that requires >>>>>>>>> regular maintenance and care, and an actual server. We can achieve all the >>>>>>>>> functionality of comments / social media, etc by integrating a blogging >>>>>>>>> platform into a site that works on Github pages. Question b (sites >>>>>>>>> included) and c (organization vision) needs discussion from everyone, and >>>>>>>>> for the rest, here are my thoughts: >>>>>>>>> >>>>>>>>> a) What the portal is about? We need to reach consensus. This is >>>>>>>>>> currently vague. >>>>>>>>>> >>>>>>>>>> A simple portal that gives nipy a brand, links to its products, >>>>>>>>> and integrates some platform for us to easily write about it. If something >>>>>>>>> more substantial than that is desired, then we first need to resolve where >>>>>>>>> it will be hosted and who takes responsibility for its life. >>>>>>>>> >>>>>>>>> >>>>>>>>>> c) How the website and e-mail lists/forums will benefit and >>>>>>>>>> promote the work and the vision of this organization. >>>>>>>>>> >>>>>>>>>> For the work - the website blog will afford all the things that >>>>>>>>> blogs afford: sharing ideas, examples, links, social media integration, etc. >>>>>>>>> >>>>>>>>> >>>>>>>>>> d) Make some decisions on the technologies that we can use to >>>>>>>>>> support a, b, c. >>>>>>>>>> >>>>>>>>>> Again, this is more about hosting and responsibility. >>>>>>>>> >>>>>>>>> >>>>>>>>>> (b) is critical because for example I saw that you added in the >>>>>>>>>> website projects which are not currently under our >>>>>>>>>> github organization https://github.com/nipy. I think we need >>>>>>>>>> consensus to take such a decisions. >>>>>>>>>> >>>>>>>>>> You should consider all current content on the site as Lorem >>>>>>>>> Ipsum etc. I simply reproduced what is on the current site and did not make >>>>>>>>> any "decisions." As I said earlier, content and template come >>>>>>>>> *after* getting the site functioning. >>>>>>>>> >>>>>>>>> >>>>>>>>>> (c) is also much related to Matthew's e-mail for supporting or >>>>>>>>>> not Neurostars for answering questions about the NIPY >>>>>>>>>> projects. This information and whatever we decide must be >>>>>>>>>> highlighted clearly in the portal. >>>>>>>>>> >>>>>>>>>> Lorem,.. ipsum... >>>>>>>>> >>>>>>>>> :) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 26, 2015 at 1:54 PM, vanessa sochat < >>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>> >>>>>>>>>>> exactly :) >>>>>>>>>>> >>>>>>>>>>> https://www.youtube.com/watch?v=Uwzg7SYZKF0 >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 26, 2015 at 10:46 AM, Ariel Rokem >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sorry - didn't see that one for some reason. >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 26, 2015 at 9:23 AM, Vanessa Villamia Sochat < >>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi everyone! >>>>>>>>>>>>> >>>>>>>>>>>>> I thought more about this on my walk - here is a reasonable >>>>>>>>>>>>> game plan! I will do the work to put together a solution that integrates >>>>>>>>>>>>> Ariel's original vision with ghpages, the parts of Jekyll that do work, and >>>>>>>>>>>>> a more non developer friendly integrated blog. I think this could meet all >>>>>>>>>>>>> of our goals and be a solution that better integrates social aspects of our >>>>>>>>>>>>> community - github just doesn't specialize in blogging but many services >>>>>>>>>>>>> do. If that does not work, then we can go to Sphinx. Boum! >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>>> Bada-boum! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I will send out an update likely during weekend time when I've >>>>>>>>>>>>> tested some things. >>>>>>>>>>>>> >>>>>>>>>>>>> Best, >>>>>>>>>>>>> >>>>>>>>>>>>> Vanessa >>>>>>>>>>>>> >>>>>>>>>>>>> > On Aug 26, 2015, at 8:32 AM, Matthew Brett < >>>>>>>>>>>>> matthew.brett at gmail.com> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Hi, >>>>>>>>>>>>> > >>>>>>>>>>>>> >> On Wed, Aug 26, 2015 at 4:10 PM, vanessa sochat < >>>>>>>>>>>>> vsochat at stanford.edu> wrote: >>>>>>>>>>>>> >> Hi Group, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Ben and I are having some discussion on the higher level >>>>>>>>>>>>> goals of the site, >>>>>>>>>>>>> >> and want to bring everyone in. In summary, we want >>>>>>>>>>>>> something that is easy to >>>>>>>>>>>>> >> contribute content to, and has continuous integration for >>>>>>>>>>>>> previewing >>>>>>>>>>>>> >> updates. I am wondering, what was wrong with the initial >>>>>>>>>>>>> look of the site? >>>>>>>>>>>>> >> Was it that sphinx is hard to update? >>>>>>>>>>>>> > >>>>>>>>>>>>> > Actually, I think that sphinx is a very good option, and >>>>>>>>>>>>> most other >>>>>>>>>>>>> > scientific Python sites use sphinx for their main pages. >>>>>>>>>>>>> > >>>>>>>>>>>>> > The particular template that we were using was a little >>>>>>>>>>>>> dated and >>>>>>>>>>>>> > ugly, but I bet that could be improved. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Most if not all developers are perfectly capable of building >>>>>>>>>>>>> the >>>>>>>>>>>>> > sphinx documentation locally to preview it, but we can also >>>>>>>>>>>>> do what >>>>>>>>>>>>> > other projects are doing, and build / publish the docs in >>>>>>>>>>>>> some >>>>>>>>>>>>> > temporary place for each commit, using an entry in the >>>>>>>>>>>>> travis-ci >>>>>>>>>>>>> > matrix of jobs. >>>>>>>>>>>>> > >>>>>>>>>>>>> > I think Ariel was particularly attracted to Jekyll / github >>>>>>>>>>>>> pages, >>>>>>>>>>>>> > because it is very easy to get a rendered version to look at >>>>>>>>>>>>> with a >>>>>>>>>>>>> > git push, and although that is generally desirable, I think >>>>>>>>>>>>> building / >>>>>>>>>>>>> > reviewing locally is at least as important. >>>>>>>>>>>>> > >>>>>>>>>>>>> > So - if it were entirely up to me - I would prefer we go >>>>>>>>>>>>> back to >>>>>>>>>>>>> > sphinx, on the basis that it is a very familiar workflow to >>>>>>>>>>>>> most >>>>>>>>>>>>> > Python developers. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thanks very much for doing all this work by the way - it's >>>>>>>>>>>>> very >>>>>>>>>>>>> > helpful, and I'm sorry that we are going round and round. >>>>>>>>>>>>> > >>>>>>>>>>>>> > See you, >>>>>>>>>>>>> > >>>>>>>>>>>>> > Matthew >>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>> > Neuroimaging mailing list >>>>>>>>>>>>> > Neuroimaging at python.org >>>>>>>>>>>>> > https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Vanessa Villamia Sochat >>>>>>>>>>> Stanford University >>>>>>>>>>> (603) 321-0676 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Neuroimaging mailing list >>>>>>>>>>> Neuroimaging at python.org >>>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Neuroimaging mailing list >>>>>>>>>> Neuroimaging at python.org >>>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Vanessa Villamia Sochat >>>>>>>>> Stanford University >>>>>>>>> (603) 321-0676 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Vanessa Villamia Sochat >>>>>>>> Stanford University >>>>>>>> (603) 321-0676 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Neuroimaging mailing list >>>>>>>> Neuroimaging at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Neuroimaging mailing list >>>>>>> Neuroimaging at python.org >>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Neuroimaging mailing list >>>>>> Neuroimaging at python.org >>>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Neuroimaging mailing list >>>>> Neuroimaging at python.org >>>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vanessa Villamia Sochat >>>> Stanford University >>>> (603) 321-0676 >>>> >>> >>> >>> >>> -- >>> Vanessa Villamia Sochat >>> Stanford University >>> (603) 321-0676 >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: submissions.png Type: image/png Size: 38786 bytes Desc: not available URL: From bertrand.thirion at inria.fr Thu Aug 27 23:28:30 2015 From: bertrand.thirion at inria.fr (bthirion) Date: Thu, 27 Aug 2015 23:28:30 +0200 Subject: [Neuroimaging] When to use neurostars, and when not to In-Reply-To: References: Message-ID: <55DF80FE.3010206@inria.fr> Sure I'll give a try. Best, Bertrand On 27/08/2015 12:43, Chris Filo Gorgolewski wrote: > Hi, > My 3 cents: Matthew, Bertrand - I would encourage you to give > neurostars a try. It really helps building the community and makes > questions more discoverable. There are some rough edges, but nothing > we cannot work around. > > Just remind yourselves how often do you find solutions to technical > issue on stackoverflow or similar services and then imagine that such > knowledge would've been hidden on some mailing lists with poor google > indexing. > > Best, > Chris > From matthew.brett at gmail.com Fri Aug 28 15:35:51 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 28 Aug 2015 14:35:51 +0100 Subject: [Neuroimaging] Upcoming nipy release Message-ID: Hi, I'm just finishing up some fixes to get the tests passing for nipy. If any of you have a few minutes, I would be very grateful for reviews on the current PRs: https://github.com/nipy/nipy/pull/348 https://github.com/nipy/nipy/pull/346 https://github.com/nipy/nipy/pull/341 One we have all the tests passing on travis, then we are in the hope straight for a release. Has anyone got PRs or feature requests or issues they want dealt with in this release? Cheers, Matthew From bcipolli at ucsd.edu Fri Aug 28 16:28:32 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Fri, 28 Aug 2015 07:28:32 -0700 Subject: [Neuroimaging] Upcoming nipy release In-Reply-To: References: Message-ID: I plan to submit a PR to fix the np.diag() issue (#325). I can do that today. On Fri, Aug 28, 2015 at 6:35 AM, Matthew Brett wrote: > Hi, > > I'm just finishing up some fixes to get the tests passing for nipy. > If any of you have a few minutes, I would be very grateful for reviews > on the current PRs: > > https://github.com/nipy/nipy/pull/348 > https://github.com/nipy/nipy/pull/346 > https://github.com/nipy/nipy/pull/341 > > One we have all the tests passing on travis, then we are in the hope > straight for a release. > > Has anyone got PRs or feature requests or issues they want dealt with > in this release? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at onerussian.com Fri Aug 28 15:59:30 2015 From: lists at onerussian.com (Yaroslav Halchenko) Date: Fri, 28 Aug 2015 09:59:30 -0400 Subject: [Neuroimaging] Upcoming nipy release In-Reply-To: References: Message-ID: <20150828135930.GR19455@onerussian.com> On Fri, 28 Aug 2015, Matthew Brett wrote: > I'm just finishing up some fixes to get the tests passing for nipy. > If any of you have a few minutes, I would be very grateful for reviews > on the current PRs: > https://github.com/nipy/nipy/pull/348 > https://github.com/nipy/nipy/pull/346 > https://github.com/nipy/nipy/pull/341 > One we have all the tests passing on travis, then we are in the hope > straight for a release. AWESOME! FWIW, I don't remember if I have shared before... For DataLad I have setup buildbot to 1. forward build reports back to travis 2. monitor for PRs and run tests on them as well it might be a well worth addition to nibotmi, although I don't know when myself I could jump to implement that, so decided just to share for now. Demo -- any datalad PR on github (with less than a 100 or so commits, some bug causes my ad-hoc setup to not pick up those PRs for testing), e.g.: https://github.com/datalad/datalad/pull/101 (scroll to the bottom ;) some are failing atm) Our setup is https://github.com/datalad/buildbot which is in large based on https://github.com/ethereum/ethereum-buildbot and apparently work on supporting pull_requests in stock buildbot since then was accepted! https://github.com/buildbot/buildbot/pull/1632 so I might look into redoing it using stock features -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From bcipolli at ucsd.edu Fri Aug 28 17:23:17 2015 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Fri, 28 Aug 2015 08:23:17 -0700 Subject: [Neuroimaging] Upcoming nipy release In-Reply-To: References: Message-ID: It looks like there are two commits (mostly PEP8 and documentation) on the maint/0.3.x branch that are not in the master branch. Is it OK to create a PR to merge those in? On Fri, Aug 28, 2015 at 6:35 AM, Matthew Brett wrote: > Hi, > > I'm just finishing up some fixes to get the tests passing for nipy. > If any of you have a few minutes, I would be very grateful for reviews > on the current PRs: > > https://github.com/nipy/nipy/pull/348 > https://github.com/nipy/nipy/pull/346 > https://github.com/nipy/nipy/pull/341 > > One we have all the tests passing on travis, then we are in the hope > straight for a release. > > Has anyone got PRs or feature requests or issues they want dealt with > in this release? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Fri Aug 28 17:34:20 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 28 Aug 2015 16:34:20 +0100 Subject: [Neuroimaging] Upcoming nipy release In-Reply-To: References: Message-ID: Hi, On Fri, Aug 28, 2015 at 4:23 PM, Ben Cipollini wrote: > It looks like there are two commits (mostly PEP8 and documentation) on the > maint/0.3.x branch that are not in the master branch. Is it OK to create a > PR to merge those in? Great, thanks, please do. Matthew From garyfallidis at gmail.com Fri Aug 28 21:24:32 2015 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Fri, 28 Aug 2015 15:24:32 -0400 Subject: [Neuroimaging] [Dipy] Congratulations to Rafael and Julio for GSoC! Results! Message-ID: Hey Julio and Rafael, I just got the news from GSoC that you successfully passed your final evaluations for GSoC!!! Have a great day! You can party hard today. You deserve it! And thank you for your great work! Best regards, Eleftherios p.s. When your blogs/code are in a final state according to your standards, you may want to share them here so that others can learn more about your projects. Your call! -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Sat Aug 29 10:45:53 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 29 Aug 2015 09:45:53 +0100 Subject: [Neuroimaging] Upcoming nipy release In-Reply-To: References: Message-ID: On Fri, Aug 28, 2015 at 2:35 PM, Matthew Brett wrote: > Hi, > > I'm just finishing up some fixes to get the tests passing for nipy. > If any of you have a few minutes, I would be very grateful for reviews > on the current PRs: > > https://github.com/nipy/nipy/pull/348 > https://github.com/nipy/nipy/pull/346 > https://github.com/nipy/nipy/pull/341 We are now only holding on for a review of pull request 346. I've done my best to make this as easy as possible, with a summary here: https://github.com/nipy/nipy/pull/346#issuecomment-135900549 Any takers? Cheers, Matthew From matthew.brett at gmail.com Sat Aug 29 10:59:00 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 29 Aug 2015 09:59:00 +0100 Subject: [Neuroimaging] Upcoming nipy release In-Reply-To: <20150828135930.GR19455@onerussian.com> References: <20150828135930.GR19455@onerussian.com> Message-ID: Hi, On Fri, Aug 28, 2015 at 2:59 PM, Yaroslav Halchenko wrote: > > On Fri, 28 Aug 2015, Matthew Brett wrote: >> I'm just finishing up some fixes to get the tests passing for nipy. >> If any of you have a few minutes, I would be very grateful for reviews >> on the current PRs: > >> https://github.com/nipy/nipy/pull/348 >> https://github.com/nipy/nipy/pull/346 >> https://github.com/nipy/nipy/pull/341 > >> One we have all the tests passing on travis, then we are in the hope >> straight for a release. > > AWESOME! > > FWIW, I don't remember if I have shared before... > For DataLad I have setup buildbot to > > 1. forward build reports back to travis > 2. monitor for PRs and run tests on them as well > > it might be a well worth addition to nibotmi, although I don't know when > myself I could jump to implement that, so decided just to share for now. > > Demo -- any datalad PR on github (with less than a 100 or so commits, some bug > causes my ad-hoc setup to not pick up those PRs for testing), e.g.: > https://github.com/datalad/datalad/pull/101 (scroll to the bottom ;) some are > failing atm) > > Our setup is https://github.com/datalad/buildbot which is in large based on > https://github.com/ethereum/ethereum-buildbot and apparently work on supporting > pull_requests in stock buildbot since then was accepted! > https://github.com/buildbot/buildbot/pull/1632 > so I might look into redoing it using stock features That would be really good - if you do have time to do it. It would be ideal to get the buildbots integrated into the github interface... See you, Matthew From ben.cipollini at gmail.com Sat Aug 29 19:51:15 2015 From: ben.cipollini at gmail.com (Ben Cipollini) Date: Sat, 29 Aug 2015 10:51:15 -0700 Subject: [Neuroimaging] [Dipy] Congratulations to Rafael and Julio for GSoC! Results! In-Reply-To: References: Message-ID: Would love to see the blogs, please share here. Congrats!! Ben On Aug 28, 2015 12:25 PM, "Eleftherios Garyfallidis" wrote: > Hey Julio and Rafael, > > I just got the news from GSoC that you successfully passed your final > evaluations for GSoC!!! > > Have a great day! You can party hard today. You deserve it! > > And thank you for your great work! > > Best regards, > Eleftherios > > p.s. When your blogs/code are in a final state according to your > standards, you may want to share them here so that others can learn more > about your projects. Your call! > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwaskom at stanford.edu Sat Aug 29 21:31:44 2015 From: mwaskom at stanford.edu (Michael Waskom) Date: Sat, 29 Aug 2015 12:31:44 -0700 Subject: [Neuroimaging] Should we prefer nii.gz or nii? Message-ID: Hi folks, I've typically used nii.gz format for all of my data. This is also the prescription in the new BIDS spec. Lately, though, I've been wondering whether this makes sense in all cases. It seems like ZFS is becoming more common for storage in cluster environments. As I understand it, this means that much of the compression that you would get from using .nii.gz will also be applied to normal .nii files. There are other benefits to .nii as well, for instance, memory-mapping the files when you load them in nibabel. I'm not sure how decompression affects load/save times when reading from ZFS using compressed files, but there might be additional costs there. Do others have thoughts about the relative merits of compressed vs. uncompressed files? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Sat Aug 29 21:49:06 2015 From: arokem at gmail.com (Ariel Rokem) Date: Sat, 29 Aug 2015 12:49:06 -0700 Subject: [Neuroimaging] [Dipy] Congratulations to Rafael and Julio for GSoC! Results! In-Reply-To: References: Message-ID: Congratulations from here as well! Inspiring work! Ariel On Sat, Aug 29, 2015 at 10:51 AM, Ben Cipollini wrote: > Would love to see the blogs, please share here. Congrats!! > Ben > On Aug 28, 2015 12:25 PM, "Eleftherios Garyfallidis" < > garyfallidis at gmail.com> wrote: > >> Hey Julio and Rafael, >> >> I just got the news from GSoC that you successfully passed your final >> evaluations for GSoC!!! >> >> Have a great day! You can party hard today. You deserve it! >> >> And thank you for your great work! >> >> Best regards, >> Eleftherios >> >> p.s. When your blogs/code are in a final state according to your >> standards, you may want to share them here so that others can learn more >> about your projects. Your call! >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jevillalonr at gmail.com Sun Aug 30 06:45:45 2015 From: jevillalonr at gmail.com (Julio Villalon) Date: Sat, 29 Aug 2015 23:45:45 -0500 Subject: [Neuroimaging] [Dipy] Congratulations to Rafael and Julio for GSoC! Results! In-Reply-To: References: Message-ID: Hi everyone, This has been an awesome experience! It was a pleasure to work with all of you and I hope this won't end here. This is the blog I have been and will continue updating as we move forward with this project: http://julioquillero.blogspot.com/ and this is my pull request: https://github.com/nipy/dipy/pull/670 There is still a lot to do and I am open to ideas on how to make the code more efficient and better in general. Thanks a lot! Cheers Julio 2015-08-29 14:49 GMT-05:00 Ariel Rokem : > Congratulations from here as well! Inspiring work! > > Ariel > > On Sat, Aug 29, 2015 at 10:51 AM, Ben Cipollini > wrote: > >> Would love to see the blogs, please share here. Congrats!! >> Ben >> On Aug 28, 2015 12:25 PM, "Eleftherios Garyfallidis" < >> garyfallidis at gmail.com> wrote: >> >>> Hey Julio and Rafael, >>> >>> I just got the news from GSoC that you successfully passed your final >>> evaluations for GSoC!!! >>> >>> Have a great day! You can party hard today. You deserve it! >>> >>> And thank you for your great work! >>> >>> Best regards, >>> Eleftherios >>> >>> p.s. When your blogs/code are in a final state according to your >>> standards, you may want to share them here so that others can learn more >>> about your projects. Your call! >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sun Aug 30 22:16:52 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sun, 30 Aug 2015 13:16:52 -0700 Subject: [Neuroimaging] Site Contributions In-Reply-To: References: Message-ID: Also, my work / response time will be sparse this week - my brother is getting married :o) I will likely be able to do the next round of edits when I get back, so please on the github issues... post away ! On Sun, Aug 30, 2015 at 1:14 PM, vanessa sochat wrote: > Hi Everyone, > > I've finished work on the "contribute" page with my thinking for how to > contribute various content: > > http://vsoch.github.io/nipy-jekyll/contribute.html > > and as an example, put up a quick blog post: > > http://neuroimaging.tumblr.com/ > > The old "example" blog posts are hidden (private) and can be viewed if you > are a contributor. I'd like to add anyone and everyone interested to > contribute as "official" contributors via tumblr - if you are interested > please send me your email address. I've already invited some of you for > which I know the email. > > Best, > > Vanessa > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sun Aug 30 22:21:21 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sun, 30 Aug 2015 13:21:21 -0700 Subject: [Neuroimaging] Site Contributions In-Reply-To: References: Message-ID: It would be good to get a document or discussion going about what kinds of content are allowed to contribute. For example, whenever we have some kind of press for the reproducibility center, a cool tutorial from our lab, or a neuroimaging tool I'd want feedback on, I'd want to be able to share it. So clearly defining what we will allow / not allow is paramount to figure out soon :) On Sun, Aug 30, 2015 at 1:14 PM, vanessa sochat wrote: > Hi Everyone, > > I've finished work on the "contribute" page with my thinking for how to > contribute various content: > > http://vsoch.github.io/nipy-jekyll/contribute.html > > and as an example, put up a quick blog post: > > http://neuroimaging.tumblr.com/ > > The old "example" blog posts are hidden (private) and can be viewed if you > are a contributor. I'd like to add anyone and everyone interested to > contribute as "official" contributors via tumblr - if you are interested > please send me your email address. I've already invited some of you for > which I know the email. > > Best, > > Vanessa > > > -- > Vanessa Villamia Sochat > Stanford University > (603) 321-0676 > -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsochat at stanford.edu Sun Aug 30 22:14:13 2015 From: vsochat at stanford.edu (vanessa sochat) Date: Sun, 30 Aug 2015 13:14:13 -0700 Subject: [Neuroimaging] Site Contributions Message-ID: Hi Everyone, I've finished work on the "contribute" page with my thinking for how to contribute various content: http://vsoch.github.io/nipy-jekyll/contribute.html and as an example, put up a quick blog post: http://neuroimaging.tumblr.com/ The old "example" blog posts are hidden (private) and can be viewed if you are a contributor. I'd like to add anyone and everyone interested to contribute as "official" contributors via tumblr - if you are interested please send me your email address. I've already invited some of you for which I know the email. Best, Vanessa -- Vanessa Villamia Sochat Stanford University (603) 321-0676 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abraham.alexandre at gmail.com Mon Aug 31 09:38:43 2015 From: abraham.alexandre at gmail.com (Alexandre ABRAHAM) Date: Mon, 31 Aug 2015 09:38:43 +0200 Subject: [Neuroimaging] Should we prefer nii.gz or nii? In-Reply-To: References: Message-ID: Hi Michael, Do others have thoughts about the relative merits of compressed vs. > uncompressed files? > This is a choice that depends heavily on the usage and the underlying hardware. As an example, nii is faster on my laptop, since I have a SSD. On my desktop, niigz tends to be faster but, for some tasks, I use nii because I want the data to be memmapped. On our cluster, I made some benchs and nii is the winner. That also depends if your processing is IO-bound or CPU-bound. What would be very useful though is to be able to read niigz files by chuncks. With nii, it's easy: the data is memapped so I don't need special processing. But if an uncompressed niigz file does not fit in memory, it would be good to still be able to process it online. I have code for that but it is very specific to my usage. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Aug 31 09:59:46 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 31 Aug 2015 08:59:46 +0100 Subject: [Neuroimaging] Should we prefer nii.gz or nii? In-Reply-To: References: Message-ID: Hi Abraham, On Mon, Aug 31, 2015 at 8:38 AM, Alexandre ABRAHAM wrote: > Hi Michael, > >> Do others have thoughts about the relative merits of compressed vs. >> uncompressed files? > > > This is a choice that depends heavily on the usage and the underlying > hardware. As an example, nii is faster on my laptop, since I have a SSD. On > my desktop, niigz tends to be faster but, for some tasks, I use nii because > I want the data to be memmapped. On our cluster, I made some benchs and nii > is the winner. That also depends if your processing is IO-bound or > CPU-bound. > > What would be very useful though is to be able to read niigz files by > chuncks. With nii, it's easy: the data is memapped so I don't need special > processing. But if an uncompressed niigz file does not fit in memory, it > would be good to still be able to process it online. I have code for that > but it is very specific to my usage. Are you using something like the slicing functionality in nibabel? http://nipy.org/nibabel/images_and_memory.html#saving-time-and-memory Cheers, Matthew From abraham.alexandre at gmail.com Mon Aug 31 13:44:37 2015 From: abraham.alexandre at gmail.com (Alexandre ABRAHAM) Date: Mon, 31 Aug 2015 13:44:37 +0200 Subject: [Neuroimaging] Should we prefer nii.gz or nii? In-Reply-To: References: Message-ID: > > Are you using something like the slicing functionality in nibabel? > No, custom code because I didn't know about this. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.gorgolewski at gmail.com Mon Aug 31 14:48:09 2015 From: krzysztof.gorgolewski at gmail.com (Chris Filo Gorgolewski) Date: Mon, 31 Aug 2015 20:48:09 +0800 Subject: [Neuroimaging] Should we prefer nii.gz or nii? In-Reply-To: References: Message-ID: On Mon, Aug 31, 2015 at 3:59 PM, Matthew Brett wrote: > http://nipy.org/nibabel/images_and_memory.html#saving-time-and-memory Interesting - does this work equally well for .nii as well as .nii.gz? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.roche at gmail.com Mon Aug 31 16:05:58 2015 From: alexis.roche at gmail.com (Alexis Roche) Date: Mon, 31 Aug 2015 16:05:58 +0200 Subject: [Neuroimaging] 3d registration for data fusion in material science In-Reply-To: References: <03955F518517BD4DB8C6698E5ADAEC2A20C77D@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C7FB@EXDAG0-B1.intra.cea.fr> <03955F518517BD4DB8C6698E5ADAEC2A20C86F@EXDAG0-B1.intra.cea.fr> Message-ID: Hi Ben, Updated examples can be found here: https://github.com/nipy/nireg/tree/master/examples At the moment, you will be able to do functional/anatomical rigid registration using nireg (see code sketch above), but it doesn't implement nonrigid registration yet, so it's not recommended for whole-brain subject-atlas realignment at the moment. # Basic structural / functional rigid registration using nireg import nibabel as nb import nireg as nr fun = nb.load('some_functional_image.nii') anat = nb.load('some_T1w_image.nii') R = nr.HistogramRegistration(fun, anat) T = R.optimize('rigid') fun_t = nr.resample(fun, T.inv(), reference=anat) nb.save(funt_t, 'resampled_functional_image.nii') Alexis On Mon, Aug 24, 2015 at 12:17 AM, Ben Cipollini wrote: > Alexis, > > I'm also interested in having this demo. Is this the right code-path to do > functional/structural alignment within a subject as well as aligning > subject and atlas data? > > Thanks, > Ben > > On Fri, Aug 21, 2015 at 9:57 AM, Alexis Roche > wrote: > >> Hi, >> >> I am realizing that the following example script is outdated as it still >> relies on importing nipy: >> >> https://github.com/nipy/nireg/blob/master/examples/affine_registration.py >> >> I will submit an update in a few days. The registration code was >> previously part of the nipy package, which we have recently decided to >> split into several standalone packages, including nireg. The idea is that >> nireg only needs nibabel to run (in addition to the standard numpy/scipy >> packages). >> >> >> > - how to convert a numpy array to nipy-like image ? >> >> This is done using nibabel, see in particular the Nifti1Image class. >> >> > - should the two images have the same size ? >> >> No. >> >> > - the version of nipy that I should use ? >> >> As mentioned above, the latest version of the code does not require nipy. >> >> I will let you know when I push an up-to-date version of the affine >> registration example script. >> >> Best, >> >> Alexis >> >> >> > >> > >> > >> > >> > >> > thank you, really, for your attention, this is kind. >> > >> > >> > >> > Gael >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret= >> cea.fr at python.org] De la part de Alexis Roche >> > Envoy? : vendredi 21 ao?t 2015 13:04 >> > >> > >> > ? : Neuroimaging analysis in Python >> > Objet : Re: [Neuroimaging] 3d registration for data fusion in material >> science >> > >> > >> > >> > Hi Gael, >> > >> > Beside the stuff in dipy that Elef mentioned, there is another brain >> image registration package that has slowly developed over the years, and >> could be useful to you (although it still crucially lacks documentation): >> > >> > https://github.com/nipy/nireg >> > >> > >> > >> > This is rigid/affine registration only for the time being and has a BSD >> license too. >> > >> > >> > >> > Best, >> > >> > Alexis >> > >> > >> > >> > On Fri, Aug 21, 2015 at 9:57 AM, GORET Gael 246279 >> wrote: >> > >> > Hi all, >> > >> > >> > >> > Thanks for your quick replies, >> > >> > This project is just starting, and there is not too much materials ? >> > >> > However, to answer your questions, I just have created a public repo on >> my github account : >> > >> > >> > >> > https://github.com/ggoret/MUDRA >> > >> > >> > >> > - In /doc, I have placed a summary (a pdf slideshow) of the >> project containing some pictures (and info on instruments) >> > >> > >> > >> > - In /examples I have put two data volumes (npy binary file >> format) the kind of data I need to register. >> > >> > >> > >> > - In /mudra a first (naive) try using the Fourier shell >> correlation as metric >> > >> > And you can also find >> > >> > - a Cython wrapping of malik and perona?s algorithms >> implementation working (pretty quickly) on 3D Volumes : >> > >> > o /mudra/extensions/non_linear_filtering.pyx >> > >> > >> > >> > - In /scripts you will find mainly converters simplifying I/O >> > >> > - In /tools 3 very nice visualization tools based on VTK (not >> mayavi) working as standalone (npy input) : >> > >> > o elevation.py -> 2d image to 3d landscape >> > >> > o plan_interpolator.py -> 2d slicing of volume + isosurface rendering >> for given seeds >> > >> > o scalar_field.py -> volume rendering (color and opacity gradient) >> > >> > >> > >> > Thanks in advance for your advices >> > >> > >> > >> > Cheers, >> > >> > >> > >> > Gael >> > >> > >> > >> > De : Neuroimaging [mailto:neuroimaging-bounces+gael.goret= >> cea.fr at python.org] De la part de Eleftherios Garyfallidis >> > Envoy? : jeudi 20 ao?t 2015 16:35 >> > ? : Neuroimaging analysis in Python >> > Objet : Re: [Neuroimaging] 3d registration for data fusion in material >> science >> > >> > >> > >> > Hi Gael, >> > >> > >> > >> > Sounds exciting. There is no restriction to use our tools in other >> libraries or domains. >> > >> > Look at these tutorials please (you need dipy development version) >> > >> > >> > >> > >> https://github.com/nipy/dipy/blob/master/doc/examples/affine_registration_3d.py >> > >> > >> https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_2d.py >> > >> > >> https://github.com/nipy/dipy/blob/master/doc/examples/syn_registration_3d.py >> > >> > >> > >> > Do you have a github repo of your project? Do you have any example >> pictures/volumes to show us that you would >> > >> > like to register? >> > >> > >> > >> > Cheers, >> > >> > Eleftherios >> > >> > >> > >> > >> > >> > >> > >> > On Thu, Aug 20, 2015 at 9:31 AM, GORET Gael 246279 >> wrote: >> > >> > Hi everybody, >> > >> > I am a (French) newcomer, working on the development of the data fusion >> of Time-of-Flight Secondary Ion Mass Spectrometer (ToF-SIMS) and X ray >> Nano-Tomography (XuM) data at the CEA (the French state institute for >> energy, high-tech, etc.). >> > >> > In terms of samples, we?re a bit far from the neuro-fields ? Solid >> oxide fuel cell, 3D chips, Si/Li matrix, etc., but in terms of methodology >> I hope we have to share ? my project is to combine a chemical information >> (from ToF-SIMS) with X-ray absorption (given by XuM) for a given volume (at >> nano-scale). I am tackling a python module aiming to the registration of >> 3d datasets. it seems that nipy includes a such possibility (an a lot more >> ?). >> > >> > I?m a computer guy, mostly Pythonist and I wander if you would let me >> transpose your code (mainly the registration part) to my problematic, I >> would be very grateful for this. >> > >> > In this context would you have some advice for me ? >> > >> > I'm looking forward to hearing from you. >> > >> > Gael >> > >> > >> > >> > >> > >> > Dr. Ga?l Goret >> > >> > Chercheur Postdoctoral >> > >> > D?partement des Technologies Silicium >> > >> > Service de Caract?risation des Mat?riaux & Composants >> > >> > Commissariat ? l??nergie atomique et aux ?nergies alternatives >> > >> > MINATEC Campus | 17 rue des martyrs | F-38054 Grenoble Cedex >> > >> > T. +33 (0)4 38 78 49 29 | gael.goret at cea.fr >> > >> > >> > >> > >> > _______________________________________________ >> > Neuroimaging mailing list >> > Neuroimaging at python.org >> > https://mail.python.org/mailman/listinfo/neuroimaging >> > >> > >> > >> > >> > _______________________________________________ >> > Neuroimaging mailing list >> > Neuroimaging at python.org >> > https://mail.python.org/mailman/listinfo/neuroimaging >> > >> > >> > >> > >> > -- >> > >> > Lead Clinical Research >> > Advanced Clinical Imaging Technology >> > Siemens/CHUV/EPFL >> > 1015 Lausanne, Switzerland >> > Phone: +41 21 545 9972 >> > https://sites.google.com/site/alexisroche >> > >> > >> > _______________________________________________ >> > Neuroimaging mailing list >> > Neuroimaging at python.org >> > https://mail.python.org/mailman/listinfo/neuroimaging >> > >> >> >> >> -- >> Lead Clinical Research >> Advanced Clinical Imaging Technology >> Siemens/CHUV/EPFL >> 1015 Lausanne, Switzerland >> Phone: +41 21 545 9972 >> https://sites.google.com/site/alexisroche >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -- Lead Clinical Research Advanced Clinical Imaging Technology Siemens/CHUV/EPFL 1015 Lausanne, Switzerland Phone: +41 21 545 9972 https://sites.google.com/site/alexisroche -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwaskom at stanford.edu Mon Aug 31 22:04:37 2015 From: mwaskom at stanford.edu (Michael Waskom) Date: Mon, 31 Aug 2015 13:04:37 -0700 Subject: [Neuroimaging] Should we prefer nii.gz or nii? In-Reply-To: References: Message-ID: In a little informal testing, indexing the dataobj appears a lot faster than loading the data from a gzip file. Cool trick! On Mon, Aug 31, 2015 at 5:48 AM, Chris Filo Gorgolewski < krzysztof.gorgolewski at gmail.com> wrote: > > On Mon, Aug 31, 2015 at 3:59 PM, Matthew Brett > wrote: > >> http://nipy.org/nibabel/images_and_memory.html#saving-time-and-memory > > > Interesting - does this work equally well for .nii as well as .nii.gz? > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Aug 31 22:52:33 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 31 Aug 2015 21:52:33 +0100 Subject: [Neuroimaging] Should we prefer nii.gz or nii? In-Reply-To: References: Message-ID: On Mon, Aug 31, 2015 at 1:48 PM, Chris Filo Gorgolewski wrote: > > On Mon, Aug 31, 2015 at 3:59 PM, Matthew Brett > wrote: >> >> http://nipy.org/nibabel/images_and_memory.html#saving-time-and-memory > > > Interesting - does this work equally well for .nii as well as .nii.gz? Actually, if you do something like slicing sequential volumes out of a data file, then this won't be well optimized unless you load the file via gzip file object rather than a file name, otherwise the code has to load the gz and seek through it multiple times. We didn't yet get round to making a nice iterator out of the slicing, which would be pretty trivial to do. Cheers, Matthew