Hi all,
below is the full text of the announcement, which has also been posted here:
http://wiki.sagemath.org/days8
Many thanks to Enthought for the generous support they've offered! We
really look forward to this meeting being a great opportunity for
collaboration between the Scipy and Sage te
On Jan 7, 2008 2:30 AM, David Cournapeau <[EMAIL PROTECTED]> wrote:
> > to what the trade-offs are. It mentions "batteries included" binary
> > distributions as one solution without giving any link.
>
> FIY, it seems you can find it here (I have not tried it):
>
> http://qct.sourceforge.net/Mercur
Robert Kern wrote:
> Travis E. Oliphant wrote:
>
>
>> I don't think it is time to move wholesale to something like Mercurial
>> or bzr. I would prefer it if all of the Enthought-hosted projects
>> moved to the (new) system at once, which is not going to happen in the
>> short term (but lon
Did you look at TourtiseHg?
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
David Cournapeau wrote:
[...]
> To be frank, I did not realize that mercurial was that popular (which
> makes it more of an argument than I initially thought: I assumed -
> wrongly it seems - that both had a similar user-base)
David,
One reason that they apparently do not is that mercurial has be
On Jan 7, 2008 1:32 AM, Bill Baxter <[EMAIL PROTECTED]> wrote:
> I've been playing around with Hg on windows for an hour or so now. My
> overall impression is that the installation process isn't quite there
> yet.
>
> The basic binary installer goes very smoothly, and after that I was
> able to op
I also have been playing with Hg on Windows apropos discussions on the
list. I plan to move repositories at my lab to Hg. I second everything
Bill Baxter has said. I plan to use Hg myself and to continue exploring
its use but TortoiseHg is not yet at the level of ease of use that
TortoiseSVN is
>
> > *) After running the binary installer, apparently you're supposed to
> > go edit some .ini file to specify your username. It seems it will
> > work ok even if you don't set your username, but since it is
> > apparently highly recommended, the installer just should ask you as
> > part of the
On Jan 7, 2008 1:49 AM, Rafael Villar Burke <[EMAIL PROTECTED]> wrote:
> David Cournapeau gmail.com> writes:
>
> > The open solaris project documented their choice, too:
> >
> > http://www.opensolaris.org/os/community/tools/scm/history/
> >
> > Contrary to mozilla, solaris is using hg as the main
In numpy book, it says:
fromiter (iter or gen, dtype=None)
but that's not true:
Help on built-in function fromiter in module numpy.core.multiarray:
fromiter(...)
fromiter(iterable, dtype, count=-1)
dtype is required
___
Numpy-discussion mailing l
David Cournapeau gmail.com> writes:
> The open solaris project documented their choice, too:
>
> http://www.opensolaris.org/os/community/tools/scm/history/
>
> Contrary to mozilla, solaris is using hg as the main VCS.
Mozilla will be using mercurial (hg) too, but decided to do the full transit
On Jan 7, 2008 1:32 AM, Bill Baxter <[EMAIL PROTECTED]> wrote:
> I've been playing around with Hg on windows for an hour or so now. My
> overall impression is that the installation process isn't quite there
> yet.
>
> The basic binary installer goes very smoothly, and after that I was
> able to op
I've been playing around with Hg on windows for an hour or so now. My
overall impression is that the installation process isn't quite there
yet.
The basic binary installer goes very smoothly, and after that I was
able to open up a prompt and type hg commands right away. But going
through the tut
Robert Kern wrote:
> Neal Becker wrote:
>> It seems that PyArray_FromAny does not accept a generator?
>>
>> Seems like this would be useful.
>
> It's difficult to do all the magical interpretation that PyArray_FromAny()
> does with a iterator of unknown length. In Python, we have fromiter()
> wh
Bill Baxter wrote:
> On Jan 6, 2008 6:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Bill Baxter wrote:
>>> http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram
>>>
>>> This is a bit puzzling. I understand better merging isn't the only
>>> reason to choose DVCS, but the above page basica
On Jan 6, 2008 6:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> Bill Baxter wrote:
> > http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram
> >
> > This is a bit puzzling. I understand better merging isn't the only
> > reason to choose DVCS, but the above page basically says that
> > Me
David Cournapeau wrote:
> Does good merging only depends on the above ? Martin Pool, one of the
> bzr programmer, wrote this article two years ago:
>
> http://sourcefrog.net/weblog/software/vc/derivatives.html
>
> which I found both enlightening and easy to follow.
My terminology was fuzzy/inc
Robert Kern wrote:
> Bill Baxter wrote:
>
>> http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram
>>
>> This is a bit puzzling. I understand better merging isn't the only
>> reason to choose DVCS, but the above page basically says that
>> Mercurial just uses whatever external merge prog
Bill Baxter wrote:
> http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram
>
> This is a bit puzzling. I understand better merging isn't the only
> reason to choose DVCS, but the above page basically says that
> Mercurial just uses whatever external merge program it can find. So
> the fil
http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram
This is a bit puzzling. I understand better merging isn't the only
reason to choose DVCS, but the above page basically says that
Mercurial just uses whatever external merge program it can find. So
the file-level merging sounds like it
Christopher Barker wrote:
> Robert Kern wrote:
>> Chris Barker wrote:
>>> What if your "objects" were nested sequences, and you wanted to partly
>>> flatten them -- which would you flatten?
>> I'm pretty sure that that is exactly the ambiguity that the depth option
>> resolves. Can you give me an
Travis E. Oliphant wrote:
> I don't think it is time to move wholesale to something like Mercurial
> or bzr. I would prefer it if all of the Enthought-hosted projects
> moved to the (new) system at once, which is not going to happen in the
> short term (but long term of course it's an open q
Robert Kern wrote:
> Chris Barker wrote:
>> What if your "objects" were nested sequences, and you wanted to partly
>> flatten them -- which would you flatten?
>
> I'm pretty sure that that is exactly the ambiguity that the depth option
> resolves. Can you give me an example where it's still ambig
23 matches
Mail list logo
