Oops, I am in the middle of giving the gcc-4.2.1 package a try. I
hope I am using it correctly - I installed it, and then removed
everything from spkg/installed, and now I am recompiliing by using
"make". Will that rebuild with gcc-4.2.1? It looks like it from what
I can see during compilation.
Many of you are probably already aware of this, but there is an early
alpha release of python 3000 that came out a couple of weeks ago. I
thought that might be worth pointing out now so folks can take a look
and get used to it early. The final release is tentatively scheduled
for late 2008:
htt
Hamptonio wrote:
> Many of you are probably already aware of this, but there is an early
> alpha release of python 3000 that came out a couple of weeks ago. I
> thought that might be worth pointing out now so folks can take a look
> and get used to it early. The final release is tentatively sche
On Sep 11, 2:07 pm, Hamptonio <[EMAIL PROTECTED]> wrote:
> Oops, I am in the middle of giving the gcc-4.2.1 package a try. I
> hope I am using it correctly - I installed it, and then removed
> everything from spkg/installed, and now I am recompiliing by using
> "make". Will that rebuild with g
On Sep 11, 2007, at 8:59 AM, Jaap Spies wrote:
>
> Hamptonio wrote:
>> Many of you are probably already aware of this, but there is an early
>> alpha release of python 3000 that came out a couple of weeks ago. I
>> thought that might be worth pointing out now so folks can take a look
>> and get
On Sep 11, 3:09 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Sep 11, 2:07 pm, Hamptonio <[EMAIL PROTECTED]> wrote:
>
Sorry, but this is slightly wrong but causes bad consequences:
>
> LD_LIBRARY_PATH="$SAGE_ROOT/local/lib/64:$SAGE_ROOT/local/lib/:
> $LD_LIBRARY_PATH" && export LD_L
On Sep 11, 3:11 pm, David Harvey <[EMAIL PROTECTED]> wrote:
> On Sep 11, 2007, at 8:59 AM, Jaap Spies wrote:
>
>
>
>
>
> > Hamptonio wrote:
> >> Many of you are probably already aware of this, but there is an early
> >> alpha release of python 3000 that came out a couple of weeks ago. I
> >> th
> The fix shouldn't be obvious
Logic all wrong, the fix is obvious and I meant to write that, it is
"print string" no longer working, but now we need print(string)
Anyway, the problem now is in distutils:
setup(name="gdmodule", version=this_version,
description="GD Package",
long_desc
> object : SyntaxError('invalid syntax', ('/tmp/Work2/sage-2.8.4-
> python3k/local/lib/python/distutils/core.py', 113, 31, 'except
> DistutilsSetupError, msg:\n'))
> type: SyntaxError
> refcount: 4
> address : 0x9594e0
> lost sys.stderr
> [4701 refs]
> Failure to build gdmodule
I think "
On 9/10/07, mabshoff <[EMAIL PROTECTED]> wrote:
> The 2.9 milestone seems to be very optimistic, especially without
> some concentrated effort to close a lot of tickets, i.e. a bug day.
> There are several possible days, whether we make this official or
> not. I would prefer the 20th or the 22nd S
On Tuesday 11 September 2007, William Stein wrote:
> On 9/10/07, mabshoff <[EMAIL PROTECTED]>
wrote:
> > The 2.9 milestone seems to be very optimistic, especially without
> > some concentrated effort to close a lot of tickets, i.e. a bug day.
> > There are several possible days, whether we make t
mabshoff wrote:
>
> supply fixes upstream if we decide to do so. Overall we have plenty of
> time for the switch because 2.x will be maintained in parallel with
> 3.x for at least two years. And because we build from sources we can
> pretty much switch any time we want. I would be willing to mai
Either of the 20th or 21st works for me, but not the 22nd.
On Sep 11, 9:08 am, Martin Albrecht <[EMAIL PROTECTED]>
wrote:
> On Tuesday 11 September 2007, William Stein wrote:
>
> > On 9/10/07, mabshoff <[EMAIL PROTECTED]>
> wrote:
> > > The 2.9 milestone seems to be very optimistic, especially wi
On 9/11/07, William Stein <[EMAIL PROTECTED]> wrote:
>
> On 9/9/07, Dan Christensen <[EMAIL PROTECTED]> wrote:
> > But "sage -t" reports lots of errors, and spent an hour or two in
> >
> > sage -t devel/doc-2.8.4.1/ref/sage.misc.trace.tex
> >
> > before I killed it. If these errors are surpris
On Sep 11, 2007, at 6:11 AM, David Harvey wrote:
> On Sep 11, 2007, at 8:59 AM, Jaap Spies wrote:
>
>>
>> Hamptonio wrote:
>>> Many of you are probably already aware of this, but there is an
>>> early
>>> alpha release of python 3000 that came out a couple of weeks ago. I
>>> thought that migh
On Sep 11, 2007, at 2:51 PM, Robert Bradshaw wrote:
>> What I'm more worried about is cython compatibility, especially if
>> python internals have changed a lot.
>
> Me too... It looks like 2.x is going to be around for a while though,
> so we'll hopefully have time to transition. I'm not lookin
David Harvey wrote:
>
> On Sep 11, 2007, at 2:51 PM, Robert Bradshaw wrote:
>
>>> What I'm more worried about is cython compatibility, especially if
>>> python internals have changed a lot.
>> Me too... It looks like 2.x is going to be around for a while though,
>> so we'll hopefully have time t
On Sep 10, 2007, at 5:25 PM, mabshoff wrote:
> On Sep 10, 4:17 pm, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote:
>> On Monday 10 September 2007 18:21, Pablo De Napoli wrote:
>>
>>> I could not read your modification to my patch since you've uploaded
>>> that as an hg bundle. I think that for trac t
On Sep 10, 2007, at 6:00 PM, Joel B. Mohler wrote:
> On Monday 10 September 2007 18:15, David Harvey wrote:
>>> The binomial function then gets a prefix something like:
>>>
>>> try:
>>> call_fast_integer_function( x, m, _binomial_raw )
>>> except CoercionError:
>>> # compute binomial sl
On 9/11/07, Jaap Spies <[EMAIL PROTECTED]> wrote:
> > Well I thought about this a bit more, and now I'm starting to think
> > it's not going to be *too* bad. There's a lot of existing C code out
> > there that uses the Python C API, and I doubt that python 3000 is
> > going to totally break all th
On 9/11/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> > I would say that bundles are better than a number of patches that have
> > to be applied manually one after the other. It is more painful to
> > learn how to use bundles (I can tell because I still am not 100% on
> > the finer points of me
On Sep 11, 2007, at 1:18 PM, William Stein wrote:
>
> On 9/11/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>>> I would say that bundles are better than a number of patches that
>>> have
>>> to be applied manually one after the other. It is more painful to
>>> learn how to use bundles (I can t
On 9/11/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> > I very often do this:
> >
> > 1. Apply the bundle to some branch of my repository, and merge it in.
> > But I *do not* check in the merge.
> >
> > 2. I browse the changes, build them, try them out, etc.
> >
> > 3. If I like the result I ch
On 9/11/07, William Stein <[EMAIL PROTECTED]> wrote:
> > > 3. If I like the result I check it in. If not, I just do
> > > hg_sage.rollback()
> > > hg_sage.revert('--all')
> > > and it is as if I never applied the bundle.
> >
> > Me too. It would be nice to be able to browse "into" bundl
On Tuesday 11 September 2007 16:30, William Stein wrote:
> > We should check first with the trac project / mailing list to see what
> > new tricks they have up their sleeve at this point . They must get
> > this question all the time...
>
> By trac I actually mean the Mercurial project.Thoug
I don't know why I haven't seen this before:
hg_sage.inspect("...", options="-p")
where ... can be the path / url of a patch / bundle / repository. It would
seem that if there's a mercurial widget for trac, this feature may be added
rather easily (if nonexistant).
On Tue, 11 Sep 2007, Will
On 9/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I don't know why I haven't seen this before:
>
> hg_sage.inspect("...", options="-p")
>
> where ... can be the path / url of a patch / bundle / repository. It would
> seem that if there's a mercurial widget for trac, this feature may be
On Tue, 11 Sep 2007, William Stein wrote:
>
> On 9/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> I don't know why I haven't seen this before:
>>
>> hg_sage.inspect("...", options="-p")
>>
>> where ... can be the path / url of a patch / bundle / repository. It would
>> seem that if t
On Sep 11, 2007, at 3:20 PM, [EMAIL PROTECTED] wrote:
> On Tue, 11 Sep 2007, William Stein wrote:
>
>>
>> On 9/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> wrote:
>>> I don't know why I haven't seen this before:
>>>
>>> hg_sage.inspect("...", options="-p")
>>>
>>> where ... can be the path /
On 9/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Sep 2007, William Stein wrote:
> >
> > On 9/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> I don't know why I haven't seen this before:
> >>
> >> hg_sage.inspect("...", options="-p")
> >>
> >> where ... can be the path
On Tue, 11 Sep 2007, Robert Bradshaw wrote:
>
> Nice. One issue is that it seems it only operates within the context
> of a given repository, i.e. I can't inspect random .hg files. Does
> anyone know whether this is a limitation of inspect, or of the .hg
> bundle itself?
According to the docs, an
On Sep 11, 2007, at 3:59 PM, [EMAIL PROTECTED] wrote:
> On Tue, 11 Sep 2007, Robert Bradshaw wrote:
>>
>> Nice. One issue is that it seems it only operates within the context
>> of a given repository, i.e. I can't inspect random .hg files. Does
>> anyone know whether this is a limitation of inspe
32 matches
Mail list logo
