Re: [sage-packaging] Re: [sage-devel] Brainstorming about Sage dependencies from system packages
On Sat, May 27, 2017 at 01:16:39PM +0200, Erik Bray wrote: > All I'm proposing are some very *minor* changes that change little about > how Sage is currently worked on, while still being a quality of life > improvement, in a way. Hi Erik. that's great news. and it sounds like the way to go, particulary in contrast to what i tried four years ago. (TL;DR; that was a demo of a modified sagelib that worked on a modified sage-the-distribution, as well as on debian -- i made choices, likely too pragmatic, and it went all bikeshed). > In other words, it's something I can do now with maybe a few days of work > instead of a major overhaul of everything. So I'd rather this thread focus > on the details of those minor changes than any big ideas that may or may > not go anywhere. the place where I would start today is just the blacklists. i.e. have toplevel configure flags that allow telling sage-the-distribution not to build spkgs. rather pretend they are "installed" (into $SAGE_LOCAL, as usual) to all other parts. something similar to $ ./configure --disable-patch --disable-ncurses will then effectively fallback to system packages without much more work. note how 4 years back, even the use of PATH was highly controversial. i reckon the situation has improved. the blacklist method will enable anyone (i am thinking of power-users and distributors, conda fans, or myself), to try, and send patches... some of them will be needed. i see the point of having all sorts of magic to determine whether or not a system package substitutes an spkg. (and i partly did some of that kind myself). i do now consider that pointless, way too much work. imo, nowadays, functionality checks should be on package level, and a transition path close to - provide blacklists - switch to system packages, one by one, fix the remaining - eventually reach "./configure --disable-all --enable-sagelib" - use standalone (vanilla) sagelib on gentoo, conda, debian, etcpp - ditch sage-the-distribution for (something similar to) conda seems feasible. at the end, it does not matter much, what spkg -i might have done during the transition. keep it simple, print a warning "not supported", and exit 1. regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Hi Volker. actually i anticipate that you know better. anyway i reply. again. just for the record. On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote: > That is not true. What is true is that none of the core developers wants to > make their life even more difficult so that the debian packages have less > to do. this is *not* *about* *debian*. only about 1/3 of linux installations are debian based. a lot of distributions are not even based on any other. sage does not only run on linux. go figure. > At the bottom of it, it is a social rather than a technical problem. You > need to convince people that you have a better way, and be able to listen > to upstream projects. at no time did i have a better way to do what you do. i wanted to try something else. somehing more straightforward. i listened to upstream and i have dropped the idea (see my last mail). still i do not know which other way might have done the trick. for the very least i did not try to move to portage. conversation could have been more productive. > Trying to rip out cythonize() because automake doesn't do wildcards? i fell back to automake, because cythonize does not support dependency tracking. does it today? don't know. needless to say that i have asked for alternatives. out-of-tree builds solved a different set of problems. afaik, the recompile-everything-everytime issue stroke back a few months ago... while i tried to address some of these issues (yes, the technical side), i learned that - modularisation is evil - libgap is necessary and must pretend to be gap - tabs are bad and so are makefiles - autotools releases must be pulled from git - capitalization is important and maybe other surprising or interesting things that i forgot about (still, thanks for the useful input!). and again: in which way does autotools not support wildcards? i guess you are pointing to the fact that i did not want to rely on them. just add it to the list above. > And you are surprised that this did not make it upstream? no. should i? this was never complete nor will it be of any use for the better-bootstrap-the-universe folks. it is not your obligation to support or even think any of this. sage is a great/interesting piece of software. sure, attempts to package (with or without help from upstream) will not die down. it is a matter of how to deal with external ideas, needs and resources. hopefully, my project will serve as a warning to others and eventually justify a fork that avoids sage-the-distribution completely. just sagelib alone is considerably simpler to deal with. for packaging you don't need dependency tracking *hint hint*. all the best felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Sat, Feb 21, 2015 at 03:58:29AM -0800, Volker Braun wrote: > [..] it still doesn't work. you keep saying that. but does it matter? the configuration worked pretty good as a proof-of-concept. i am sorry if your expectations were higher. note that this particular part was just optional within the project ([1] part 2, last item), no more no less. as it seems, hardly anybody (and about zero of the core developers) from the sage community wants to make use of system-installed packages (except for maybe gcc, ssl and whatnot). yet, i did not expect that much headwind. after all the mere attempt of a straightforward bypass implementation has been pretty pointless. in the meantime, i have dropped the top-level part to concentrate on making just sage (the library, the software, the essential part) work for non-(sage-the-distribution or OSX-based) software distributions. the effort makes no sense for sage-the-distribution, where all paths are to stay static and hardcoded. forks are evil and all that, but the build/install now works if the build dependencies are available. it's lagging behind at 6.3-something, i don't use sage currently, and i have other things to do. > Nor is it a particularly good way of exposing a lot of configuration > options (at least one per package). the intent was to have exactly one option per package. this (would have) allowed to install/develop sage-the-distribution with all foreign packages disabled except pari (hey, this is not even off topic!). may anyone find a better way. good luck felix [1] https://www.google-melange.com/gsoc/project/details/google/gsoc2013/felixs/5779342353235968 -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] equals tilde in sage launch script
On Mon, Jan 05, 2015 at 12:59:17PM -0800, kcrisman wrote:
> if [[ "$1" =~ "--notebook="* || "$1" =~ "-n="* || "$1" =~ "-notebook="* ]];
> [..]
>
> Is there an obvious way to remove the =~ from this [..]?
this likely works with older bash
$ foo=bar
$ echo ${foo:0:2}
ba
and this
$ if [ "${1:0:11}" = "--notebook=" ] || ...
might do the trick.
have fun
felix
PS: also, the "*"s in the original line look suspiciously unescaped (is this a
bug?).
from the manual:
The special pattern characters have the following meanings:
* Matches any string, including the null
string. When the
globstar shell option is enabled, and * is used in a
pathname expansion
context, two adjacent *s used as a single pattern will
match all files and zero
or more directories and subdirectories. If followed by
a /, two adjacent *s
will match only directories and subdirectories.
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
On Tue, Nov 18, 2014 at 03:35:57AM -0800, Volker Braun wrote: > The problem with union file systems is that you don't have a good option on > OSX (e.g. forget about the built-in union fs). Hi Volker. i dont think that reviews made on non-OSX computers are inferior. and, nobody would keep you from recompiling on OSX, while other platforms do better. anyway there must be something like cp -a on OSX, and can probably be used instead, to bridge the semantics -- until OSX gets a suitable update. yes, there might be some impact on efficiency, clearly SEP... note that sage includes conditional stuff that only works for OSX, and is of no use otherwise (which is not a bad thing!). cheers felix PS: i have not used aufs or anything like it. it appears to potentially solve a problem. if its not perfect, maybe recompilations are still worse. -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: About recmpilations caused by Git
On Mon, Nov 17, 2014 at 05:57:53PM -0800, Andrew wrote: > When the branch is finally ready for review it has to be merged with the > latest development branch, so you can't avoid this indefinitely. As with > Nathan, I'm reluctant to continuously switch between versions because of > the compile time lag. hi there. some thoughts - there is no such thing as a 'reviewed' branch. if a review corresponded to a merge into 'reviewed', no switching back (to develop? master?) would be necessary (in theory..) - git-new-workdir (part of git) [1] permits multiple work directories on top of one repository. this makes multiple builds more efficient, such as one for production and one for review. - aufs [2]. use an overlay for reviewing. afterwards discard it and return to the previous state. hth felix [1] -> search engine, tons of resources available. [2] http://aufs.sourceforge.net -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] What should be the present working directory for sage -notebook=ipython ?
On Mon, Oct 13, 2014 at 06:25:01AM -0700, Sébastien Labbé wrote: > - pwd obviously. thanks for catching this, it will be hard to fix afterwards. can you name a single (mature?) program that breaks with this convention? cheers felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)
On Fri, May 02, 2014 at 09:48:50AM +, Francois Bissey wrote: > I know what you want to say Felix but once the pre-requisite are in place > we are more less performing all the install from a "sage shell" in which > sage-env is used to set the environment. a sage shell is not necessary to run the spkg-install's (see my proof-of-concept thing). and it shoudn't be used. likewise, any of the other package managers proposed back then (ebuilds-based?) wouldnt be ran from a sage-shell. > When spkg-install is at work, sage-env is read. At least that's how I > understand > it works. part of the problem. i've fixed this by *not* sourcing sage-env from toplevel, see the demo tarball. good luck with this. felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)
On Fri, May 02, 2014 at 09:12:34AM +1200, François Bissey wrote:
> > We could put it into sage-env as well, but regarding how often that's
> > called...
>
> I was actually thinking of feeding it to sage-env :)
sage-env is a part of sage ("the library"). the environment for
pkgconfig (and probably others, think of python) must be present before
the library package/module has been configured/built/installed.
please consider an environment for sage ("the distribution"), which is
fed from toplevel configure and later included by sage-env.
cheers
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)
On Thu, May 01, 2014 at 10:58:47PM +0200, leif wrote: > Felix Salfelder wrote: > >pkg-config --variable pc_path pkg-config > > That doesn't always work. (See my other post on how to get it.) if so (when?), how about fallback to something more complex *in case it does not*? reportedly, --debug does not always exist either. cheers felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] R graphics and pkg-config (trac #15742)
On Thu, May 01, 2014 at 07:18:18PM +, Francois Bissey wrote:
> So we should either find the system folders in sage-env or patch our
> pkgconfig source to search them automagically.
fwiw: last year i figured out the following values to make the
'configurable sage ("the distribution")' work.
PKG_CONFIG_PATH=`pkg-config --variable pc_path pkg-config`
PKG_CONFIG_LIBDIR="$path_where_local_is/local/lib/pkgconfig"
patching pkg-config doesnt seem to be necessary. you will somehow have
to call pkg-config before changing $PATH.
have fun
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Re: How to define a new ring class ? [We need a class representing genuine real field]
On Thu, Mar 13, 2014 at 12:59:28PM +0100, Thierry wrote: > > These examples are great ! It would be more natural to have > > sage: Infinity in RFF and NaN in RFF # real floating field > > True > > sage: Infinity in RR and NaN in RR # real numbers > > False i've been waching discussions about real number problems for some time and i have a question. excuse me if this is stupid. there is no such thing as a field of floating point numbers, but the real numbers form a field. i am surprised that this doesnt look like """ sage: Infinity in FPN and NaN in FPN # floating point numbers True sage: Infinity in RR or NaN in RR# real number field False """ from the beginning. doesnt it make (much) more sense to preserve the word "field" for things that are fields in a mathematical sense? and while i'm at it... > sage: Infinity in RRbar > True > sage: NaN in RRbar > False wouldn't it make sense to have both, RR_inf and RR_pminf? one for each compactification... otherwise, why choose one over the other? """ sage: RR_inf(Infinity) == RR_inf(-Infinity) True sage: RR_pminf(Infinity) == RR_pminf(-Infinity) False """ cheers felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] system-wide sage installation with option to add spkgs locally
On Mon, Mar 10, 2014 at 09:30:27AM +0100, Felix Salfelder wrote: > when I was working on the spkg-install scripts, i decided to > undisambiguate SAGE_LOCAL. or rather un-undisambiguate :) felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] system-wide sage installation with option to add spkgs locally
On Mon, Mar 10, 2014 at 09:12:18AM +0100, Ralf Hemmecke wrote: > I don't know whether this is the right place to ask, but how can meet > Sage the following use case? > > - system-wide installation of sage in /opt/sage/$SAGEVERSION > - /opt/sage is not writable by an ordinary user > - "sage -i PACKAGE" exacuted as an ordinary user should install an > additional spkg into $HOME/.sage-local/$SAGEVERSION. > > Is that currently possible? > Can such behaviour be easily achieved? > > Of course, I don't want to copy the full installation of Sage, but > rather only the files that "sage -i" needs to modify are copied over to > $HOME. And I would expect that Sage first looks into > $HOME/.sage-local/$SAGEVERSION before it tries /opt/sage/$SAGEVERSION. when I was working on the spkg-install scripts, i decided to undisambiguate SAGE_LOCAL. SAGE_LOCAL is used as "installation" path *and* as search path from within the spkg-install's. between the lines of #15136 #14804 i fixed this by introducing a SAGE_PREFIX variable. this then was supposed to be passed as an ordinary prefix to the spkg-install programs and was set to $SAGE_LOCAL for inside-sage-the-distribution (or git-development-mode, how-you-call-it) installs. i'd be happy to see (something like) SAGE_PREFIX (maybe just PREFIX?) in future versions. i'm sorry i currently don't have a lot of (read: "no") time to work on this. good luck felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] sage-location
> On 2014-03-01 18:37, William Stein wrote: > > Forcing sage-location, probably because a new package was installed. > > Updating various hardcoded paths... > > (Please wait at most a few minutes.) > > DO NOT INTERRUPT THIS. > > > >This is a somewhat disturbing waste of time, right? it is a really good idea to get rid of sage_location, or if that is not always possible, it should be restricted it to its use case (ie. where hardcoded paths cannot be avoided and need to be updated). On Sun, Mar 02, 2014 at 11:33:22AM +0100, Jeroen Demeyer wrote: > The problem is that Sage cannot know in advance that you will *not* > move the Sage tree. hardcoded paths only need to be fixed once, *just after* moving sage. the condition is easy to detect, and has nothing to do with knowing in advance. not running sage_location generally does not hurt, except for a bogus doctest that will fail. i fell for this after i had built sage (the library) outside of sage (the distribution) and after i had built sage (the distribution) with fallback to system packages. iirc an unexpected ipython executable triggered a doctest failure. cheers felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sun, Jan 12, 2014 at 01:09:42PM -0500, Michael Orlitzky wrote: > Prefix is designed to run as an ordinary user on non-gentoo systems. If > you're on gentoo, you don't need it (unless you don't have root). Plenty > of us have been able to get it working, so if we made a concerted > effort, I'm sure we could stick a nice UI on it. Besides, it's currently > working better than the nonexistent rewrite being discussed. the nonexistant rewrite exists as a demo [1]. it is based on autotools (not python). it is mostly boilt down to calling the spkg-install programs in the right order, while being semantically similar to the current toplevel makefiles and scripts. it also supports package content lists (to possibly remove/exchange packages) and is able to optionally completely disable packages (fallback to system packages). i'm sure a python script could as well be used to call the spkg-install programs in the right order and do fancy stuff. but similar to the autotools build system, it will not be able to guess package contents without some tiny spkg-install modifications like [2]. imo, sage should stay distribution independent, distributions other than sage should only require to package sagelib in the end. and whatever happens next, sage (the library) should be freed from hardcoded paths and from package management code, so not everybody has to work that out again and again, YMMV of course. have fun felix [1] http://tool.em.cs.uni-frankfurt.de/~felix/sage [2] http://trac.sagemath.org/ticket/15136 -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] compile sage from github
On Mon, Nov 11, 2013 at 07:09:54PM +0100, Ralf Hemmecke wrote: > But I think even if I send that log, the bug is rather that Sage should > check "git --version" and then don't start trying to build git at all, > no? "checking whether is necessary" is one part of the problem. according to some sage developers it must also be impossible to accidentally run into provided by the (surrounding) system, if has not been explicitly marked unnecessary. so unless you change the rules, you will have to resolve #12627 (my proposed toplevel build system does). regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] compile sage from github
On Mon, Nov 11, 2013 at 06:39:28PM +0100, Ralf Hemmecke wrote: > Obviously your (and probably others) opinion is that a sage installation > as approached by Felix for Debian cannot easily be lifted to other > non-debian distributions. I haven't actually looked at any code (so I'm > rather uninformed). Still, can you summarize what the problems with > Felix' approach is? Hi there. nothing i proposed to merge into sage is debian specific^*. i merely made it possible to optionally disable packages, and make sure the rest still works (independent of this choice). finally it worked with either all packages enabled on a random platform, or with most packages disabled (manually) and running on debian (carefully crafted with recent packages). and to make it clear: the main focus has never been debian. that's why i was not done after unhardwiring the run time paths in sagelib (=src/*), it was pretty clear that nobody cares. Furthermore, i didn't even dare to propose automatic choice of whether a package should be disabled. you guess that i am sure it would work out for most packages. Volker (welcome back from sarcasm mode!) may be right that some doctests were failing in my demo tarball, but that was about the same number that were failing in the "build-system" branch, where I started off. once the dust from the git transition has settled, it should be straightforward to review/merge/rebase the patches/commits/branches i have lined up. but i didnt receive any serious feedback yet -- particularly not during the project period. googlegroups won't forget. have fun felix ^*Volker might have misconceived my failed attempt to fix libgap. when it turned out that OSX doesnt like symbol name mangling, i proposed to patch the (not yet existing, not yet planned, not yet reachable) sagelib package for debian, instead of unnecessarilty packaging libgap for debian. -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] compile sage from github
On Mon, Nov 11, 2013 at 06:53:37AM -0800, Volker Braun wrote: > On Sunday, November 10, 2013 10:14:30 AM UTC-8, Felix Salfelder wrote: > > > > the idea is to run sage (the distribution) on top of debian. and > > only compile packages that deviate from upstream or the debian > > package. > > > Fixed that for you. that's great. would you be so kind and tell me/us where to find it and how to make use of it? thanks felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] compile sage from github
On Sun, Nov 10, 2013 at 01:02:30PM -0500, Vincent Delecroix wrote: > I do really think that this is the best of what can > happen for Sage but I also think that we need an agreement of all Sage > developers that spkg can not be patched... actually, it's the other way around. if there were no patched/bleeding edge packages within sage-the-distribution, there was no need for that toplevel build system -- you could just run standalone sagelib on top of anything you like. the idea is to run sage (the distribution) on top of (e.g.) debian. and only compile packages that deviate from upstream or the (e.g.) debian package. particularly, this enables you to *develop* sage within sage-the-distrition on top of any other software distribution without unnecessarily compiling hundreds of spkgs (like git). regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] compile sage from github
On Sun, Nov 10, 2013 at 04:56:58PM +0100, Ralf Hemmecke wrote: > What actually surprises me is that Sage must build git at all. Wouldn't > it make sense to restrict build and development scripts to use features > of a git version number that is usually satisfied by current major > stable distributions and build git only when this is not fuflilled for > some very old distribution. Note that git must have been installed, > since I have (successfully) cloned sage from github. Hi Ralf. I have addressed this problem within my gsoc project. the solution is a configurable toplevel build system that allows to choose between "build stuff shipped with sage (the distribution)" and "fallback to already installed software" on a per-package basis. see [1] for instructions on how to build a demo sage (the distribution) on top of debian. if this is of any use, you may want to help to integrate a proper build system for sagelib [2], and eventually finish the toplevel build system described above [3]. good luck felix [1] https://wiki.debian.org/DebianScience/Sage [2] http://trac.sagemath.org/ticket/14807 [3] http://trac.sagemath.org/ticket/14796 -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: How can an spkg extend the interactive Sage environment?
On Mon, Sep 30, 2013 at 03:51:15PM -0700, Bill Janssen wrote: > > However, I've also got to make sure that the environment variable > > JMODELICA_HOME is set. Is there some way for an spkg to hook into sage-env > > and extend it? > Hello? Anyone? that's pretty easy to do. actually, unhardwiring the parts of sage-env solves a lot more problems. it is #15087, and it does no longer merge cleanly, because of some other changes I dont know about. have fun. felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] sage-env always sets LDFLAGS, which clobbers Numpy's distutils Fortran compiler support
On Tue, Sep 24, 2013 at 10:34:11AM -0700, Bill Janssen wrote: > Hmmm, but that would replicate the fairly complicated Python code that it > already uses to determine the proper flags. > > For the moment, I've fixed it by doing an "unset LDFLAGS" in the > spkg-install file, but I think it's still a Sage bug to export empty > LDFLAGS if the user hasn't set them that way. if empty LDFLAGS is what the upstream build system wants to see, unsetting LDFLAGS is the right thing to do (in this case). broken build systems are ubiquitous :/. at best, there is an "EXTRA_LDFLAGS" variable (or something), that you can use to pass the actual user defined LDFLAGS... if exported LDFLAGS were a sage bug, you would have to unexport them in sage-env (which makes things worse -- probably). > There's a difference between an empty value and "not defined", after > all. there *is* a difference. in my experience there's nothing useful about it. implicitly overriding (not appending!) flags from the environment is merely asking for trouble. regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] sage-env always sets LDFLAGS, which clobbers Numpy's distutils Fortran compiler support
On Mon, Sep 23, 2013 at 02:21:39PM -0700, Bill Janssen wrote: > I was trying to compile the Python+Fortran Assimulo package on Sage (5.11) > on OS X, and I couldn't figure out why the gfortran link step kept failing > -- the correct linker flags for shared libraries weren't being used. Turns > out that the "fcompiler" support in Numpy's distutils will *always* look at > LDFLAGS and use them instead of the carefully determined platform-specific > flags. > > And there's this code in sage-env: > > if [ "$LDFLAGS" = "" ]; then > LDFLAGS="" && export LDFLAGS > fi > > So the empty LDFLAGS setting was always clobbering the carefully determined > platform-specific flags. > > Not sure this is a good thing... While it does not exactly make sense to export empty LDFLAGS in case they are empty already, this shouldn't affect the spkg. the correct place to figure out appropriate flags for the Assimulo build system is its spkg-install file/program (you may want to *append* global LDFLAGS, maybe...). regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] A .cc file in Sage's source code
On Sun, Sep 22, 2013 at 02:10:27PM +0200, Nathann Cohen wrote: > > does it run outside of sage/distutils magic (with cython and gcc called > > manually)? should be easier to debug... > > Hmmm... I just made it work by compiling the .cc file as a shared > library, and linking the .pyx with the library in modules_list.py. what you probably want to make work is one pyx and one cc in one python object. a library and linking sounds like overkill. > But I can't get it to work by having Cython compile this cursed .cc file :-P by having /distutils/ compile it? does it work if you compile manually? something like $ cython somefile.pyx -o somefile.cc $ c++ somefile.cc -shared -fPIC -o somefile.o $ c++ yourfile.cc -shared -fPIC -o yourfile.o $ c++ yourfile.o somefile.o -o somemodule.so > Now it is telling me that I define several methods twice. Ahahahah. > This thing is a nightmare ;-) sounds much like forgotten #ifndef something\n#define someting and #endif in your header... (?) > So is there any place in Sage where you can write a couple of calls to > gcc, to make a library out of a .cc file ? The only place I know is a > spkg, and that's too much trouble ^^; without distutils, that would be easy :/ regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] A .cc file in Sage's source code
On Sun, Sep 22, 2013 at 01:12:31PM +0200, Nathann Cohen wrote: > Yep. But that's how I get my segfault, unfortunately :-/ does it run outside of sage/distutils magic (with cython and gcc called manually)? should be easier to debug... > I'll resume the fight :-P good luck felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] A .cc file in Sage's source code
Hi Nathann. On Sun, Sep 22, 2013 at 12:44:34PM +0200, Nathann Cohen wrote: > Hmmm... I really tried this way (that's what I called "compiling it > through Cython" in my message). i see. a closer look into module_list.py reveals that the c/cc code is just added to cython autogenerated code. urghs. is this what you tried/want to do? > and I really can't get it to work. The > only thing that does it for me now is a .pxd file with a "cdef extern > from 'myfile.cc'", and it produces a segfault >_< if yourfile.cc contains the implementation, you probably want to add a header with just the prototypes, and cdef from there (but i'm not so totally sure about what cython/distutils will do with it -- cross your fingers properly). have fun felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] A .cc file in Sage's source code
On Sun, Sep 22, 2013 at 10:34:53AM +0200, Nathann Cohen wrote: > Would anybody know if there is an easy way to have a .c, .cpp or .cc file > in Sage's source code, and have it compiled "manually", i.e. with a call to > gcc and not through Cython there are plenty of cases of this kind. grep -e '\.c\>' -e '\.cc\>' -e '\.cpp\>' src/module_list.py also, there is a proper build system waiting for integration, #14807. > Have fuuun everybody ! yes. regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] python inspect issue
Hi there. I have discovered weird behaviour while debugging a doctest in dynamic_class.py. A minimal example looks like this: $ ./sage -t src/sage/structure/dynamic_class.py [..] passed! [..] $ touch local/lib/python2.7/site-packages/sage/structure/dynamic_class.py $ ./sage -t src/sage/structure/dynamic_class.py [..] inspect.getfile(Foo2) Expected: '.../sage/structure/dynamic_class.pyc' Got: '.../local/lib/python2.7/site-packages/sage/structure/dynamic_class.py' [..] The reason is, that py_compile.compile() produces bytecode different from what a python call silently creates (other than that, there _seems_ to be no difference). Now in general, there is nothing wrong with silently generated pyc files, so imo there shouldn't be a problem in this case. The simplest solution would be just expecting '.../sage/structure/dynamic_class.py...', as this will not only pass the test, but also documents the randomness. Is there anything else within the sage library that relies on one or the other outcome of a getfile call? regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] midterm and status
Hi there I have submitted the midterm evaluation form yesterday, as i won't be online during the next week. Some words on the overall status: - I have worked out a place to store run time variables. these need to be ripped out of sage-script (src/bin), and must be taken care by the specific spkg-install scripts. I have created a (still dummy) "sagelib" package for that reason. unlike on debian it does not yet make sense to build sagelib-on-sage-the-distribution as a whole. - Most things work in classic mode (i.e. "compile everything"). some failing doctests are due to hardcoded run time paths, and must still be taken care of. - It's possible to disable packages, and fallback to system packages. this works with the old and plain spkg-install programs, without additional overhead. disabling packages must be supported by the packages that remain enabled (this is done by adapting spkg-install). - uninstallation of packages is now supported. also it's possible to create binary tarballs for system-wide installation. exporting source-packages and/or ebuilds needs some work, but should be simple to implement. (see toplevel INSTALL for directions). - sagelib now builds on debian (apart from doc), with some unstable/experimental packages and manually installed pari. I am working on getting rid of the segfaults (then also build doc). Packaging for debian will be trivial, and will mostly consist of collecting version numbers... After midterm I will concentrate on cleanup and a transition path from the current to the new build. Certainly some aspects are open, like - "relocation" (= move the source tree around, and don't recompile) - create ebuilds, so they are of any use. - how will branch-hopping look like (or: should the package sources be deleted after compilation?) - how will additional/custom spkg installs look like in non-sage-the-distribution context? I'm sure you will find even more issues. I'm curious to hear about them. Don't hesitate to suggest solutions. regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] spkg statistics
Hi there.
On Fri, Jul 05, 2013 at 04:00:39PM +0200, Harald Schilly wrote:
> splitting it apart for debian does happen right now.
what does "not compiling python if its already there" to do with
"splitting apart"? (replace "python" with any other packagename).
indeed its just the contrary, I am working on a build system that will
eventually put all core parts of sage in one huge package ("sagelib").
> e.g. sage-highschool == "sympy + ipython + matplotlib" in my point of view.
package presets on toplevel would be totally great! parts of the sage
python library already are optional, making the others optional should
be feasible in a similar way...
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] sage build system project progress
Hi there.
A draft of the build systems for sage is now available on github [1].
The commits are based on the "working" branch, which represents the
current transition from hg to git.
The top level build system now not only disables unneeded packages
automatically (e.g. gcc, iconv), but also allows disabling any package
manually, by configuring with --disable-. for this to work,
each package needs to provide its own runtime configuration (currently
hardwired within sage-env). whether or not disabling a package already
makes sense depends mostly on the other packages, for example python can
only be disabled once/because all other packages know where to find
python. *not* disabling a package does not/should not/must not change
anything relative to the current way sage works. I am trying to
non-destructively introduce that infrastructure into Sage [2], but maybe
I am not aware of all implications yet.
It will then be possible to uninstall packages from $SAGE_LOCAL manually
by typing make -(un)install. Uninstallation relies on the
capabilities of the spkg-install, and currently more or less works for
rpy2, singular, mpir, sagetex, matplotlib and some others. this is
implemented by replacing the install program (for make-based upstream
build systems) and by overriding parts of the file operation routines
(in the distutils case). whether or not this works can be checked with
the -distcheck target, which compares the list of actually
installed files with the list of files the build system claims to have
installed. Once an spkg-install file has been modified/augmented, it
will be easy to export source or binary packages of the corresponding
package.
There is now also a unified build system for sage ("the library"). On a
system that matches all requirements, it should be possible to
build/install the parts within /src in one go, with
./configure; make (install) (and create tarballs with make dist).
This is pretty much untested, and currently lacks a lot of checks. On
gentoo, or within sage -sh, it might do anything useful already. On
debian, several dependencies are not met yet [3], [4]. some are of the
type "need a patch for sage to work with upstream" (e.g. cliquer), some
are "sage needs support for current upstream" (e.g. singular), but also
there are unresolved license issues (singular), and problems far worse
than that (ecl, maxima, ...). I could need any help here, and i will
certainly not be able to resolve all of these myself.
I have some hope to run (=pass tests within) a sage-the-distribution
with several packages disabled (lets call it "hybrid-mode" maybe?) on
top of debian some day. this might give an insight on which packages are
not just available, but also work for sage, if they are just installed
in a conventional way. For this I need all packages either within
debian or hybrid-ready one within sage-the-distribution...
regards
felix
[1] git://github.com/felix-salfelder/sage.git
[2] http://trac.sagemath.org/sage_trac/ticket/14804
[3] http://http://wiki.debian.org/DebianScience/Sage
[4] http://people.debian.org/~thansen/debian-sage-status.html
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] SAGE_ATLAS_LIB and sage -bdist
On Tue, Jun 11, 2013 at 11:47:48AM +0200, Julien Puydt wrote: > Le 11/06/2013 11:33, Volker Braun a écrit : > >I'd say archiving the symlink is exactly what you'd want. If you use > >system libraries for compiling Sage then they become dependencies of the > >binary distribution, obviously. > > What would break if they were copied instead of linked? a binary dist is supposed to work on a machine that looks the same as the one it was compiled on, hence the symlink is fine. thats why you should always use *source* distributions that ship a sane build system instead. > The current answers look more like the usual "No, because it's > different from what we do now!" than like a technical discussion... not this time, i think :D regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Sage on Windows
On Thu, May 30, 2013 at 09:43:17AM +0200, Jeroen Demeyer wrote:
> On 05/30/2013 12:08 AM, rjf wrote:
> >This project, and the one below, suggest that people are going to
> >continue to ignore the elephant not
> >in the Operating System Room, namely native Windows XP, Vista, 7, 8 ...
> Windows support is very far from being ignored. In fact, there
> exists a usable version of Sage using Cygwin. It doesn't work 100%
> and there are some DLL rebasing issues, but it mostly works.
depends on what "native" means. for debian i'd suspect native is
"without the distribution". on redmond i think rjf is pointing to at
least "without cygwin" (which looks far more difficult).
but why not stick to cygwin and package sage for cygwin? just think of
cygwin as a gnu-like distribution and read the fine print of the
debian-sage project ("the one below")...
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] GSoC project, build system -- getting started
Hi there.
currently debian does not provide all dependencies required to compile
the sage python modules or lib_c, i would like to start with a build
system for sage ("the distribution") and postpone the other parts a bit.
that build system is supposed to allow the user disable the build of
specific packages/modules or (later) compute a minimal set of required
packages, depending on what the host OS provides. for now i just need
the "disable" part. and some design decisions.
one package contains the sage python library (lets call it lib), which
is included within the git repo. other than the foreign packages within
build/pkgs, lib does not technically require a sage-install script to
wrap the installer. on the other hand, i'm going to implement a build
system for lib, so it can be installed with just "./configure; make
install".
so i need to choose one of
[1] sage ("the distribution") installs *all* packages by calling
./configure; make install; i.e. i have to add a (dummy?) configure
and wrapper Makefile to every directory within build/pkgs. this will
simplify sage ("the distribution") a bit, but is more work and more
flexibility on the package side.
[2] sage ("the distribution") handles two types of modules/packages.
foreigns will be installed using spkg-install, lib will be installed
using the corresponding build system directly.
[3] a wrapper script called "sage-install" is used to install lib, so all
packages will have the same interface again (but no flexibility).
[4] something completely different i am not aware of.
actually, for the moment, just [1] and [2] look sane to me, i'd prefer
[2], as long as spkg-install fits all needs (does it?).
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] GSoC project, build system
Hi Mentors, hi sage-devel.
my project [1] has been accepted. this project is about
improving/implementing build systems for sage ("the distribution") and
its parts. i'm glad there are four mentors that voluntarily support
this project. thank you for the effort!
i am a phD student (computer science) in frankfurt, not so much of a
sage user, but a debian user. i'd like to simplify access to sage as
much as possible -- particularly, but not limited to debian.
as the precendent discussion on sage-devel indicates, there are
different possible ways to implement things, i'd like to choose the
simplest (sometimes the most elegant) ones, that satisfy all/most
requirements. lets dicuss the details here on sage-devel. i'd like to
invite all sage-developers and package-maintainers to post their
do(n't)'s and wishes.
i will somehow establish a sort of blog [2] where i will document the
progress of the project.
regards
felix
[1] http://www.google-melange.com/gsoc/project/google/gsoc2013/felixs/24001
[2] http://felix.salfelder.org/sage-gsoc/
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] proposal: make the Sage build system more distribution friendly
On Sun, Apr 28, 2013 at 11:35:43PM +0200, Jeroen Demeyer wrote: > I think the problem was mainly unclarity with the definition of > "module". I thought you wanted to split up the sources into > different repos, like we have now. And that's the only thing I am > against. hi Jeroen. that's great. in fact some details were confusing witin my first proposals, as i didn't take into account the git-transition... but while we are at it: eventually, theres not even a need for a monolithic build system within /src? so there's no need to change the proposal much (but make it more verbose about what a module is.), correct? thanks felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] proposal: make the Sage build system more distribution friendly
On Mon, Apr 22, 2013 at 05:15:30PM +0200, Jeroen Demeyer wrote:
> 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.
Dear Jeroen,
I would really like to do that project, and i'm trying hard to
understand your objections against modules. maybe i will understand some
day.
to get this going i'd like to make a change, that should lead around
that issue before the end of the application period.
A I restate the project goals to
"""
make it possible to
1) build sage ("the distribution") by typing ./configure && make
2) build/install sage ("the library") with
./configure --just-library --prefix=whatever && make install
3) build/install sage ("the program") with
./configure --sagetheprogram --prefix=whatever && make install
and make sage distribution friendly.
"""
B i'll implement this in a modular way. one module gets one configurable
build system. (a module roughly is a subdirectory of src).
C i'll then target a monolithic, standalone build system for sage ("the
library"), which is the stuff in /src.
I understand that it's C, you are after (is that right?). i'm conviced, I
can make A work by B. if theres nothing within sage that blocks C, there
will be nothing left that blocks C. In that case I expect that I can
concat the configure scripts from B within two hours -- and reach C.
would that be acceptable for you? anything else maybe?
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] proposal: make the Sage build system more distribution friendly (update)
Hi Tobias.
On Wed, Apr 24, 2013 at 02:47:06PM +0200, Tobias Hansen wrote:
> On 04/24/2013 11:46 AM, Felix Salfelder wrote:
> >part of my proposal is
> >to make it possible to just install sage ("the distribution") skipping
> >everything but the core modules and the notebook.
>
> So your plan is to make it possible to run configure and make for
> each directory in /src separately
yes.
> but since we want to
> build all of Sage the program
not from that source package. the notebook is a part of sage ("the
program") but not part of /src. it's currently part of sage
("the distribution"). i think sage ("the program") should be implemented
as a flavor of sage ("the distribution").
sage-notebook is an almost trivial-to-package python-module with its own
source package. we shouldn't change that.
> you will also allow doing that in one
> go (described in the quoted text)
yes, that would be sage ("the distribution"). this will also take care
about foreign modules. foreign modules, their build systems and the
corresponding glue code have nothing to do with debian and will be
excluded.
> and use that to avoid multiple
> invocations of configure and make in debian/rules?
debian rules will have to walk through all modules (if we stick to one
source package). that's what sage ("the distribution") will have to do
as well (and currently does, in an unspecified way).
an extra configure script in between will never meet all requirements
and finally bitrot. this will cause sage ("the distribution") not use it
when adding/changing submodules and we are back to start.
> I find this is
> still a bit unclear in your proposal draft.
i hope it's clear now. i'll add it to the next version of my proposal.
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] proposal: make the Sage build system more distribution friendly (update)
On Tue, Apr 23, 2013 at 06:08:54PM -0300, Paulo César Pereira de Andrade wrote:
> I will make a few comments, attempting to be as constructive
> as possible :-)
Hi Paolo, hi list.
Thanks for going through all this. i'll consider your comments as far
as the scope of this project allows.
> The biggest problem is compatibility of version of the components.
> Sagemath works in its current setup due to bundling most components,
> so that it can be built on a 3 year old distribution as well as on a
> bleeding edge one.
... compiling all of its dependencies. part of my proposal is
to make it possible to just install sage ("the distribution") skipping
everything but the core modules and the notebook.
depending on the changes needed within the foreign packages (read
"spkg-install or successor"), this could quickly evolve to --(un)skip
options for all modules. so even on a 3 year old distribution sage ("the
distribution") may run with less compilation effort.
there is hope that, once people start using sage ("the distribution")
using their own versions of dependencies, sage will start to
accept/incorporate small patches working around the smaller issues
(controlled by ./configure).
> [..]
> Some more strict rules on spkg would
> make it actually easier to get sagemath integrated in distributions,
> example:
> o avoid carrying patches that upstream does not accept,
>or were never submitted upstream.
that has reduced significantly in the past. almost all sage dependencies
are avaible in debian right now (and sage-ready). this is mostly due to
Julien Puydt. submitting upstream is his favourite way.
> o avoid creating spkgs of software that does not have a home
> page, or that is a snapshot of something without any ETA to
> be released, and not available anywhere for download.
as soon as what i call "embedded modules" works for sage ("the
distribution"), adding more code/modules to the git repo will be
painless. it will not complicate or disrupt the build system. (i'm
still arguing that this is the only way to go).
> One example is scons usage, that I patch to generate a more
> standard library:
> [..]
nobody should have to patch build systems. if (because) scons doesnt
work, i'll replace it. patches that work under any conditions can be
easily accepted upstream.
> > An autotools build system can be used easily by package generation
> > scripts such as debhelper (creating Debian packages) and can be called
> > from within sage ("the distribution"). The difference between these uses
> > consists in passing different flags to the corresponding "configure"
> > script.
> >
> > This sums up to three tasks
> > 1 write/exchange the build systems for the core parts (c_lib,
> > python-sage, sage-scripts, extcode, ...).
>
> c_lib should be split out of the sage-$version directory. This way,
> IMO, there is not much of a need to change how the core python
> modules are built. Well, I would be happy enough to not need to
> add this pseudo patch:
c_lib is currently in /src and will/should be treated as a
module. there will be no sage-$version package anylonger.
debian will distribute the contents of /src (as a source
package). you may choose to pick the subdirectories seperately.
> +if os.environ.has_key('DESTDIR'):
> +DESTDIR = os.environ['DESTDIR']
> +else:
> +DESTDIR = ''
> [...]
> -pyx_inst_file = '%s/%s'%(SITE_PACKAGES, f)
> +pyx_inst_file = '%s%s/%s'%(DESTDIR, SITE_PACKAGES, f)
>
> to setup.py.
i will most likely replace setup.py by a template, filled from
./configure. (or replaced completely by Makefile.am's, depending what
works better). in any case, all build systems i'm going to write will
implement
- --prefix option for ./configure
- make install target honouring DESTDIR (the way you propose or another)
in particular, all build systems will be interfaced by configure/make,
which will then be consistent throughout all core modules, and finally
be ready to use for sage ("the distribution") without further glue code.
> > 1 - carefully read setup.py (within the sage-git-transition repo)
> > - implement checks for headers and libraries
> > - implement configure switches where needed
>
> I see this as a great improvement, but also consider adding checks
> in the more pythonic way to the "current" build system.
please enlighten me about what the pythonic way is. does it support a
configure/make interface?
> > 3 - install dependencies on a debian machine
> > - compile everything
> > - prepare sage-scripts for system wide installation
>
> My current approach is to add the location of sage scripts
> to $PATH, and besides some symbolic links from system
> directories to SAGE_ROOT, in most sage scripts I just
> remove in a patch the hardcoded $SAGE_LOCAL/bin
> prefix to binaries.
$PATH should be default in non-sage-("the distribution") cases. other
paths should be handled by proper -I and -L etc. *FLAGS. symlinks are bad.
> > There is hardly any risk, that
Re: [sage-devel] proposal: make the Sage build system more distribution friendly (update)
Hi There
i have updated my proposal, taking into account the discussion. I've
mostly extended the Details section. Thanks for reading.
=== Title, Project Synopsis
"Get Sage ready for Linux distributions"
Sage is currently shipped as a software distribution that, next to
genuine code, includes all dependencies as foreign packages.
Moreover, the core library and python modules cannot be compiled in a
straightforward way, as most linux distributions expect. Aim of this
project is to detach the build process of sage ("the software") from
sage ("the distribution"). The goal is a build system that works within
the context of sage as well as for any gnu/linux distribution that ships
the dependencies for sage.
=== Personal involvement/relationship
To me, a Debian user, who likes maths (and doesn't like big Ms), this
project fills an obvious gap. I have already worked on packaging sage
dependencies for debian occasionally. There, I have learned some of the
basics of packaging and software distribution. I found out that a
package for sage cannot be done overnight...
=== Details
Switching the build system of the core parts to autotools allows
implementing a standard interface to build and install the software.
Such a build system includes a mechanism to figure out the
availibility/names/locations of tools/headers/libraries and adapts the
build/install process accordingly.
An autotools build system can be used easily by package generation
scripts such as debhelper (creating Debian packages) and can be called
from within sage ("the distribution"). The difference between these uses
consists in passing different flags to the corresponding "configure"
script.
This sums up to three tasks
1 write/exchange the build systems for the core parts (c_lib,
python-sage, sage-scripts, extcode, ...).
2 modify sage ("the distribution") to use the new build systems instead
of running 'setup.py'.
3 build stand-alone sage, draft debian packages, figure out dependencies
which split up into [optional in brackets]
1 - carefully read setup.py (within the sage-git-transition repo)
- implement checks for headers and libraries
- implement configure switches where needed
- find convenient/flexible way of writing down targets (Makefile.am
layout etc.)
- templatize {module_list,setup}.py or convert to Makefile.ams.
- figure out run-time-paths, patch where needed.
- sort out sage-scripts, make paths configurable
- handle the other directories in src
2 - compile sage ("the distribution")
- carefully read top-level Makefile
- somehow handle sage-scripts ("bin") and doc
- figure out configure environment/switches needed within sage
- (add additional options if/where needed)
- adapt toplevel Makefile module installation
- run test suite...
- [draft "toplevel configure"]
3 - install dependencies on a debian machine
- compile everything
- prepare sage-scripts for system wide installation
- create source package out of /src
- write control file/rules etc.
- run tests on debian [gentoo]
- [package sage-notebook]
Interfaces
Currently there is one static Makefile in the toplevel directory that triggers
the build process of all packages and installs them into a local directory.
The new build system will expose the following interfaces
- Configurable build systems for all modules
- A configurable build for sage ("the distribution")
The build systems for the core (non-foreign) modules are meant to be used by
distributions (like debian) in a straightforward way. This is done by
picking out the embedded modules for packaging. For debian that means,
the /src directory will make (exactly) one source package, from
which all the modules are built.
Sage ("the distribution") will permit builds in different flavours,
controlled by the configure script
- same as before (default)
- install core+notebook (sage "the program")
- skip a subset of the modules (optional within this project)
- skip modules that are already installed elsewhere (beyond the scope of this
project, needs changes in external module handling)
Rationale
This proposal targets distribution-friendliness by exploiting the modular
structure. Once every module can be built in a straightforrward way, any
(linux) distribution can package it.
Making sage ("the distribution") use these build systems internally is a key
feature. This is the proposed way to make sure that packages created today will
work with sage releases tomorrow.
Discussion
There is some controversy on the sage-devel mailing list [2]. I'll list
the key objection and explain how I'm trying to deal with them.
- (embedded) modules is too much work.
It's true that modularization has its price. Before the git-transition Sage was
using modules (spkgs) for its parts (even without distribution friendliness).
This project will in fact revert some of the modularization loss, and will
demonstrate that using modules is even less work in the long run.
- when installing (one/all) sage core
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 and the scripts make no sense > > >without Sage. > > (see the other posts about why this is not entirely correct) well, it's almost. it's just that libcsage doesnt build-depend on python-sage. i am starting to mix up the posts about scripts and modules and python... sorry felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
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 why this is not entirely correct)
> It seems to me these three things belong into a Debian source
> package together and Sage should provide configure, build and
> install targets for them together (don't know if real configure
> script/makefile or a script invoking multiple other builds). The
> Debian source package would split the resulting files into binary
> packages python-sage, libsagec etc. which is a standard thing we do
> for most large projects we package in Debian.
i agree that it the contents of /src could make one
debian source package. this is what Andrew calls sage ("the program").
a common build system for these would still break gentoo and include
sage-scripts which i think should be moved (completely/partly?) to sage
("the distribution").
also /src contains more than just sage-scripts (src/bin),
sage-python (src/sage) and libcsage (src_c/lib). namely ext, doc and
mac-app. finally i expect even more modules to populate src/ so i'd like
to face it and write a build system for each of them (whether or not
sage ("the file server") provides them as seperate tarballs).
why?
0 simple structure, no exceptions
1 to keep build systems small and maintainable
2 to keep debian/rules simple and maintainable
3 to make gentoo happy (libc and sage-python issue)
4 to keep modules apart, painlessly add more (non-foreign) modules
5 to make sage ("the distribution") simple
6 to keep the directory structure
7 to support other kinds of distribution
details
0 exceptions are bad, and need someone who understands them
1 less checks, clear context, easier to write/read/debug, also for
non-experts
2 one build process for each package, clear distinction of targets,
different DESTDIRs
3 gentoo is weird, but why not?
4 some modules are unrelated, believe it or not.
importing sage-notebook into src/ (as proposed by Jeroen) wouldn't
require any changes to the configure logic.
5 sage ("the distribution") is modular wrt to the foreign packages. it
shouln't treat parts different depending on where the source resides.
a --skip- is easier if every module is a module.
6 not changing the directories in src/ will definitely not break the
current build. this makes sense, because it's not complete yet.
7 you can *never* know which module of sage may be useful to someone for
some reason or other
so if the outcome is one module too many, a merge is trivial. the other
direction is certainly not.
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
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
> improvements you make for packaging will benefit our work, too.
i hope so. please tell me if there's anything to be considered.
> 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 this about installing a most recent version of sage on a stable
debian system?
sage-specific deb packages will (probably) never be part of debian. i
expect sage developers to take more care about pushing patches upstream
in the future. so the way to go would be backports for fresh debian
packages or fallback to sage ("the distribution") (or a successor).
hopefully some day sage ("the distribution") can be configured with
--just-install-needed ...
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
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 repo) by some version of Gentoo's portage. This > > > would be similar to the lmonade project, except that it's trying to be a > > > smooth transition from the current source distribution. > > are you targeting sage-upstream or is this a local hack that is doomed > > to fail some releases (and several git-transitions) later? > We're targeting sage/git upstream. is this planned to be part of sage? then i'd suspect you are trying to rewrite sage "the distribution". would it help to have build-systems for the (non foreign) parts of sage? > You don't have to use portage. If all spkgs are debian packages, then > there is no point in using portage since you won't be using any spkgs > anyway. You could of course use it as part of the build process and > unmerge portage in a final step to remove it again. packaging into .deb instead of .spkg as in my first proposal does the trick (for debian), as long as sage uses spkgs. a distribution friendly build system for some, including libcsage/sage-python is missing nevertheless. have you written one? > I don't believe it is gentoo centric. Actually, I'm not even using > gentoo myself anymore. > The current SPKG approach has its problems, especially with the new git > layout. One main problem being that you cannot uninstall an SPKG when > you switch to a branch where it is not present. That's where we want to > use portage. I at least don't think of portage here as a distribution > system, but just as a tool to configure/install/uninstall things in a > local prefix. 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 missing -- so packages can also be built for debian, gentoo, whatever-you-like. but i'm interested in how you handle it! regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
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
> smooth transition from the current source distribution.
are you targeting sage-upstream or is this a local hack that is doomed
to fail some releases (and several git-transitions) later?
> As soon as this works, then it would be possible to use this to generate
> debian packages, since portage keeps track of installed binary files for
> packages. So the debian/rules file could query portage for which files
> should go into which binary package.
the goal of the/my gsoc project would be streamlining the packaging of
debian/gentoo/whatever packaging process. having to use an extra layer
("portage"), makes things worse. no debian maintainer i can think of
would seriously use it.
> The only technical obtacle I can think of is that you'll likely want to
> eventually install the sage tree somewhere under /usr/lib/sage, or
> /opt/sage or something. So portage should compile for that prefix. But it
> should "install" under debian/tmp. That should be possible, especially
> since portage uses its own DESTDIR too.
any sane build system understands --prefix and DESTDIR, also the ones
i'm proposing to write. (but install paths is not everything.)
how about talking about build systems for the sage modules that suit
all, including sage ("the distribution") gentoo and debian? you could
help explain to sage developers, why modularization and build systems
are inevitable...
regards
felix
PS: i don't want to make your work obsolete, but it's obviously too
gentoo centric
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
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). you could help explaining why this really makes sense. nobody should have to ditch his own packages and/or do duplicate work. regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
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 Sage Python
> library, the Sage Python library requires libcsage and the scripts
> make no sense without Sage.
being a module doesnt imply "makes sense standalone". so there is no
contradiction. sage-python depends on libcsage, but libcsage can be
built without sage-python. the scripts make no sense without sage, but
sage makes perfect sense without the scripts. extcode and what-not may
have different dependencies. why not leave these choices to the user?
> >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-sage and sagenb seperated.
> sagenb is a separate project, at least on paper. Currently Sage
> doesn't work without sagenb, but one could argue that's a bug.
if the notebook is convenient for many, then one should set
"--enable-notebook" the default in sage ("the distribution").
sage ships a python library that works perfectly well /without/ the
notebook. try
$ python
> from sage import all
or just
$ sage
>
so it would be a bug, if the notebook was obligatory. also consider,
that the notebook is intended as frontend for other software as well.
if /currently/ sage doesnt work without the notebook or the notebook
doesnt work standalone (which might be the case), there is no reason to
complicate these uses further. what you suggest makes --disable-notebook
and packaging the notebook ultimately impossible (and that would be a
different project).
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
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 started my first proposal). > >switching to git is a great idea. if submodules/externals are to > >complicated to use, subdirectories are less meaningful but still great > >in seperating parts. > For me, modularity means that the external packages (such as GCC, > Python, ATLAS, GAP,...) can be removed from Sage and a system > version could be used. I don't see the advantage of Sage itself > (scripts + Python library + C library) being modular. Hi Jeroen. 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-sage and sagenb seperated. for gentoo it makes sense to have c_lib seperated. most importantly: /keep/ things seperated, so distributions can pick it up (and can pick it up tomorrow, after someone has reinvented sage "the distribution"). regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
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, just doesn't have any of the necessary
> checks).
>
> On Sun, Apr 21, 2013 at 6:05 AM, Felix Salfelder wrote:
>
> > a configure script would locate headers depending on the flags
> > (--with-ntl=/here/or/there ...), does a check (optional) and then sets
> > CFLAGS/wheteverFLAGS accordingly. Cython is used to write .c out of
> > .pyx, i don't see why/how it could care about configure options.
> >
> > (just to be sure: what does it have to do with a dependency tree?)
> >
>
> More the point is that you do not want to directly call the terminal
> command for cython -- rather you want
> to call cythonize on a python list of modules, as it regenerates c files if
> the corresponding pyx file is touched or if any file that the pyx depends
> on is touched. Moreover, it provides extra functionality (such as cycache:
> ccache for cython) that we will likely want to take advantage of.
(of course files need to be regenerated in case dependencies change)
> So at some point a python module like module_list.py will have to be used,
> potentially generated.
somewhere there must be list of files/rules. i don't see why it must be
a *python module*. Makefiles would be probably less magic and more
transparent (is this another topic?). anyohow i don't see a link to
checking functionality.
checking for headers/libraries/availibility is done by the configure
script. it is meant to either break if something is missing or set paths
accordingly. cython/cythonize/gcc/whatever is called much later.
> > No, I did not me a top-level build system -- as I see it there are three
> > > embedded levels of sage:
> > >
> > > 1) sage as a python library
> > > 2) sage as a program (i.e. the terminal command prompt/notebook)
> > > 3) sage as a distribution.
> >
> > sage as a program is in /src/bin. there used to be
> > a sage-scripts.spkg. notebook is another package...
> > yes, these need also be considered modules/packages.
> >
>
> By "sage as a program" is almost everything under src (some scripts in
> src/bin are only needed for distribution purposes).
okay, so sage the program is not the sage executable. almost obvious :)
(2) does not contain the notebook. the notebook is a module (as it
should).
unrelated parts of src/bin should be moved to where they are needed.
> As a person who frequently compiles software from source I have a big
> objection to breaking up the configuration of "sage as a program" into
> multiple components, it complicates the process for someone who has all the
> dependencies and just wants to build a copy of sage.
sage "the program" is not functional without either a software distribution or
sage "the distribution", so why bother? "a copy of sage" is not well
defined either. so no -- i don't see any complication in handling
modules as modules. there's virtually no overhead in modules, as sage
("the distribution") will always have to care about foreign modules.
> By default I think
> that `./configure && make && make install` should setup a makefile that
> will build and install all of "sage as a program". If you want more
> modularity you could have an extra configure flag
the topic of the gsoc project is "make sage distribution friendly". this
forbids to add another extra layer that is of no use for distributions.
what you probably want to do, when you write "install all of \"sage as a
program\"" is install ("sage the distribution" minus "foreign
packages"). this is a legitimate goal, and should be implemented as
./configure --skip-foreign --enable-notebook && make install
(details may vary) within a tarball of sage "the distribution".
why would you want to install sage "the program" without the ability to
install other modules? why would you want to use the toplevel
("distribution") configure script to do this? there will always be
another package that makes even less sense to merge into the
distribution tarball.
> --with-csage=PATH uses csage at path instead of building its own copy
> of csage
>
> and separate make targets for installing the various components
>
> make install_bin
> make install_lib
> make install_extcode
> make install_csage
> make install_doc
make targets without configurability are of no use (for distributions).
if packaging sage (w
Re: [sage-devel] proposal: make the Sage build system more distribution friendly
On Sun, Apr 21, 2013 at 12:17:33PM +0200, Felix Salfelder wrote:
> 1 write/exchange the build systems for the core parts (c_lib,
> python-sage, extcode...).
> 2 modify sage ("the distribution") to use the new build systems instead
> of running 'setup.py'.
> 3 build stand-alone sage, draft debian packages, figure out dependencies
I must add sage-scripts (currently the directory /src/bin)
to (1). it seems to be more work.
my approach would be to use a configure script to find other programs and then
-- before installation -- replace things like
grep -i version "$SAGE_LOCAL/bin/sage-banner"
by
grep -i version "@sage-banner@"
and
if [ "$1" = '-gap' -o "$1" = '--gap' ]; then
shift
exec "$SAGE_LOCAL/bin/gap" "$@"
fi
by
if [ "$1" = '-gap' -o "$1" = '--gap' ]; then
shift
exec "@gap@" "$@"
fi
then within an ordinary distribution one could simply set
@sage-banner@ to sage-banner and @gap@ to gap.
when installing for sage ("the distribution"), the configure script can
substitute @sage-banner@ for $SAGE_LOCAL/bin/sage-banner and choose
@gap@ to be either $SAGE_LOCAL/bin/gap or "/whatever/prefix/for/gap", depending
on where gap can be found.
(any problems with this? better ideas?)
but i'm curious: why doesn't sage simply use $PATH to locate executables? this
looks quite involved, what's the point?
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] proposal: make the Sage build system more distribution friendly
On Sun, Apr 21, 2013 at 05:22:30AM -0700, R. Andrew Ohana wrote:
> > it's not completely rewriting, think of it as modularization/conversion
> > (while adding checks for availability/headers/libraries and the like).
> >
>
> 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, just doesn't have any of the necessary
> checks).
a configure script would locate headers depending on the flags
(--with-ntl=/here/or/there ...), does a check (optional) and then sets
CFLAGS/wheteverFLAGS accordingly. Cython is used to write .c out of
.pyx, i don't see why/how it could care about configure options.
(just to be sure: what does it have to do with a dependency tree?)
> No, I did not me a top-level build system -- as I see it there are three
> embedded levels of sage:
>
> 1) sage as a python library
> 2) sage as a program (i.e. the terminal command prompt/notebook)
> 3) sage as a distribution.
sage as a program is in /src/bin. there used to be
a sage-scripts.spkg. notebook is another package...
yes, these need also be considered modules/packages.
> Currently you can only get to 1 and 2 as components of 3, and the goal of
> this project is to make it more modular so as to be able to get at 1 and 2
> outside of 3.
agreed.
> To me it makes the most sense to have a single configure
> script for 2 (as a set), with a configure flag to just build 1, the python
> library (if so desired).
in the end, sage ("the distribution"), i.e. the top-level-stuff, must
take care of building/installing the modules in the right order. having
one module that builds another undermines this logic.
so for example, if you want to install 1) and 2), there would be three
options
- your linux distribution already ships 1) and 2)
- use 3)
- just install 1) and 2) manually (but why?)
> A top-level configure script (from how take people to use the term), would
> be a configure script for 3.
agreed. at best one that allows you to select just 1) and 2).
> > it might make sense to call distutils from an autotools Makefile (at
> > least for the python part).
>
> I guess I was a bit unclear, this is what I meant.
i can investigate that.
regards
felix
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] proposal: make the Sage build system more distribution friendly
Hi Andrew. thanks for your comments. On Sun, Apr 21, 2013 at 03:47:36AM -0700, R. Andrew Ohana wrote: > When you say "write/exchange the build systems for the core parts (c_lib, > python-sage, extcode...)" what exactly is your goal? currently, the modules c_lib and sage-python etc. don't have a dedicated build systems goal is, to create build systems for these modules, taking over the role of ../setup.py > I don't think it makes much sense completely rewriting the setup.py/modules, > especially in Makefile (as it sounds like you might have been thinking). it's not completely rewriting, think of it as modularization/conversion (while adding checks for availibility/headers/libraries and the like). > If you are looking for making an autotools based build system (here > assuming part of your goal for (1) is to make a single configure for all of > "sage as a program") no. (1) is not about a top-level build system. (a top-level build system is another story and relies on configurable modules. lets discuss it!) > then I would suggest just calling `python setup.py > build` and `python setup.py install` in the appropriate places. setup.py doesnt do what is needed, when packaging for a distribution. writing a script that calls "setup.py install" doesnt make that module distributable either. it might make sense to call distutils from an autotools Makefile (at least for the python part). looking at how setup.py works around dependencies and implements parallelization, i doubt anyone will seriously regret the conversion. regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] proposal: make the Sage build system more distribution friendly
On Thu, Mar 28, 2013 at 01:14:10AM +0100, Tobias Hansen wrote:
> Two people from Sage, Jeroen Demeyer and John Palmieri, volunteered to
> cover the Sage side of mentoring the project. Julien Puydt, who already
> put a lot of work into packaging Sage dependencies for Debian, is also
> on board. All we need now is a student.
Hi there.
I'd like to draft a project proposal corresponding to this idea [1]
following the proposal template. Comments are welcome.
=== Title, Project Synopsis
"Get Sage ready for Linux distributions"
Sage is currently shipped as a software distribution that, next to
genuine code, includes all dependencies as foreign packages.
Moreover, the core library and python modules cannot be compiled in a
straightforward way, as most linux distributions expect. Aim of this
project is to detach the build process of sage ("the software") from
sage ("the distribution"). The goal is a build system that works within
the context of sage as well as for any gnu/linux distribution that ships
the dependencies for sage.
=== Personal involvement/relationship
To me, a Debian user, who likes maths (and doesn't like big Ms), this
project fills an obvious gap. I have already worked on packaging sage
dependencies for debian occasionally. There, I have learned some of the
basics of packaging and software distribution. I found out that a
package for sage cannot be done overnight...
=== Details
Switching the build system of the core parts to autotools allows
implementing a standard interface to build and install the software.
Such a build system includes a mechanism to figure out the
availibility/names/locations of tools/headers/libraries and adapts the
build/install process accordingly.
An autotools build system can be used easily by package generation
scripts such as debhelper (creating Debian packages) and can be called
from within sage ("the distribution"). The difference between these uses
consists in passing different flags to the corresponding "configure"
script.
This sums up to three tasks
1 write/exchange the build systems for the core parts (c_lib,
python-sage, extcode...).
2 modify sage ("the distribution") to use the new build systems instead
of running 'setup.py'.
3 build stand-alone sage, draft debian packages, figure out dependencies
which split up into [optional in brackets]
1 - carefully read setup.py (within the sage-git-transition repo)
- implement checks for headers and libraries
- implement configure switches where needed
- find convenient/flexible way of writing down targets (Makefile.am
layout)
- convert module_list.py to Makefile.ams. automatically if possible.
- figure out run-time-paths, patch where needed.
2 - compile sage ("the distribution")
- figure out configure environment/switches needed within sage
- (add additional options if/where needed)
- somehow handle sage-scripts ("bin") and doc
- run test suite...
- [discuss how "toplevel configure" can be done]
3 - install dependencies
- compile everything
- discuss appropriate number of source packages
- write control files etc.
- prepare sage-scripts for system wide installation
- run tests on debian [gentoo]
- [package sage-doc]
=== Schedule
During the GSoC period I have no university work obligations as I'm on
parental leave.
- I won't be at home May 3 till May 19. still trying to stay connected
- From July 27 to Aug 4 I will be most likely unavailable
- i'll be away another two weeks in summer (Jul/Aug), not fixed yet.
=== Risk Management
The tasks list includes the inevitable parts and doesn't promise an
instant switch to a different build system. This would be the ultimate
goal for the sage project, beyond the scope of a GSoC project.
There is hardly any risk, that work done within this project turns out
to be useless. If difficulties occur, the modularity of the approach
allows postponing problems in 1 while still continuing to work on 2 and
3. On the other hand, if time permits, I can work out the optional
parts.
regards
felix
[1]
https://docs.google.com/document/d/1ipzvwbhfujaubDe0QVO-V9JmmRcLZvitaeXh4r2WNqA/pub#h.pty9ayy9wo8
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
hi there. On Fri, Apr 12, 2013 at 05:13:14PM -0600, David Roe wrote: > But speaking as someone who contributes a lot to the Sage library itself, > I'm strongly in support of Robert Bradshaw's proposal that we combine the > different Sage repositories (root, devel, script and ext). It's much > easier to work on issues that involve code in these different repositories > once you only have to make a commit to a single unified repo. i'm not a sage developer, but i get your point (apart from "root" - which doesn't contain a single line of code). missing useful git support for submodules is the force appearently. > I'm not sure whether the spkgs you refer to correspond to the four > repositories I mentioned above, but if so then the merging is intended to > be permanent. in turn, i cannot associate any of the four repositories above to the (former) spkg "sage.spkg". additionally http://hg.sagemath.org/sage-root is dead, but iirc it contains the toplevel Makefile and README. i think, we are talking about the same merge... > > To the git transition team: Have you considered using git submodules for > > the different Sage components? It would certainly solve this issue. > > Would it also have other advantages? Is there a reason not to do it? > > > > Exactly what do you mean by "different Sage components?" I do know that > there was some discussion of git submodules, but it was discarded for > technical reasons that I don't recall. components are all non-packaging/distribution related parts. like sage-scripts, sage-notebook, extcode, sage-tex the python modules and the c library. these were (before the git-transition) more or less cleanly split from each other. guess why (who did this?). also, all packages had a unified interface (the spkg-install script), and were treated alike by the top-level-stuff (okay, they should have been -- i don't know for sure). regards felix PS: yes i could think of a roadmap do deal with most of this. but its more work and less distribution-friendly. lets burn all bridges first. -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
On Fri, Apr 12, 2013 at 09:23:45PM +1200, Francois Bissey wrote: > I'd like to note that on gentoo we only use things like > sage-singular-xxx as an exception - singular is a particularly good > example, since it was the last one we had years ago. Compared to debian > we have a little bit more freedom on the versions a user can install. > My own experience over the years is that singular and pari are possibly > the most problematic one followed by polybori (but it is improving > dramatically in that regard in the latest release), networkx and lately > ppl. but i guess, you would switch to unprefixed versions, if they worked as well. > The biggest reason of doing sage-foo for everything is to use mpir > instead of gmp. sage-on-gentoo is using gmp as switching to mpir distro > wide would require agreement from the toolchain people. There are way of > giving people the choice but that involves changing every package > currently using gmp in debian one would probably postfix libraries linked against mpir instead of gmp with -mpir, like for example libmpfr-mpir, libmpfi-mpir or libpari-mpir. this is not difficult, does not require a distro-wide switch and is only indirectly related to sage. providing mpir versions is something we/debian should do after sage is packaged and working (and there is an indication to do so). regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
Hi there. On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote: > > so theres the inevitable question to ask: > > would it be an option to eventually split c_lib and the python modules > > to different packages? > > If they are each in a selfcontained folder it's not too much hassle to > repack them from the one tarball. (Ok, still some hassle.) However, I > don't see why they should not be in one source package. Because linking > to c_lib has to be done differently when it is not installed on the > system when the package is built? An important implication of having > stuff together in a source package is usually that they have to be > updated together. That is the case for the parts of Sage. By the way, > does c_lib have a stable ABI so that it is reasonable to have it as a > public shared library? Would that be useful? i don't see the c_lib/python sage lib as critical as the gentoo people do. but: if some distribution -- for whatever reason -- requires/fancies seperate packages, seperate packages would make sage more distribution friendly. (no actual problem here). what frightens me is that the spkgs for the core parts have vanished in https://github.com/sagemath/sage.git (the git-transition). if this is serious (and not a temporary kludge), we really would have to repack tarballs. this (imo) is not just 'some hassle': try to cherry-pick a patch from current sage-python that makes the release candidate work with, say singular-(sage-singular-version+0.0.1). this scenario is realistic, as it doesnt seem possible to always ship exact dependencies within debian/gentoo/whatever. now try to cherry-pick that patch after repacking and loosing history. im not saying it's not possible. but it would be seriously distribution-unfriendly. > >>> It would still be nice if the top level script could be used by > >>> distributions. [...] > > > > i'm not convinced. once all parts (including python-sage and c_lib) are > > in a distributable/configurable shape, any distribution will be able to > > pick them up easily. especially there will be no need for distributions > > to use sage's built in top-level script. > > > > whatever a top level script does, it will never fit the needs of all > > distributions at once. just think about building a multiarch ready > > package out of c_lib, while it is only accessible within a tarball > > containing the sources of five other packages, through a patchwork of a > > sage-toplevel script and an spkg-install script calling "scons install" > > through a static makefile (or setup.py or whatever). > > Sounds reasonable. Would you take care that the Sage distribution also > build python-sage, c_lib, etc using the new configurable process? that would be the primary objective. treat python-sage, c_lib, sage-scripts, extcode, whatnoteverelse as *packages* just like all the other packages. now understand the sage-toplevel repository as a sage distribution (distributing spkgs or successors). sage will be distribution-friendly as soon as all packages have sane build systems. regards felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
Hi there. On Thu, Apr 11, 2013 at 11:41:17AM +1200, François Bissey wrote: > From the point of view of a linux distribution, my opinion is that the > package > management system should be extracted. If it comes from your distro the > packages and upgrades are handled by the distro mechanism, except for stuff > that (can) live in the final user home directory. i do not really understand this. are you saying that the linux distribution should take over the role of the sage package mechanism? if so, would that mean that sage components should work independently of the sage packaging method? > Sage itself has currently several components that are shipped separately and > at least one that should be split: > sage_root: which has all the elements of the basic build system and > traditionally the scripts to start sage. > sage_scripts: a collection of various scripts and command to run and tests > sage. > extcode: various bits and pieces accumulated over time. I understand it will > disappear in the git migration being integrated elsewhere. > sage: the python extension itself plus the c library. The c library is the > element we think should be split (and we do in sage-on-gentoo). are you implying that its a good idea to split components and ship them as seperate packages? the sage-to-git transition apparently does the reverse. how does this affect the gentoo-packaging? > Whether to keep this structure in Debian or after the git transition is not > for me to answer. But I strongly believe the c library needs to be available > separately from the python library. in debian, one source package can create multiple binary packages. this for example makes sense, when seperate (but related) lib*, *-dev, *-doc, *-dbg packages are convenient. packing unrelated stuff from a single source repo do different binary packages usually leads to overhead within the rules (which will probably not even work for the next release). so theres the inevitable question to ask: would it be an option to eventually split c_lib and the python modules to different packages? > The c library is built with scons which > has its detractors (that includes me) but is seriously too small to justify > autotooling in my opinion. all i (need to?) know about scons is, that there is no visible concept of configure. particularly there is no way to pass --with-this-and-that=/my/favourite/path switches in a practical way. so if the c_lib is small, that would make transition to something else even fast. > > It would still be nice if the top level script could be used by > > distributions. There are still several things to build and other things > > to do, if external dependencies are not built, and we should not > > implement all this in debian/rules. One could start with the option to > > build all or none of the dependencies and then maybe go further to allow > > more combinations. But I'm also not entirely sure if combining system > > and bundled dependencies is needed. Maybe an alternative build script > > for building with system libraries would be a better idea. Are there > > other opinions? > > > > The questions has arisen several time in the past 5 years but in spite of some > suggestions on how to achieve this, no one has done the work. You are welcome > to have a go at it. If you start it you may get a surprising number of > helpers. I think most of the inertia is in starting it. i'm not convinced. once all parts (including python-sage and c_lib) are in a distributable/configurable shape, any distribution will be able to pick them up easily. especially there will be no need for distributions to use sage's built in top-level script. whatever a top level script does, it will never fit the needs of all distributions at once. just think about building a multiarch ready package out of c_lib, while it is only accessible within a tarball containing the sources of five other packages, through a patchwork of a sage-toplevel script and an spkg-install script calling "scons install" through a static makefile (or setup.py or whatever). have fun felix -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
Hi there. On Thu, Apr 11, 2013 at 01:04:23AM +0200, Tobias Hansen wrote: > Remember the git transition. spkg's will go away. There will be just one > tarball containing everything in the future. The sources of other > projects will be better separated, so it will be easy to get a Sage > tarball without sources of other projects. Taking this into account, it > probably makes sense to have only one Sage "Debian source package". i have looked at the git repo at https://github.com/sagemath/sage. as it seems, this repo contains the contents of (formerly?) hg.sagemath.org/sage-main (and some more stuff) within src, while the other spkgs have been replaced by a set of patches and rules (couldnt find references to the original tarballs?), sorted into build/pkgs. in particular the contents of sage.spkg have been relocated and merged with other stuff (ext, doc). i don't know why or how serious this is. so current plans are to merge everything together (instead of for example splitting up sage.spkg into c_lib and python-sage)? > Switching to autotools is something we can't decide alone. What do Sage > developers say? Do you mean with "Sage (the library)" all Sage > components including notebook etc? sage "the library" is the contents of sage.spkg. i.e. a shared library (in c_lib) and a python module (in sage). (or *was* the contents of that spkg). > It would still be nice if the top level script could be used by > distributions. There are still several things to build and other things > to do, if external dependencies are not built, and we should not > implement all this in debian/rules. One could start with the option to > build all or none of the dependencies and then maybe go further to allow > more combinations. But I'm also not entirely sure if combining system > and bundled dependencies is needed. Maybe an alternative build script > for building with system libraries would be a better idea. Are there > other opinions? the top-level stuff in a way *is* a distribution. using it to build debian packages makes things worse -- finally the purpose of debian/rules will be mostly dissecting the components. look at singular for a smaller example [1]. (i'm not saying, a top level configure script isnt useful for local/manual installation). regards felix [1] http://git.debian.org/?p=debian-science/packages/singular.git -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: git integration repository, please test
On Wed, Jan 16, 2013 at 02:48:16AM -0800, Timo Kluck wrote: > The problem was that the install root usually needs to be known at compile > time for the binary packages. I think that the location of the > $PREFIX/share/PACKAGE directory are usually put into the binaries by > config.h. that is possible. but what is 'usually' supposed to mean? all packages i know of support a PACKAGE_DATA environment variable. that would be simple (and about time) to add to all the others. > Of course, if we compile the packages locally, that problem disappears > entirely. But I don't thinkg apt is really designed for that, so I'm not > sure if that's feasible. compiling locally is bad, of course YMMV. if apt is not the right tool (designed for it, or not), i'd still be interested in why. regards felix -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: git integration repository, please test
Hi there. On Tue, Jan 15, 2013 at 08:32:29AM -0800, Timo Kluck wrote: > I looked into this, seeing whether we could use portage, pkgsrc, apt > or > macports for this. Unfortunately, they all either require root > privileges > and/or a dedicated user added to the system (portage, apt), require > you to > have the entire dependency tree (pkgsrc), i doubt any of these are true. i have once used apt-get to install packages into a seperate root (without root privileges, not using fakeroot, chroot and the like). iirc, apt-get -c $SOME_ROOT/etc/apt/apt.conf did the trick. a quick look into apt.conf(5) reveals that there is a RootDir configuration item: """ The configuration item RootDir has a special meaning. If set, all paths in Dir:: will be relative to RootDir, even paths that are specified absolutely. So, for instance, if RootDir is set to /tmp/staging and Dir::State::status is set to /var/lib/dpkg/status, then the status file will be looked up in /tmp/staging/var/lib/dpkg/status. """ of course some environment settings are ineviatble to make use of that installation about dependencies: no, apt would only use the local dependency tree in $SOME_ROOT/var/lib/apt/lists/. > or rely on mac-specific libraries > (macports). so it must be that one? sorry, i don't know about mac.*. have fun felix -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: can't name a script "new.sage"?
On Thu, Sep 22, 2011 at 10:50:26AM +0200, Ivan Andrus wrote: > [..] > editors. Unfortunately, I don't know of a way to make bash ignore > certain file extensions when completing. > [..] good idea. after typing $ complete -f -X '*.preparsed.py' vim $ touch foo.sage foo.preparsed.py tab completion $ vim foo yields $ vim foo.sage this should not interfere much with other completion rules. but i don't know/don't use them. regards felix -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: can't name a script "new.sage"?
On Wed, Sep 21, 2011 at 09:11:57AM -0700, Tom Boothby wrote:
> I capitulate on the hidden file idea, in favor of putting 'em in
> ~/.sage/ though one might note that we're exchanging one hidden file
> for another ;)
i agree. prefixing a dot is not quite a solution as i thought yesterday.
putting them in ~/.sage would require some pathname mangling or hashing,
that wouln't make it easier to list/find them than a prefixed filename
(be it with a dot or not).
if I got it right, caching the preparser output is for debugging or for
performance (correct me if im wrong). if it is for debugging, it would
be perfectly safe to hide it from the user, if it is for performance, it
would make more sense to put it into /tmp or /dev/shm.
it seems different users have different views on this, so what about
having environment variables to fine-tune? what i'm thinking of is
something like, SAGE_{CACHE_PREFIX,CACHE_SUFFIX, CACHE_PATH}. CACHE_PATH
set to "." then caches FILE.sage into
$(CACHE_PREFIX)FILE$(CACHE_PREFIX), otherwise into
$CACHE_PATH/mangled_name($PWD/FILE). also, all three set to empty could
disable caching at all.
with something like that running, it should be easy to agree on default
settings.
regards
felix
PS: this is all optional, i'm totally happy with caching as it is works
right now.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: can't name a script "new.sage"?
On Tue, Sep 20, 2011 at 12:55:32PM -0700, John H Palmieri wrote: > Should "sage-preparse" name the preparsed file something safer, in order to > prevent name clashes like this? For example, turn FILE.sage into > FILE_preparsed.py? Hi. while You are at it: preparsed_FILE.py or even simply .FILE.py would make tab completion happy. (who has not accidentally edited FILE.py instead of FILE.sage more than once?) regards felix -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Finite-dimensional algebras in Sage?
On Tue, Sep 20, 2011 at 12:40:30PM +0200, Nicolas M. Thiery wrote:
> Here is a suggestion of implementation plan:
>
> - Low level kernel: implement efficient "mutable" subspaces. That is
>we want the usual subspaces:
> [..]
> - Implement generically (in ModulesWithBasis) a method:
> [..]
> - Use it to implement (in AlgebrasWithBasis) a method:
> [..]
> - Make sure that all sage vector spaces and algebras are in the
>appropriate categories!
Hi there.
this looks familiar (in a way).
some time ago i've started implementing path (or 'quiver') algebras in a
similar way. a path algebra is the algebra generated by the paths in a
directed graph -- think of it as a generalization of a free algebra
(where the graph has only one vertex).
i haven't come beyond elements, multiplication and (graded) quotients,
which are currently brute force and quite slow.
nevertheless these basic things work:
(from memory, see doctests for more examples/details):
sage: G = DiGraph({'e':['s'], 's':['e']}, name="some graph");
sage: A = PathAlgebra(GF(3),G);
sage: X=A.gens();X
(e,s,es,se)
sage: e,s,es,se=X
sage: es*e
0
sage: es*s
es
sage: es*se
es_se
sage: A(1)
e + s
sage: I = A.ideal([es*se])
sage: Q = A.quotient(I)
sage: Y=Q.gens();Y
[[e], [s], [es], [se]]
sage: e,s,es,se=Y
sage: Q.gens(2)
[[se_es]]
sage: Q.graded_comp(2).dimension()
1
sage: es+se
[es+se]
sage: e*es
[es]
sage: a=es*se;a
[es_se]
sage: a==0
True
sage: (es*se).simplify()
0
you can find the code here:
http://tool.em.cs.uni-frankfurt.de/~felix/misc/path_algebra-0.0.0.tbz2
regards
felix
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] integrate, diff and subs using wildcard bug II
Sorry. i forgot to mention that the bug was observed in version 4.3.3
(from source tarball, fresh install) on a (rather untouched)
lenny/2.6.26-amd46.
regards
felix
On Tue, Mar 16, 2010 at 02:42:19PM +0100, Felix Salfelder wrote:
> Hi all.
>
> I just encountered something like a bug, when i tried to calculate some
> statistics.
>
> here is an example:
> \begin{example}
> var('x s')
> assume(x>0)
> S=x.parent()
> w0=S.wild(0)
> f(x) = (2/sqrt(pi)*exp(-s^2)).integrate(s,0,x)
> g(x) = f(x).diff(x)
> h(x) = diff(erf(x),x)
> print "g :", g
> print "h :", h
> print "g :", g.subs(diff(erf(x),x)(x=w0) == 2/sqrt(pi) * exp(-w0^2))
> print "h :", h.subs(diff(erf(x),x)(x=w0) == 2/sqrt(pi) * exp(-w0^2))
> print "g-h :", g-h
> print "g-h :",(g-h).subs(diff(erf(x),x)(x=w0) == 2/sqrt(pi) * exp(-w0^2))
> print "g-h :",(g-h).simplify()
> \end{example}
>
> the output is as follows:
> \begin{output}
> 1: g : x |--> D[0](erf)(x)
> 2: h : x |--> D[0](erf)(x)
> 3: g : x |--> D[0](erf)(x)
> 4: h : x |--> 2*e^(-x^2)/sqrt(pi)
> 5: g-h : x |--> -D[0](erf)(x) + D[0](erf)(x)
> 6: g-h : x |--> -2*e^(-x^2)/sqrt(pi) + D[0](erf)(x)
> 7: g-h : x |--> 0
> \end{output}
>
> I dont understand why output line 3 differs from output line 4.
> in line 5-7 simplify() works as expected, but subs() doesnt.
>
> regards and thanks
> felix
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] integrate, diff and subs using wildcard bug
Hi all.
I just encountered something like a bug, when i tried to calculate some
statistics.
here is an example:
\begin{example}
var('x s')
assume(x>0)
S=x.parent()
w0=S.wild(0)
f(x) = (2/sqrt(pi)*exp(-s^2)).integrate(s,0,x)
g(x) = f(x).diff(x)
h(x) = diff(erf(x),x)
print "g :", g
print "h :", h
print "g :", g.subs(diff(erf(x),x)(x=w0) == 2/sqrt(pi) * exp(-w0^2))
print "h :", h.subs(diff(erf(x),x)(x=w0) == 2/sqrt(pi) * exp(-w0^2))
print "g-h :", g-h
print "g-h :",(g-h).subs(diff(erf(x),x)(x=w0) == 2/sqrt(pi) * exp(-w0^2))
print "g-h :",(g-h).simplify()
\end{example}
the output is as follows:
\begin{output}
1: g : x |--> D[0](erf)(x)
2: h : x |--> D[0](erf)(x)
3: g : x |--> D[0](erf)(x)
4: h : x |--> 2*e^(-x^2)/sqrt(pi)
5: g-h : x |--> -D[0](erf)(x) + D[0](erf)(x)
6: g-h : x |--> -2*e^(-x^2)/sqrt(pi) + D[0](erf)(x)
7: g-h : x |--> 0
\end{output}
I dont understand why output line 3 differs from output line 4.
in line 5-7 simplify() works as expected, but subs() doesnt.
regards and thanks
felix
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] save bug (filename dependent behaviour when saving list)
Hi all,
there is a problem with save(), (at least) with sage 4.3, 4.3.1, 4.3.3.
I found trac#2046, but i am not sure if it is connected. somehow the
".sobj"-suffixing mechanism seems to be broken. i'd suggest just leaving the
filenames as specified.
see below for the details.
regards and thank You
felix
##
# the implementation works:
sage: 1.save("foo")
sage: load("foo")
1
# but then:
sage: [1,2].save("foo")
---
AttributeErrorTraceback (most recent call last)
/home/felix/hesage/ in ()
AttributeError: 'list' object has no attribute 'save'
###
# interestingly this works:
sage: save([1,2],"foo")
sage: load("foo")
[1, 2]
###
# and now this is absurd:
sage: save([1,2],"foo.bar")
---
AttributeErrorTraceback (most recent call last)
/`pwd`/ in ()
/path/to/sage/local/lib/python2.6/site-packages/sage/structure/sage_object.so
in sage.structure.sage_object.save (sage/structure/sage_object.c:8108)()
AttributeError: 'list' object has no attribute 'save'
##
# since this again works:
sage: save(1,"foo.bar")
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
