[sage-devel] Re: Sage 4.8 build failed: Error: Failed to build Maxima as an ECL library.

Please make sure to follow this part of the instruction: "and including the relevant part of the log file   /files3/home/sahosse/sage/spkg/logs/maxima-5.23.2.p3.log Describe your computer, operating system, etc. " All one can see from your report so far that your Linux kernel is kind of old. We d

[sage-devel] Re: Rework download/extract code in sage-spkg (#12602) needs review

On Mar 2, 4:31 pm, Jeroen Demeyer wrote: > On 2012-03-02 20:26, kcrisman wrote: > > > Does this address the following issue? > > > make > > sage -ihttp://url/of/package-1.2.spkg# an upgrade > > sage -b > > > > sage -f package-1.1 # should just go use, the current package IN spkg/ > > standard,

[sage-devel] Re: sage, gentoo-prefix & lmonade was: log messages

Hi, >> ... (too much) of the work that goes into sage is fixing external packages >> -- that work would be better spent working on the sage library ... Yes, I do share that insight, for quite some time now. It's good to see, that others think alike! Does it concern you that the support mat

Re: [sage-devel] Re: tachyon -- are we building it incorrectly or?

I can verify that tachyon renders using multiple threads on linux. In fact it looks like it uses all available threads by default (!). Rendering the 1000 random platonic solids from William's 3d plot worksheet took 1.07 seconds using 10 Xeon cores. -- Benjamin Jones benjaminfjo...@gmail.com On

[sage-devel] Re: tachyon -- are we building it incorrectly or?

Also, note that tachyon can spend a lot of time pre-processing the scene data (single-threaded) if you have lots of objects. For example, sum(sphere((random(),random(),random()), size=0.1) for i in range(1)).show(viewer='tachyon') is spending all of its time preprocessing. The command line

Re: [sage-devel] Re: Rework download/extract code in sage-spkg (#12602) needs review

On 2012-03-02 20:26, kcrisman wrote: > Does this address the following issue? > > make > sage -i http://url/of/package-1.2.spkg # an upgrade > sage -b > > sage -f package-1.1 # should just go use, the current package IN spkg/ > standard, right? > Unpacked and it is empty/doesn't look like a tar a

[sage-devel] Re: Sage 4.8 build failed: Error: Failed to build Maxima as an ECL library.

The error is because asdf can not see maxima.asd although it's in the current directory. So I added this line before the call to asdf to make maxima: -eval '(push "/files3/home/sahosse/sage/spkg/build/maxima-5.23.2.p3/ src/src/" asdf:*central-registry*)' \ -eval '(asdf:make-build :maxima :type :fa

[sage-devel] Re: tachyon -- are we building it incorrectly or?

>From the spkg-install: # The threaded version of the 0.98 beta doesn't work on OS X. I haven't tried it myself. On Friday, March 2, 2012 11:17:55 AM UTC-8, William wrote: > > I thought that if I rendered a 3d scene using viewer='tachyon', then > it would use the multiple cores of my computer

Re: [sage-devel] tachyon -- are we building it incorrectly or?

On Fri, 02 Mar 2012 12:43:46 William Stein wrote: > On Fri, Mar 2, 2012 at 12:42 PM, Francois Bissey > > wrote: > > On Fri, 02 Mar 2012 11:17:55 William Stein wrote: > >> Hi, > >> > >> I thought that if I rendered a 3d scene using viewer='tachyon', then > >> it would use the multiple cores of my

Re: [sage-devel] tachyon -- are we building it incorrectly or?

On Fri, Mar 2, 2012 at 12:42 PM, Francois Bissey wrote: > On Fri, 02 Mar 2012 11:17:55 William Stein wrote: >> Hi, >> >> I thought that if I rendered a 3d scene using viewer='tachyon', then >> it would use the multiple cores of my computer to render the scene >> more quickly.  However, I was just

Re: [sage-devel] tachyon -- are we building it incorrectly or?

On Fri, 02 Mar 2012 11:17:55 William Stein wrote: > Hi, > > I thought that if I rendered a 3d scene using viewer='tachyon', then > it would use the multiple cores of my computer to render the scene > more quickly. However, I was just rendering a complicated 3d scene > for my class (that takes abo

Re: [sage-devel] Re: sage, gentoo-prefix & lmonade was: log messages

On Fri, 02 Mar 2012 13:41:58 Michael Orlitzky wrote: > On 03/02/12 12:47, William Stein wrote: > > By "Gentoo" do you mean "Gentoo prefix" [1] everywhere in this message? > > Not really. The "Prefix" project is just a way to run portage (the > package manager) out of a non-root directory. So, for

Re: [sage-devel] Re: default ellipse color

Hi, Continuing with this thread, I'm preparing a lecture on 3d graphics today. I only ran into one similar inconsistency/issue! * bezier3d -- the default color is "red", but it should be the same as for all other plots (i.e., that blueish). The documentation also has this line: - ``c

[sage-devel] Re: Natural language interface to sage

Bringing this back to the actual subject of the thread... See http://trac.sagemath.org/sage_trac/ticket/12619 The developer has the following followup too. >>> Login into localhost at port 9000 >>> waiting... EmptyBlock 2 >>> finished handshake. Session id is 9b9c68446cc2caf65e14d5078ac9eedd >

[sage-devel] Re: trac field names -- arrrrr!

On Mar 2, 10:01 am, Michael Orlitzky wrote: > On 03/02/12 03:07, Robert Bradshaw wrote: > > > > > > > > > > > On Tue, Feb 28, 2012 at 5:48 PM, Michael Orlitzky > > wrote: > >> On 02/28/2012 07:33 PM, Keshav Kini wrote: > > >>> It's not much consolation right now, but this will become easier on

[sage-devel] Re: Rework download/extract code in sage-spkg (#12602) needs review

On Mar 2, 11:21 am, Jeroen Demeyer wrote: > The current code in sage-spkg to determine which package to install and > whether to download it is too complicated (and probably buggy). Also get > rid of calls to the newest_version script, allow gzip compression of > .spkg files, get rid of the "dow

[sage-devel] Re: the state of dense linear algebra in Sage

On Mar 2, 2:59 am, Martin Albrecht wrote: > which collects this information. I am not done yet filling it in, but I have > to catch a train now. Meaning: knock yourselves out adding/filling in your > favourite base ring :) Not my favorite base rings, but ones I can comment on. I'm partial to QQ

Re: [sage-devel] Re: sage, gentoo-prefix & lmonade was: log messages

On 03/02/12 12:47, William Stein wrote: > > By "Gentoo" do you mean "Gentoo prefix" [1] everywhere in this message? Not really. The "Prefix" project is just a way to run portage (the package manager) out of a non-root directory. So, for example, you could install the Prefix copy of portage in $HO

Re: [sage-devel] Re: Is Sage a pure Python/Cython library?

On Fri, Mar 2, 2012 at 9:12 AM, daveloeffler wrote: > On Mar 2, 2:48 pm, "Georg S. Weber" > wrote: >> >> But the "no binary objects whatsoever" criticism from Harald is >> justified (due to the mercurial history, even erasing .png files later >> will not help --- the increase in size will last fo

[sage-devel] Re: Is Sage a pure Python/Cython library?

On Friday, March 2, 2012 9:15:08 AM UTC-8, daveloeffler wrote: > > Sorry, that got lost in sending: I meant "I wouldn't want to read > documentation of the Farey symbols module without some diagrams to explain > what was going on". > +1 Sometimes a picture says more than a thousand words ;-) I

Re: [sage-devel] Re: sage, gentoo-prefix & lmonade was: log messages

On Fri, Mar 2, 2012 at 9:32 AM, Michael Orlitzky wrote: > On 03/02/12 11:46, William Stein wrote: >> >> On Mar 2, 2012 1:04 AM, "Robert Bradshaw" > > wrote: >> . >>> >>> I think the vast majority of spkgs should be vanilla upstream, and for >>> those that we do

Re: [sage-devel] Re: sage, gentoo-prefix & lmonade was: log messages

On 03/02/12 11:46, William Stein wrote: > > On Mar 2, 2012 1:04 AM, "Robert Bradshaw" > wrote: > . >> >> I think the vast majority of spkgs should be vanilla upstream, and for >> those that we do patch, they're likely bugfixes that should make their >> way ups

Re: [sage-devel] Sage security

Hi On 2 March 2012 09:03, Robert Bradshaw wrote: > Sage is as secure as bash (+ compilers). If you want to run arbitrary > bash scripts, let other people run their bash scripts, or set up a web > interface for others to running bash scripts, then you should get your > security from another level

[sage-devel] Re: Is Sage a pure Python/Cython library?

On Friday, 2 March 2012 17:12:04 UTC, daveloeffler wrote: > > There are already a couple of images in the documentation of the > "homology" Sage module that nobody has complained about so far. I > don't think this is an issue. I wouldn't want to read documentation of > the > > Sorry, that got

[sage-devel] Re: Is Sage a pure Python/Cython library?

On Mar 2, 2:48 pm, "Georg S. Weber" wrote: > > But the "no binary objects whatsoever" criticism from Harald is > justified (due to the mercurial history, even erasing .png files later > will not help --- the increase in size will last forever), as well as > the question of maintainability. There

Re: [sage-devel] Re: sage, gentoo-prefix & lmonade was: log messages

On Mar 2, 2012 1:04 AM, "Robert Bradshaw" wrote: . > > I think the vast majority of spkgs should be vanilla upstream, and for > those that we do patch, they're likely bugfixes that should make their > way upstream. But that leaves several packages that we still need to > patch (either sage-specifi

[sage-devel] Rework download/extract code in sage-spkg (#12602) needs review

The current code in sage-spkg to determine which package to install and whether to download it is too complicated (and probably buggy). Also get rid of calls to the newest_version script, allow gzip compression of .spkg files, get rid of the "download again" part (why was it needed?). There is one

Re: [sage-devel] Re: the state of dense linear algebra in Sage

On Friday 02 Mar 2012, Simon King wrote: > Hi Martin, > > On 2 Mrz., 11:59, Martin Albrecht > > wrote: > > Meaning: knock yourselves out adding/filling in your > > > > favourite base ring :) > > I added some information on my MeatAxe fork wrapper (comparison with > Magma missing, I'm workin

Re: [sage-devel] Re: git and gerrit

On Fri, Mar 2, 2012 at 1:06 AM, Robert Bradshaw wrote: > Though for a single commit, a rebase is cleaner IMHO than a merge, and > squashing commits improves the signal-to-noise ratio of the history > (and it's nice to be able to squash away stuff like typos). That was my original position, but I

Re: [sage-devel] Re: trac field names -- arrrrr!

On 03/02/12 03:07, Robert Bradshaw wrote: > On Tue, Feb 28, 2012 at 5:48 PM, Michael Orlitzky > wrote: >> On 02/28/2012 07:33 PM, Keshav Kini wrote: >>> >>> >>> It's not much consolation right now, but this will become easier once we >>> switch to git, as branches can be automatically checked for

Re: [sage-devel] Re: Natural language interface to sage

On 03/01/12 23:43, Keshav Kini wrote: > > I don't understand. Why would it be *faster* to do version bumps if > sage-on-gentoo gets into Gentoo proper? Overlays are always more nimble > than the Gentoo tree, as far as I can see. If we're to distribute sage via source, we need some way for users t

[sage-devel] Re: Is Sage a pure Python/Cython library?

Well, as for the original question(s), the answer is "No, the Sage core library is not a pure Python/Cython library, so yes, essentially you can include C/C++ code." --- there are already other examples (I think some code of David Harvey for example). I think formally, the way of the integration

[sage-devel] Re: git and gerrit

Robert Bradshaw writes: > Though for a single commit, a rebase is cleaner IMHO than a merge, The problem with rebasing is that unless you do it manually, the actual commits (i.e. snapshots of the codebase) do not necessarily represent code that anyone has actually looked at. Just because a merge

[sage-devel] Re: Is Sage a pure Python/Cython library?

Martin Raum writes: > At #11709 we have a nice implementation of FareySymbols and apart from some > small changes the current patch is ready for inclusion into Sage. But it is > mostly written in C++. > > Do we accept patches to the Sage library that contain C or C++ code? I > couldn't > find any

[sage-devel] Re: Group collaboration on a branch of Sage

Robert Bradshaw writes: > On Fri, Mar 2, 2012 at 1:45 AM, Keshav Kini wrote: >> For example, if two >> people have branches named trac-n, the script should just do nothing, >> not try to pick the most recently updated one, or look for branch names >> in the comments, or whatever :) > > Or one cou

[sage-devel] Re: Is Sage a pure Python/Cython library?

On Friday, March 2, 2012 12:52:32 PM UTC+1, Martin Raum wrote: > > At #11709 ... > I don't know, but I remember that there shouldn't be any images stored in the documentation, due to the increase in size. Is this rule still effective? Of course, including the plot commands with saving to a tem

[sage-devel] Re: the state of dense linear algebra in Sage

Hi Martin, On 2 Mrz., 11:59, Martin Albrecht wrote: > Meaning: knock yourselves out adding/filling in your > favourite base ring :) I added some information on my MeatAxe fork wrapper (comparison with Magma missing, I'm working on it now), even though #12103 is still in need of review (hint hin

Re: [sage-devel] the state of dense linear algebra in Sage

On Fri, Mar 2, 2012 at 11:59, Martin Albrecht wrote: > Hi there, > > I am going to give a talk about Sage at the ECrypt PhD Summer School on Tools > >  https://www.cosic.esat.kuleuven.be/ecrypt/courses/mykonos12/index.shtml > > For that I tried to compile an overview on where we stand in terms of

[sage-devel] Is Sage a pure Python/Cython library?

At #11709 we have a nice implementation of FareySymbols and apart from some small changes the current patch is ready for inclusion into Sage. But it is mostly written in C++. Do we accept patches to the Sage library that contain C or C++ code? I couldn't find anything about this in the developm

Re: [sage-devel] Re: Group collaboration on a branch of Sage

On Fri, Mar 2, 2012 at 2:06 AM, Martin Albrecht wrote: > Hi, > > On Friday 02 Mar 2012, Keshav Kini wrote: > [snip] >> > There are some things github does better, though.  I can't recall them >> > off the top of my head, though. >> >> I find github to be a lot faster than bitbucket, for some reaso

[sage-devel] Upstream bugs

Hi, how can I have a list of upstream bugs which affect sage? There is no custom query for that on trac, and looking for 'upstream' in the keywords didn't turn anything up. Searching 'upstream' in the description gets 53 tickets, but that is too broad, as it counts (I'm only interested in those

Re: [sage-devel] Re: Group collaboration on a branch of Sage

On Fri, Mar 2, 2012 at 1:45 AM, Keshav Kini wrote: > Robert Bradshaw writes: >> On Fri, Mar 2, 2012 at 1:06 AM, Keshav Kini wrote: >>> I do notice that David Roe's description for Review Days includes >>> something like a feature request for better code review procedures, such >>> as line commen

[sage-devel] the state of dense linear algebra in Sage

Hi there, I am going to give a talk about Sage at the ECrypt PhD Summer School on Tools https://www.cosic.esat.kuleuven.be/ecrypt/courses/mykonos12/index.shtml For that I tried to compile an overview on where we stand in terms of linear algebra. I figured this should be of more general inter

Re: [sage-devel] Re: Unifying Command line options

On Fri, Mar 2, 2012 at 1:27 AM, Jason Grout wrote: > On 3/2/12 2:55 AM, Robert Bradshaw wrote: >> >> I think sage foo ... should default to running bin/sage-foo (in the >> sage environment) if it exists, and treat foo as a file otherwise. >> Virtually no argument parsing (aside from understanding

Re: [sage-devel] Re: Just *when* are objects deallocated ?

My God !! How could I have found that without you ?? Thank you so much !!! :-) There is a patch available at this address [1] to fix the problem. One of the two references was nto even used nor useful, so the patch is 10 lines long and avoids this cyclic reference --> the objects are now d

Re: [sage-devel] Re: Group collaboration on a branch of Sage

Hi, On Friday 02 Mar 2012, Keshav Kini wrote: [snip] > > There are some things github does better, though. I can't recall them > > off the top of my head, though. > > I find github to be a lot faster than bitbucket, for some reason, though > maybe it's some consequence of being in Singapore. >

[sage-devel] Re: Unifying Command line options

Jason Grout writes: > -1 to magic parsing of 'sage foo'. What if sage-foo was later added > to sage? Then things would break for people. I agree. This works for `git` only because `git ` is not valid usage. > I like the idea of 'sage run foo' to run foo. How would that be added > to a script

[sage-devel] Re: Group collaboration on a branch of Sage

Robert Bradshaw writes: > On Fri, Mar 2, 2012 at 1:06 AM, Keshav Kini wrote: >> I do notice that David Roe's description for Review Days includes >> something like a feature request for better code review procedures, such >> as line comments. Github's tracker can do that without any further >> co

Re: [sage-devel] Re: Just *when* are objects deallocated ?

Dear Nathann, You can have a look at trac tickets #715, #11521, #12313 and #12357 where Simon and I had a look at this kind of problems. Maybe you can draw some inspiration from them. Best, Le jeudi 1 mars 2012 20:57:05 UTC+1, Nathann Cohen a écrit : > > Thank you for your answers ! I forward t

[sage-devel] Re: Just *when* are objects deallocated ?

On 3/2/12 3:24 AM, Nathann Cohen wrote: In general (not just Cython) a Python object is deallocated as soon as it's no longer referenced (via the Py_DECREF macro), which is often as soon as they fall out of scope. The garbage collector is used to reclaim cyclically-referenced objects. Note also t

[sage-devel] Re: Unifying Command line options

On 3/2/12 2:55 AM, Robert Bradshaw wrote: I think sage foo ... should default to running bin/sage-foo (in the sage environment) if it exists, and treat foo as a file otherwise. Virtually no argument parsing (aside from understanding --) would be involved here, and the decision to use bash/python/

Re: [sage-devel] Re: Just *when* are objects deallocated ?

> In general (not just Cython) a Python object is deallocated as soon as > it's no longer referenced (via the Py_DECREF macro), which is often as > soon as they fall out of scope. The garbage collector is used to > reclaim cyclically-referenced objects. Note also that ipython (used at > the Sage pr

Re: [sage-devel] Re: Group collaboration on a branch of Sage

On Fri, Mar 2, 2012 at 1:06 AM, Keshav Kini wrote: > Robert Bradshaw writes: >> On Wed, Feb 29, 2012 at 4:51 PM, Keshav Kini wrote: >>> William Stein writes: It's difficult for me because they are patch in hg format, but I can't export a patch out of git in hg format.  It's possible t

[sage-devel] Re: trac field names -- arrrrr!

Robert Bradshaw writes: > On Tue, Feb 28, 2012 at 5:48 PM, Michael Orlitzky > wrote: >> On 02/28/2012 07:33 PM, Keshav Kini wrote: >>> It's not much consolation right now, but this will become easier once we >>> switch to git, as branches can be automatically checked for whether they >>> are sti

Re: [sage-devel] review when one patchbot says TestFailed and the others say TestPassed

On Sat, Feb 25, 2012 at 10:33 AM, William Stein wrote: > On Sat, Feb 25, 2012 at 10:28 AM, Daniel Krenn wrote: >> I'm currently reviewing tickets #5491 and #12471. In both tickets the >> patchbot for 4.8 (linux/ubuntu/hardy/sage.math.washington.edu) failed, >> whereas the other two patchbots (one

Re: [sage-devel] Re: git and gerrit

On Tue, Feb 21, 2012 at 3:23 PM, Keshav Kini wrote: > Jason Grout writes: > >> On 2/21/12 12:19 PM, Robert Bradshaw wrote: >>> Perhaps we could require that every state >>> of the main line be consistant, and if it's worthwhile to preserve >>> inconsistent history we merge it as a branch rather t

[sage-devel] Re: Group collaboration on a branch of Sage

Robert Bradshaw writes: > On Wed, Feb 29, 2012 at 4:51 PM, Keshav Kini wrote: >> William Stein writes: >>> It's difficult for me because they are patch in hg format, but I can't >>> export a patch out of git in hg format.  It's possible to import the >>> code in from the trac ticket, but then if

Re: [sage-devel] Re: sage, gentoo-prefix & lmonade was: log messages

On Wed, Feb 22, 2012 at 7:57 AM, Burcin Erocal wrote: > On Tue, 21 Feb 2012 00:56:13 +0800 > Keshav Kini wrote: > >> Burcin Erocal writes: > >> >> Just to be clear, sage-on-gentoo itself has no goal of being a way >> >> to distribute Sage in general. It is simply a port of Sage and its >> >> SP

[sage-devel] Sage 4.8 build failed: Error: Failed to build Maxima as an ECL library.

Hi there, I saw people talking about this error on Lion. But this machine is linux, so it might be a new error. uname - a Linux msx0 2.6.18-274.12.1.el5 #1 SMP Tue Nov 8 21:37:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux Error Log: ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0 ;;; ;;; E

Re: [sage-devel] Unifying Command line options

On Fri, Jan 27, 2012 at 2:04 AM, R. Andrew Ohana wrote: > So I've been looking into restarting ticket #21 now that we have > argparse in python 2.7. The basic premise of the ticket was to make > our command line options use a standard library, however, since it was > opened (a long time ago), the

Re: [sage-devel] Will a debian buildslave be usefull?

On Tue, Feb 28, 2012 at 4:31 PM, Maarten Derickx wrote: > Dear All, > > I just got my very first own server up and running, I installed debian > stable (squeeze 6.0.4) on it. And I saw that sage doesn't have a buildslave > for debian yet. I might want to make it available as a buildslave depending

Re: [sage-devel] Re: trac field names -- arrrrr!

On Wed, Feb 29, 2012 at 5:47 AM, Jason Grout wrote: > On 2/28/12 11:19 PM, kcrisman wrote: >> >> "Needs reviewer", or >> something - that's probably not the right wording, but you get the >> point. > > > Exactly what I was going to suggest, if we are indeed going to go in the > direction of yet an

Re: [sage-devel] Re: trac field names -- arrrrr!

On Thu, Mar 1, 2012 at 1:38 AM, P Purkayastha wrote: > > > On Thursday, March 1, 2012 5:25:32 PM UTC+8, John Cremona wrote: >> >> On 29 February 2012 22:23, David Roe wrote: >> > You can use the custom query: >> > >> > http://trac.sagemath.org/sage_trac/query?status=needs_review&author=~cremona&o

Re: [sage-devel] Re: trac field names -- arrrrr!

On Tue, Feb 28, 2012 at 5:48 PM, Michael Orlitzky wrote: > On 02/28/2012 07:33 PM, Keshav Kini wrote: >> >> >> It's not much consolation right now, but this will become easier once we >> switch to git, as branches can be automatically checked for whether they >> are still mergeable into trunk or n

Re: [sage-devel] Sage security

Sage is as secure as bash (+ compilers). If you want to run arbitrary bash scripts, let other people run their bash scripts, or set up a web interface for others to running bash scripts, then you should get your security from another level (limited accounts, jails, virtual machines, etc.) One can