Re: [sage-devel] Re: Solaris binaries?

On Sat, Apr 20, 2013 at 8:42 AM, leif wrote: > William Stein wrote: >> >> On Sat, Apr 20, 2013 at 5:33 AM, leif > > wrote: >> >> Jeroen Demeyer wrote: >> >> On 04/20/2013 12:14 PM, Julien Puydt wrote: >> >> Le 20/04/2013 10:29, Jeroen Demeyer a

Re: [sage-devel] Re: New Trac Server

Bikeshedding? :-) On Apr 22, 2013 2:18 PM, "John Cremona" wrote: > Any chance of user configurable colour schemes? > > John > > On 22 April 2013 22:10, Jeroen Demeyer wrote: > > On 04/22/2013 09:32 PM, John Cremona wrote: > >> > >> I volunteer to be the official red-green colour-blind > >> guine

Re: [sage-devel] Re: Pickling and TestSuite problems in doctests

As a quick example (that is not minimal), you can go to your (David) OMS repository (https://github.com/roed314/OMS). I just pushed a change that adds a failing doctest to sage/modular/pollack_stevens/distributions.py . Note that there are doctests in that file that run the TestSuite and they p

Re: [sage-devel] Re: git transition timetable

When 5.9, 5.10, ... are out is up to Jeroen. My goal is to have everything reviewed by mid/late June, so assuming I meet my goal then I expect a 6.0 release in the Augest-September time frame (assuming about a month gestation period for releases). On Mon, Apr 22, 2013 at 2:14 PM, John Cremona wr

Re: [sage-devel] New Trac Server

On Monday, April 22, 2013 2:08:09 PM UTC-7, Jeroen Demeyer wrote: > > On 04/22/2013 10:57 PM, R. Andrew Ohana wrote: > > If we are going to change the colors for diffs, please give suggestions. > > Also, there is two shades of a third color that will be used once we > > switch to git, see > >

Re: [sage-devel] Re: New Trac Server

Any chance of user configurable colour schemes? John On 22 April 2013 22:10, Jeroen Demeyer wrote: > On 04/22/2013 09:32 PM, John Cremona wrote: >> >> I volunteer to be the official red-green colour-blind >> guinea-pig if you point me to a suitable sample page. > > Me too by the way. > > > -- >

Re: [sage-devel] Re: Pickling and TestSuite problems in doctests

Are these files in the Sage library? If not, the doctesting code executes the file, thus overwriting the factory. But it should be done before calling anything, so I wouldn't think it would cause this problem. As Volker says, can you post a testcase somewhere? David On Mon, Apr 22, 2013 at 9:3

Re: [sage-devel] Re: git transition timetable

Thanks for the detailed workplan, that is useful. Any ideas at all on when these releases (5.9, 5.10, 6.0) will be out? Perhaps that is not a fair question from someone not contributing to the transition -- sorry! John On 22 April 2013 20:41, R. Andrew Ohana wrote: > I've been posting git rele

Re: [sage-devel] Re: New Trac Server

On 04/22/2013 09:32 PM, John Cremona wrote: I volunteer to be the official red-green colour-blind guinea-pig if you point me to a suitable sample page. Me too by the way. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this g

Re: [sage-devel] New Trac Server

On 04/22/2013 10:57 PM, R. Andrew Ohana wrote: If we are going to change the colors for diffs, please give suggestions. Also, there is two shades of a third color that will be used once we switch to git, see http://trac.tangentspace.org/changeset/3b459a4ef46068ed1b62acd5bfb81b721f87bfaa/. And w

Re: [sage-devel] New Trac Server

If we are going to change the colors for diffs, please give suggestions. Also, there is two shades of a third color that will be used once we switch to git, see http://trac.tangentspace.org/changeset/3b459a4ef46068ed1b62acd5bfb81b721f87bfaa/ . Everything at trac.tangentspace.org will be tossed whe

Re: [sage-devel] New Trac Server

On Apr 22, 2013, at 13:16 , Maarten Derickx wrote: > The account creation page only takes seconds to load instead minutes. So this > new server makes me very happy. A question (well, two) occurs to me: are new accounts needed? Will new accounts made during testing survive the transition to "

[sage-devel] Re: New Trac Server

The account creation page only takes seconds to load instead minutes. So this new server makes me very happy. Le lundi 22 avril 2013 20:19:44 UTC+2, R. Andrew Ohana a écrit : > > Hey Everyone, > > Sometime in the next couple weeks, we will be moving our trac installation > over to a dedicated VM

Re: [sage-devel] Mac OS X dependencies to build from source

On Friday, April 19, 2013 11:52:34 PM UTC+2, Jean-Pierre Flori wrote: > > > It seems it happened to other people as well: > https://discussions.apple.com/message/21781679#21781679 > And the situation is back to "normal" now... -- You received this message because you are subscribed to the Goo

Re: [sage-devel] Re: git transition timetable

I've been posting git releases in the sage-git mailing list, and once #14330 is merged I'll start posting the git releases to the sage-release mailing list. Otherwise, here is the status: Known issues: -- sagenb is broken (will be fixed with sagenb-0.10.6 -- this is #14330) -- 2 doctest failur

Re: [sage-devel] browsing Sage source code

On Apr 22, 2013 11:28 AM, "Jeroen Demeyer" wrote: > > On 04/22/2013 08:10 PM, William Stein wrote: >> >> Hi, >> >> There is a link on the sagemath.org web site >> >> homepage to the Sage source code (where it says "open source"), and it's >> to a mercurial repo we self-host (

Re: [sage-devel] Re: New Trac Server

On 22 April 2013 20:20, John H Palmieri wrote: >> 5) Sage color scheme has been updated/fleshed out to match the updated >> trac theme > > > Speaking of color schemes: I've heard comments that the red and green colors > used when displaying patches are not ideal for color-blind users. Should we >

[sage-devel] Re: New Trac Server

On Monday, April 22, 2013 11:19:44 AM UTC-7, R. Andrew Ohana wrote: > > Hey Everyone, > > Sometime in the next couple weeks, we will be moving our trac installation > over to a dedicated VM. You can currently access the instance at > trac.tangentspace.org -- although note that the database is a

Re: [sage-devel] browsing Sage source code

On 04/22/2013 08:10 PM, William Stein wrote: Hi, There is a link on the sagemath.org web site homepage to the Sage source code (where it says "open source"), and it's to a mercurial repo we self-host (http://hg.sagemath.org/). I wonder if pointing to https://github.com/sa

[sage-devel] New Trac Server

Hey Everyone, Sometime in the next couple weeks, we will be moving our trac installation over to a dedicated VM. You can currently access the instance at trac.tangentspace.org -- although note that the database is a snapshot from Sunday evening, so don't do any real development there, since it wil

[sage-devel] browsing Sage source code

Hi, There is a link on the sagemath.org web site homepage to the Sage source code (where it says "open source"), and it's to a mercurial repo we self-host (http://hg.sagemath.org/). I wonder if pointing to https://github.com/sagemath/sage might be nicer, since github has a much better source

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On Mon, Apr 22, 2013 at 06:01:17PM +0200, Felix Salfelder wrote: > On Mon, Apr 22, 2013 at 11:34:05AM +0200, Tobias Hansen wrote: > > On 04/22/2013 11:14 AM, Jeroen Demeyer wrote: > > > [..] > > >libcsage means nothing without the Sage Python library, the > > >Sage Python library requires libcsage

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On Mon, Apr 22, 2013 at 11:34:05AM +0200, Tobias Hansen wrote: > On 04/22/2013 11:14 AM, Jeroen Demeyer wrote: > > [..] > >libcsage means nothing without the Sage Python library, the > >Sage Python library requires libcsage and the scripts make no sense > >without Sage. (see the other posts about

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

Le 22/04/2013 17:15, Jeroen Demeyer a écrit : On 04/22/2013 12:06 PM, Felix Salfelder wrote: why not leave these choices to the user? Because it's more work for us to support this, for absolutely no advantage. I suggest sage-the-distribution sticks to not leaving choices to the users because

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On 04/22/2013 12:06 PM, Felix Salfelder wrote: why not leave these choices to the user? Because it's more work for us to support this, for absolutely no advantage. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group an

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On 04/22/2013 12:41 PM, Francois Bissey wrote: My current sage-on-gentoo install on a OS X prefix is without sagenb and as far as I am concerned it works. What do you mean with "it works"? Sage-without-sagenb certainly doesn't work for me, when starting Sage: Traceback (most recent call last):

[sage-devel] Re: Pickling and TestSuite problems in doctests

I figured out what the difference was between the class that works and the one that doesn't: nothing! The only difference is that for the class that works I had a leftover "from ... import WorkingFactory" statement at the beginning of my doctest (leftover in that I had put it there before inclu

[sage-devel] Re: git transition timetable

On Monday, April 22, 2013 6:23:34 AM UTC-4, John Cremona wrote: > > Could someone report on where the transition to git has reached and > when it will happen (or give a link to somewhere this is recorded)? > > It seems to me from postings to this group that this will be soon > enough that it i

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

Op maandag 22 april 2013 14:57:17 UTC+2 schreef Timo Kluck het volgende: > > No, it's about publishing a recent version of sage in a PPA (or in the app > store) for ubuntu. > I should add: but this is not something I'm actually working on, it's just what the idea was about. :-) Timo -- Y

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

Op maandag 22 april 2013 14:52:15 UTC+2 schreef Felix Salfelder het volgende: > > > I was > > thinking of the idea of having sage-specific deb packages for sage's > > foreign (often patched) modules. So maybe sage-gap, sage-maxima, et > cetera, > > which would install into /opt/sage. > > is t

Re: [sage-devel] Re: Solaris binaries?

On Mon, Apr 22, 2013 at 2:37 PM, Jeroen Demeyer wrote: > The current version of the Solaris build is NONE. > which is quite confusing. I tried to catch this with a SSI-"if" check, but it didn't work and i let it be. Tried it again right now, it works in the opposite way. no idea why ;-) It's als

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

Hi Timo. On Mon, Apr 22, 2013 at 05:23:10AM -0700, Timo Kluck wrote: > So you're trying to make Sage "native" on Debian as opposed to making > packages for the sage-patched foreign packages. yes. > That's probably an > unrelated effort to our portage work, except that whatever build system >

Re: [sage-devel] Re: Solaris binaries?

Also, the page http://www.sagemath.org/download.html still talks about Solaris binaries. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@go

Re: [sage-devel] Re: Solaris binaries?

On 04/20/2013 05:42 PM, leif wrote: I would probably keep the directory / page though, with just a README explaining that we still (intend to) support Solaris on x86 and SPARC (and regularly test on these platforms), but simply do no longer offer binary distributions of Sage for these. Sounds go

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

> debian has already packages for most of the foreign packages, and this > is totally unrelated to sage. what i need is just packages for the core > modules (currently the directories in /src). my proposal > is to handle all modules (foreign or not) alike, and add build systems > where missin

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

Hi Julian On Mon, Apr 22, 2013 at 01:24:21PM +0200, Julian Rüth wrote: > * Felix Salfelder [2013-04-22 13:01:20 +0200]: > > On Mon, Apr 22, 2013 at 03:15:54AM -0700, Timo Kluck wrote: > > > We're trying to replace the current spkg system (actually the spkg system > > > like it exists in the git

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

* Felix Salfelder [2013-04-22 13:01:20 +0200]: > On Mon, Apr 22, 2013 at 03:15:54AM -0700, Timo Kluck wrote: > > We're trying to replace the current spkg system (actually the spkg system > > like it exists in the git repo) by some version of Gentoo's portage. This > > would be similar to the lmo

[sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

El jueves, 18 de abril de 2013 17:05:00 UTC+2, leif escribió: > > 'man sem_open' would probably have been quicker... ;-) > There are more man pages that could be dreamt in my philosophy. > Did you run that as root, or as the user you're building Sage with? > "All ok!" for both. > (And did

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

Hi Timo. On Mon, Apr 22, 2013 at 03:15:54AM -0700, Timo Kluck wrote: > We're trying to replace the current spkg system (actually the spkg system > like it exists in the git repo) by some version of Gentoo's portage. This > would be similar to the lmonade project, except that it's trying to be a

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On 22/04/13 21:14, Jeroen Demeyer wrote: > On 04/22/2013 09:57 AM, Felix Salfelder wrote: >> do you see disadvantages in treating sage parts as modules? > It doesn't even make sense to treat them as modules, since they are not > independent. libcsage means nothing without the Sage Python library, t

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On Mon, Apr 22, 2013 at 10:08:48PM +1200, Francois Bissey wrote: > If you change the way c_lib is built by using the python library > setup.py instead, we'll ditch our own separate package. if you ask me, setup.py should be used *only* for the python library (which is then treated as a module). yo

[sage-devel] git transition timetable

Could someone report on where the transition to git has reached and when it will happen (or give a link to somewhere this is recorded)? It seems to me from postings to this group that this will be soon enough that it is not worth showing a new potential developer how to use Mercurial, queues and a

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

Op maandag 22 april 2013 09:57:19 UTC+2 schreef Felix Salfelder het volgende: > > do you see disadvantages in treating sage parts as modules? > > maybe it doesnt matter much, whether c_lib and scripts are in the same > module or not, for distribution purposes it makes sense to have > python-sa

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On 22/04/13 19:57, Felix Salfelder wrote: > On Mon, Apr 22, 2013 at 09:45:18AM +0200, Jeroen Demeyer wrote: >> On 04/22/2013 09:28 AM, Felix Salfelder wrote: >>> sage already was modular in that sense, before the git transition >>> started. all that was missing, was a build system for sagelib and >

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On Mon, Apr 22, 2013 at 11:14:43AM +0200, Jeroen Demeyer wrote: > On 04/22/2013 09:57 AM, Felix Salfelder wrote: > >do you see disadvantages in treating sage parts as modules? > It doesn't even make sense to treat them as modules, since they are > not independent. libcsage means nothing without the

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On 04/22/2013 11:14 AM, Jeroen Demeyer wrote: On 04/22/2013 09:57 AM, Felix Salfelder wrote: do you see disadvantages in treating sage parts as modules? It doesn't even make sense to treat them as modules, since they are not independent. libcsage means nothing without the Sage Python library, t

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On 04/22/2013 09:57 AM, Felix Salfelder wrote: do you see disadvantages in treating sage parts as modules? It doesn't even make sense to treat them as modules, since they are not independent. libcsage means nothing without the Sage Python library, the Sage Python library requires libcsage and t

[sage-devel] Re: Pickling and TestSuite problems in doctests

Do you have some minimal testcase? Its hard to say anything for sure without some code. If your class does complicated things it is sometimes necessary to implement __reduce__, though. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscri

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On Mon, Apr 22, 2013 at 09:45:18AM +0200, Jeroen Demeyer wrote: > On 04/22/2013 09:28 AM, Felix Salfelder wrote: > >sage already was modular in that sense, before the git transition > >started. all that was missing, was a build system for sagelib and > >sage-python (this is where i ignorantly start

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

On 04/22/2013 09:28 AM, Felix Salfelder wrote: sage already was modular in that sense, before the git transition started. all that was missing, was a build system for sagelib and sage-python (this is where i ignorantly started my first proposal). switching to git is a great idea. if submodules/ex

Re: [sage-devel] proposal: make the Sage build system more distribution friendly

Hi Andrew. some of this is confusing a lot... On Sun, Apr 21, 2013 at 03:45:10PM -0700, R. Andrew Ohana wrote: > Ah, yes, I see your point. One suggestion then is to maybe think about > adding such checking functionality to Cython directly (since it already > computes the entire dependency tree,