+1, provided that there is no regression in capability, which appears to not be the case.
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Hi All,
Matt and I were discussing the move from homegrown hosting to
Bitbucket, and I was advocating for going all in: using BitBucket's
issue tracker and wiki, and discontinuing further use of our Trac site
at yt.enzotools.org. Could we get a simple vote going, -1/+1 for using
BitBucket's issue tracker and wiki?
thanks,
J. S.
Hi all,
I'm writing to let you know that we have outgrown our homegrown
mercurial serving (as some of you may have noticed with the
installation errors) and we have moved the yt source code to
BitBucket. Here are the three takeaways:
* You should not have to make any changes for "yt instinfo -u" to
continue working.
* This should fix all outstanding issues with the install script
timing out when downloading yt.
* You can now much more easily contribute changes!
The new source code location is the same as the old source code
location: http://hg.enzotools.org/ . The username on BitBucket is
"yt_analysis". The DNS might take a few hours to get circulated
around, so if it doesn't work just now, it will by tonight or
tomorrow.
To contribute changes you can go here: http://hg.enzotools.org/yt/fork
to get your own version of the yt repository, where you can make
changes and commit, and even notify the main repo when your changes
are ready to push back upstream. We're very excited that this will
enable much greater participation, and I hope that this will lower the
barrier to entry for developing yt! I'm rewriting the developer guide
now, but the short answer to how to make changes has gotten a lot
shorter: just fork the repository and issue a "pull request" when
you're ready to contribute back upstream.
Let us know if this causes any unforeseen problems, and please feel
encouraged to fork and contribute!
Best,
Matt
Hi everyone,
I found out I'm may be a bit busy on Sunday, so I'm moving the hg
server domain right now. There may be downtime for a little while,
but I have "flipped the switch" as it were and redirected our
hg.enzotools.org to the yt_analysis project page. We can move
usernames later if "yt" becomes available.
All the existing paths should still continue to work once the domain
begins resolving correctly to bitbucket. For now it'll just give
bad_httpd_conf until that happens.
I also encourage everyone to "fork" the yt repo for interim changes,
higher-cadence development and experimental features:
https://bitbucket.org/yt_analysis/yt/fork
(this will eventually be available at https://hg.enzotools.org/yt/fork .)
Once you have made a fork, some really cool features become available,
like "pull requests" and fork viewing. For instance, here's a view of
the divergence between my fork and the main yt repo:
https://bitbucket.org/MatthewTurk/yt/compare/default..yt_analysis/yt
where you can see I haven't pulled in Sam's recent changes. There are
incoming and outgoing views of changesets. I'm going to rewrite the
developer guide with more info on how to leverage BitBucket and then
commit it later this weekend.
Anyway, again, things are probably broken now but should clear up in a
few hours.
-Matt
Matt,
> Can I get [+-][01] on going to Bitbucket?
+1.
> yt_analysis
> ytanalysis
> yt_astro
> ytastro
> [other]
Of these, I like ytastro the best, because it's the shortest. Short is good. I'd also go with yt_repo or yt_hg, although that gets a bit repetitive. How about the_real_yt?
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Hi everyone,
There've been lots of problems with the hg server on hg.enzotools.org.
It's time to move from there to somewhere else.
I propose going to Bitbucket. This enables many things: forking,
easier collaboration, pull reports, code review, and so on and so
forth. Additionally, it will eliminate the timeouts that have plagued
the hg.enzotools.org server. Bitbucket allows for domain redirection,
so all the existing paths should continue to work, they will just be
served by a different server.
Can I get [+-][01] on going to Bitbucket?
I'm trying to get us the 'yt' username, but haven't had luck yet. If
the yt username is unavailable as of Sunday night, we'll need a backup
name. I'd like to put this up for a vote:
yt_analysis
ytanalysis
yt_astro
ytastro
[other]
Can I get a vote on that, or any other suggestions? The upshot here
is that we'll have hg.enzotools.org point to the user page for
whatever we end up with (so it will still be
http://hg.enzotools.org/yt/ to get to the yt repo, yt-doc for yt-doc,
etc etc), but we also need a username. So if you go to BitBucket
itself, rather than hg.e.o, you will see
bitbucket.org/[username]/[project] .
In addition, if you are reading this, can you email me off list with
your BitBucket username so that I can add you to the access control
list? For now I think it will be better if we ease ourselves into the
BitBucket workflow and avoid being too free with Pull Requests, and so
I'd like to add people to the write list for whatever repo we end up
with. You can get a BitBucket username simply by logging in with your
Google username, if you like, or create a new one. I'm MatthewTurk,
for what it's worth.
Thanks,
Matt
Hi all,
I was calculating some quantities for a halo list with 32 processors,
and it broke when it tried to calculate derived quantities for small
halos with less than 32 grids within its sphere. I fixed it for enzo
datasets and posted the diff here.
http://paste.enzotools.org/show/1511/
First it broke in the preload function when the grid list is null, and
it tried to get a field list from the first grid. That was easily fixed
by returning data = None. Then I had to modify the mpi_catarray
function to consider a null dataset (len(data) == 0).
I don't like how I modified the preload function because it only applies
for the enzo frontend. Is there another routine that can be modified
that affects all data formats, so this fix can be generalized?
Thanks,
John
Hi,
I was trying to update one of my installs on a kubuntu (10.10) desktop,
which I haven't done since the Cython files started to be generated on
the client's computer.
When I tried to install it, my desktop didn't have "pip" by default.
yt> sudo python setup.py install
Received error on importing Cython:
No module named Cython
Now attempting to install Cython
Traceback (most recent call last):
File "setup.py", line 18, in <module>
import pip
ImportError: No module named pip
But this was easily fixed by a "sudo apt-get install python-pip". I
just wanted to share this if you think pip needs to be auto-installed
also. I don't know if this makes any difference, but this installation
didn't use the install script.
John
> Is this worth
> implementing?
I agree with Jeff - adding new code is not worth it.
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Hi Matt,
What I discovered is that without calling "from yt.mods import *", the class StaticOutput() was not being initialized in yt/data_objects/static_output.py, so the output_type_registry dict was empty in convenience.py. Should this concern us?
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
