Hi everyone
Can someone please review ticket #9976; its patch has been there for
~6 months now.
It fixes a problem with decorators and Sphinx: as it is now, most
decorated functions will get a generic signature in the Sphinx
documentation. Notable examples include most of the plot commands,
e.g.
Hi!
I hope sage-devel is the right place to ask a very basic question on
the coercion model.
sage.structure.parent.Parent has methods register_conversion and
register_coercion. What is the difference between conversion and
coercion? I see that there are different caches for the two. In what
situa
On Mar 31, 2011, at 21:24 , Volker Braun wrote:
> I agree that the number of make -jN threads should be a good deal larger
> than the number of physical cores. Also, make sure that you set
>
> export SAGE_PARALLEL_SPKG_BUILD=yes
>
> or you'll see mostly a slow single-threaded configure followe
So I just made a fresh build of sage and the patching went smoothly.
Not sure what was causing the problem. So far, everything works
great! I also noticed that it did seem to take a long time for the
applets to load, and somehow it seems that the image resolution is not
as good as it was before I
I agree that the number of make -jN threads should be a good deal larger
than the number of physical cores. Also, make sure that you set
export SAGE_PARALLEL_SPKG_BUILD=yes
or you'll see mostly a slow single-threaded configure followed by a
lightning-fast compile phase. This should be really th
On Fri, Apr 1, 2011 at 1:20 PM, kcrisman wrote:
> See (or don't) #11102 and #11103. Now they're creating new tickets,
> not just comments. Hopefully someone can get rid of them.
They're closed as invalid and the corresponding accounts deleted.
> But it
> would be bad to go back to the "email
Hi, all,
I've just upgraded my home system, to a Mac Pro (Dual 6-core Xeon, 24GB
memory), and figured (hoped) I'd see 24 processes hammering away during the
build & test of a Sage release.
Turns out not to happen. For the record, these new cores from Intel sport 2
"threads" each, which act al
See (or don't) #11102 and #11103. Now they're creating new tickets,
not just comments. Hopefully someone can get rid of them. But it
would be bad to go back to the "email William for an account" days...
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from
On Thursday, March 31, 2011 3:09:38 PM UTC-4, kcrisman wrote:
>
> I realize that not everyone will agree on what
> acronyms/cuss words are appropriate for this forum
In the context of programming, I think of WTF mostly as
http://thedailywtf.com. In its own humorous ways, it has a lot to teach
Hi all,
This is to advertise a patch (http://trac.sagemath.org/sage_trac/
ticket/10289) which, unfortunately, is sleeping in Trac without a
reviewer for more than four months.
This patch would be very useful for those who converted from Magma.
Please review!
On Thu, 31 Mar 2011 at 06:08AM -0700, Jonathan wrote:
> If you want to see what is coming down the pike in the next few
> weeks, take a look at the published samples on my test server:
> http:///141.233.197.45:. I could really use some comments on how
> it works.
I'm using Firefox 4.0 on Ubu
I've built Sage 64-bit on OpenSolaris but it crashes at startup. I've run gdb
and find the bit of code that's causing the crash is this.
./devel/sage-main/sage/symbolic/function.cpp
/* "sage/symbolic/function.pyx":109
* raise ValueError, real_fname + " parameter must be call
On Wed, Mar 30, 2011 at 12:17:06AM -0700, Simon King wrote:
> I tested, and found that cpdef'ing does not help (much):
>
> With def:
> sage: R. = QQ['t'][]
> sage: timeit('R.base_ring')
> 625 loops, best of 3: 967 ns per loop
>
> With cpdef:
> sage: R. = QQ['t'][]
> sage: timeit('R.base_ring')
>
On Thu, Mar 31, 2011 at 3:28 PM, Francois Bissey
wrote:
> I'll certainly commiserate with him being busy with his new baby (got a new
> one of my own on Monday, they are demanding little thing, let's not mention
> the students...)
Congratulations!
John
--
To post to this group, send an email t
> On 03/31/11 05:22 PM, Volker Braun wrote:
> >As Dave Kirby remarked,
> >
> > right now it compiles on a couple of gcc releases and essentially no
> > other compiler. And thats hardly a surprise if you look at the code. At
> > the very least the endless compiler warnings need to be looked at /
> >
Thanks guys. I was definitely using hg_sagenb.apply() and not
hg_sagenb.commit(), so I am not sure why it was asking me to commit.
The only difference from what you say Jonathan was that I was applying
the patches from a local directory and not an http:, so I doubt that
makes a difference. I will
On 03/31/11 05:32 PM, jtyard wrote:
Hi Jonathan,
Thanks for your reply. I tried last night to figure out how to patch
my notebook, and I ended up giving up after several hours. I also
couldn't find any documentation for hg_sagenb.apply. After updating
jmol to 1.1.5, I tried to follow the dire
Some things to take into account:
Mike is certainly very busy now. (In the last half hour I have been
receiving alternate emails from him, and from sage-devel about
lcalc!).He is (co-)running the current semester at MSRI on
Arithmetic Statistics (other organisers including me, and William).
H
On 03/31/11 05:22 PM, Volker Braun wrote:
As Dave Kirby remarked,
right now it compiles on a couple of gcc releases and essentially no other
compiler. And thats hardly a surprise if you look at the code. At the very
least the endless compiler warnings need to be looked at / fixed.
Micheal did
On 3/31/11 2:09 PM, kcrisman wrote:
And I agree that we should communicate with the author politely. I was
addressing the Sage developers that use lcalc, and I think that its
allowable to use a more colloquial tone in that case.
I would submit that we should be as polite as possible whenever
> And I agree that we should communicate with the author politely. I was
> addressing the Sage developers that use lcalc, and I think that its
> allowable to use a more colloquial tone in that case.
I would submit that we should be as polite as possible whenever
discussing component pieces of Sag
On Wed, Mar 30, 2011 at 7:52 PM, William Stein wrote:
> There is an easy fix though. The problem was that the default network
> interface got renamed by udev to eth6, but the file
> /etc/network/interfaces only lists eth1-eth4.
> So whoever (?) is maintaining the vmware image should just add a bu
Your description sounds like you are doing a hg_sagenb.commit(), not a
hg_sagenb.apply("http://.patch"). If you just copy
the link to the listed patches as shown above they should work.
That's what I do.
Jonathan
P.S. Great name!
On Mar 31, 11:32 am, jtyard wrote:
> Hi Jonathan,
>
> Thank
On Thursday, March 31, 2011 1:08:35 PM UTC-4, robertwb wrote:
>
> On Thu, Mar 31, 2011 at 9:22 AM, Volker Braun
> wrote:
> > Is anybody working on either removing lcalc or getting its code up to
> > reasonable quality?
>
> Is it not giving you the right answers anymore?
>
In fact, it does not gi
If it would help at all he (Mike R) is in the office 3 doors down from
me right now at MSRI. But I would not like to forward any emails to
him which were not a lot more polite.
John
On Thu, Mar 31, 2011 at 10:08 AM, Robert Bradshaw
wrote:
> On Thu, Mar 31, 2011 at 9:22 AM, Volker Braun wrote:
On Thu, Mar 31, 2011 at 9:22 AM, Volker Braun wrote:
> Is anybody working on either removing lcalc or getting its code up to
> reasonable quality?
Is it not giving you the right answers anymore?
> Does anybody know the upstream author?
Yes, several of us.
> The lcalc spkg
> recently broke on g
Hi Jonathan,
Thanks for your reply. I tried last night to figure out how to patch
my notebook, and I ended up giving up after several hours. I also
couldn't find any documentation for hg_sagenb.apply. After updating
jmol to 1.1.5, I tried to follow the directions at
http://www.sagemath.org/doc
On 2011-03-31 18:22, Volker Braun wrote:
> Is anybody working on either removing lcalc or getting its code up to
> reasonable quality? Does anybody know the upstream author? The lcalc
> spkg recently broke on gcc-4.6 essentially due to this:
>
> #define double(x) (double)(lcalc_to_double(x))
>
>
Is anybody working on either removing lcalc or getting its code up to
reasonable quality? Does anybody know the upstream author? The lcalc spkg
recently broke on gcc-4.6 essentially due to this:
#define double(x) (double)(lcalc_to_double(x))
I mean, WTF? Does anybody believe that you can safel
Jon,
We are sorting this out. Ticket #9238 is the one you want.
The .spkg you used is out-of-date. All the fixes are not in, but if
you follow the patching instructions on #9238 you should get something
that will work cleanly on MacOS + Chrome. FF has been inconsistent,
so we are having troubl
On Mar 28, 2011, at 11:36 AM, Jeroen Demeyer wrote:
> 2) Patches should be made using *hg export tip*, and not hg diff.
Don't forget that you need to use --git if you have touched any binary files.
It may be best to add this to your .hgrc (I think this was mentioned in another
thread recently)
Thank you. Do you have any idea how a Javascript variable could be
passed to Python? Setting a prompt (using html()) is easy enough, as
well as outputting the result using document.write, but of course for
it to be of any use it has to be interpreted by Python.
--
To post to this group, send an e
32 matches
Mail list logo
