On Feb 22, 12:45 pm, Eviatar wrote:
> For some reason I cannot post on the other topic, so I made another
> one. This way it will also be more visible.
>
> Some people were wondering about where to use imports for maximum
> efficiency, how to do lazy imports, etc. I found this guide that has
> all
Hi,
I would like to see a section on "rebasing patches" with mercurial
queues, in the Developer's Manual. It is a frequent task to rebase a
patch for a new version of Sage. I myself do this one way, but I am
not sure if I am doing it the right way. My way is simply:
1. hg qpop -a
2. upgrade Sage.
On Mon, Feb 21, 2011 at 8:26 PM, Eviatar wrote:
> Importing in a loop is definitely not a good idea.
Unless the loop is rarely executed...
> I found this great guide about Python performance, including
> information about importing, lazy imports, and other issues:
> http://wiki.python.org/moin/P
I agree with the second point. This information is useful.
On Feb 21, 10:07 pm, "D. S. McNeil" wrote:
> (1) I just started playing with this stuff, and found queues much
> nicer than cloning; it's worth It might be good to add a few
> explanations to the page of what to do in common-screwup cas
(1) I just started playing with this stuff, and found queues much
nicer than cloning; it's worth It might be good to add a few
explanations to the page of what to do in common-screwup cases (at
least for me): e.g. unapplying everything (even though there are
uncommitted changes), undoing an accid
For some reason I cannot post on the other topic, so I made another
one. This way it will also be more visible.
Some people were wondering about where to use imports for maximum
efficiency, how to do lazy imports, etc. I found this guide that has
all that information and more:
http://wiki.python.
Importing in a loop is definitely not a good idea.
I found this great guide about Python performance, including
information about importing, lazy imports, and other issues:
http://wiki.python.org/moin/PythonSpeed/PerformanceTips#Import_Statement_Overhead
Maybe it should be (at least partly) added
Importing inside a loop is bad practice; there is overhead. I found
this, which is also a great guide to Python performance in general:
http://wiki.python.org/moin/PythonSpeed/PerformanceTips#Import_Statement_Overhead.
Perhaps it could be added to the docs? I might do it when I have time.
--
To p
On Mon, Feb 21, 2011 at 1:40 PM, Nils Bruin wrote:
> On Feb 21, 10:31 am, Robert Bradshaw
> wrote:
>> k[x,y], k[x,z], k[y,z] all coerce to k[x,y,z], but there some overhead
>> due to the extra object creation (assuming one needed to coerce back
>> into the larger ring). This, and creation of the
On Feb 21, 10:31 am, Robert Bradshaw
wrote:
> k[x,y], k[x,z], k[y,z] all coerce to k[x,y,z], but there some overhead
> due to the extra object creation (assuming one needed to coerce back
> into the larger ring). This, and creation of the new ring, is probably
> still pretty cheap.
The problem I
On Monday, February 21, 2011 8:27:28 PM UTC, François wrote:
>
> > The problem is when configure calls
> >
> > /export/home/drkirkby/sage-4.6.2.rc0/spkg/build/cddlib-094f.p8/src/
> > missing --run automake-1.11 --gnu
>
> Just a quick question Volker. Is this call always happening and
> no
Thanks, everybody, for the great suggestions - this is just what I
hoped to see.
I'm going to still wait a few days before starting, so feel free to
pile on if you would like to add to the discussion.
Rob
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from
On Feb 21, 2:29 pm, Volker Braun wrote:
> I'm all in favor of updating jmol, but I don't see the plan here. Do you
> want to break out jmol from the sagenb spkg into a separate spkg? Or should
> we (i.e. the sagenb maintainer) rather make a new sagenb release with the
> updated jmol.
I think th
On Feb 22, 4:00 am, Volker Braun wrote:
> The problem is when configure calls
>
> /export/home/drkirkby/sage-4.6.2.rc0/spkg/build/cddlib-094f.p8/src/
> missing --run automake-1.11 --gnu
>
> if automake were not installed, then "missing" would emulate it. This
> means that it would touch the Makefi
On Feb 21, 11:24 am, kcrisman wrote:
> Some of the
> issue might be that the developer guide isn't explicit enough about
> how to import things like this?
+1
Like KDC, I never know whether to import at the top of a module,
inside a method, inside a loop,..., even though I know the various
poss
I'm all in favor of updating jmol, but I don't see the plan here. Do you
want to break out jmol from the sagenb spkg into a separate spkg? Or should
we (i.e. the sagenb maintainer) rather make a new sagenb release with the
updated jmol.
Volker
--
To post to this group, send an email to sage-
On Monday, February 21, 2011, Robert Bradshaw
wrote:
> On Mon, Feb 21, 2011 at 2:24 AM, David Kirkby wrote:
>> On 21 February 2011 06:20, William Stein wrote:
>>> There are many (important) potential users who do not use Sage at all
>>> just because the startup time is so bad. It's really unf
On Feb 21, 1:21 pm, Robert Bradshaw
wrote:
> On Mon, Feb 21, 2011 at 2:24 AM, David Kirkby wrote:
> > On 21 February 2011 06:20, William Stein wrote:
> >> There are many (important) potential users who do not use Sage at all
> >> just because the startup time is so bad. It's really unfortun
+1 to returning elements of the basering in the univariate case. If
anything, the multivariate case should be changed.
On Sun, Feb 20, 2011 at 9:56 AM, John Cremona wrote:
> One difference is that in the multivariable case, having the return
> value in the ring with fewer variables would require
On Mon, Feb 21, 2011 at 2:24 AM, David Kirkby wrote:
> On 21 February 2011 06:20, William Stein wrote:
>> There are many (important) potential users who do not use Sage at all
>> just because the startup time is so bad. It's really unfortunate
>> how much I let the startup time of Sage slip ov
On Mon, Feb 21, 2011 at 8:37 AM, kcrisman wrote:
>
>
> On Feb 21, 2:00 am, Eviatar wrote:
>> I've noticed this too. I wonder if they purposely implemented Sage
>> syntax or if it's just a very comprehensive parser.
>
> I think the goal is to understand any natural syntax for many
> questions, and
I used the developer's guide to get started with Sage about a year
ago, and I still refer back to it from time to time. I'm
enthusiastically in support of improving it!
Pros for mercurial queues:
* quicker to get started
* easier to understand (for some)
* easy to transition from just reviewin
On Feb 21, 2:00 am, Eviatar wrote:
> I've noticed this too. I wonder if they purposely implemented Sage
> syntax or if it's just a very comprehensive parser.
I think the goal is to understand any natural syntax for many
questions, and certainly this syntax is relatively unambiguous, and
pretty
On Feb 21, 5:47 am, David Kirkby wrote:
> On 21 February 2011 10:36, Keshav Kini wrote:
>
> > I also wonder why the development guide recommends that we use
> > mercurial from inside a Sage session. It seems considerably more
> > tedious than just using it from the command line. Is there some
>
Thought I would pass this warning on to people. The Jmol community
has found that the old version of Jmol normally packaged with SAGE is
unlikely to work in most webkit browsers (especially on MacOS) very
soon. In the Jmol community we have already seen this and have a
fix. It requires
The problem is when configure calls
/export/home/drkirkby/sage-4.6.2.rc0/spkg/build/cddlib-094f.p8/src/
missing --run automake-1.11 --gnu
if automake were not installed, then "missing" would emulate it. This
means that it would touch the Makefile.in's, as if automake would have
run.
Since you ha
Hello everybody !!!
A colleague of mine just forwarded a CFP about the "2011 IEEE
INTERNATIONAL WORKSHOP ON OPENSOURCE SOFTWARE FOR SCIENTIFIC
COMPUTATION!"
With such a title, they're basically begging for a talk about Sage.. I
thought it'd be sensible to drop a line about it on this group just i
On 21 February 2011 10:36, Keshav Kini wrote:
> I also wonder why the development guide recommends that we use
> mercurial from inside a Sage session. It seems considerably more
> tedious than just using it from the command line. Is there some
> advantage I'm not seeing?
>
> -Keshav
I would say
> > On 2011-02-21 02:19, David Kirkby wrote:
> > > /export/home/drkirkby/sage-4.6.2.rc0/spkg/build/cddlib-094f.p8/src/miss
> > > in g --run automake-1.11 --gnu
> > > sh: line 1: autoconf: not found
> > > automake-1.11: autoconf failed with exit status: 127
> > > make: *** [Makefile.in] Error 1
> >
On Feb 21, 4:45 pm, "Johan S. R. Nielsen"
wrote:
> I'm _only_ using queues at the moment. As far as I can see, clones are
> neat if you have "projects" of patches. However, the beginner will not
> usually have this but only a few scattered fixes here and there and
> patches for review, with none o
On 21 February 2011 06:20, William Stein wrote:
> There are many (important) potential users who do not use Sage at all
> just because the startup time is so bad. It's really unfortunate
> how much I let the startup time of Sage slip over the years. Sorry.
> William Stein
I feel very sorry f
> On 2011-02-21 02:19, David Kirkby wrote:
> > /export/home/drkirkby/sage-4.6.2.rc0/spkg/build/cddlib-094f.p8/src/missin
> > g --run automake-1.11 --gnu
> > sh: line 1: autoconf: not found
> > automake-1.11: autoconf failed with exit status: 127
> > make: *** [Makefile.in] Error 1
> > Error buildin
On 2011-02-21 02:19, David Kirkby wrote:
> /export/home/drkirkby/sage-4.6.2.rc0/spkg/build/cddlib-094f.p8/src/missing
> --run automake-1.11 --gnu
> sh: line 1: autoconf: not found
> automake-1.11: autoconf failed with exit status: 127
> make: *** [Makefile.in] Error 1
> Error building cddlib
>
> C
Hi David,
On Mon, Feb 21, 2011 at 1:53 AM, Dr. David Kirkby
wrote:
> That patch would seem sensible to me,
See ticket #10811 for an updated Makefile:
http://trac.sagemath.org/sage_trac/ticket/10811
> as long as building the pdf docs
> remade the HTML files with the links in.
Here is what I u
On Feb 21, 2:27 am, Rob Beezer wrote:
> I'm inclined to update the "Walking Through the Development Process"
> section of the Developer Guide.
>
> I've had some feedback (in-person) and have seen a few thoughtful
> comments in various places in sage-devel. Other than mentioning new
> features (li
On Feb 21, 2:20 pm, William Stein wrote:
> There are many (important) potential users who do not use Sage at all
> just because the startup time is so bad. It's really unfortunate
> how much I let the startup time of Sage slip over the years. Sorry.
I see that Jeroen has relaxed the startup t
36 matches
Mail list logo
