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

[Felix Salfelder]

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

[Tobias Hansen]

Am 12.04.2013 10:25, schrieb Felix Salfelder:
> 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.

Only if we want multiple Sage "Debian source packages".

> 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.
> 

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?

Cheers,
Tobias

-- 
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] Re: Global options

[Volker Braun]

It would be nice if we could implement the syntax in the IPython 
configuration stuff:

A.options.foobar = 1

in addition to

A.options(foobar=1)

This would require us to rename the existing methods of GlobalOptions with 
underscores. 

Also, for consistency we should recommend / enforce a name for the options. 
Should it be A.options or A.global_options or what? The docs use various 
conventions.




On Friday, April 12, 2013 2:17:35 AM UTC+1, Andrew Mathas wrote:
>
> Dear Developers,
>
> As part of the clean up of the partitions code by Travis (Trac 
> 13605) 
> I implemented a generic options interface in sage which can be used for 
> controlling (global) options for sage objects. See 
> sage.structure.global_options for details. This patch, including the 
> global_options, was merged in sage-5.8.beta3. 
>
> Novosel has just complained, quite justifiably, on the ticket above that 
> the global options should have been given their own ticket rather than 
> being hidden in a large patch. Apologies for this, but these options just 
> grew as part of my review patch with fine tune-tuning (and reviewing) from 
> Travis and Nicolas at ICERM... 
>
> Given the obscure manner in which this options framework has entered sage, 
> and Novosel's comment on the ticket, I now take the opportunity to 
> advertise them.
>
> Andrew
>

-- 
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

[Francois Bissey]

On 12/04/13 20:59, Tobias Hansen wrote:
> Am 12.04.2013 10:25, schrieb Felix Salfelder:
>> 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.
> 
> Only if we want multiple Sage "Debian source packages".
> 
>> 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.
>>
> 
> 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?
> 

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.

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

Francois

-- 
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] Re: Sage part of Google's Summer of Code 2013

[mmarco]

Can someone edit the project proposals page to include the gui for
controling the vm?

On 11 abr, 10:49, Harald Schilly  wrote:
> Hi, this is a reminder, that students start proposing ideas in the
> dedicated forum over 
> here:https://groups.google.com/forum/?fromgroups#!forum/sage-gsoc
>
> H
>
>
>
>
>
>
>
> On Monday, April 8, 2013 11:03:40 PM UTC+2, Harald Schilly wrote:
>
> > Good News, like last year Sage is once again part of Google's Summer
> > of Code. This means, until April 22 at 19:00 UTC students can submit
> > their applications and mentors will review them and do the matching.
> > Please share this with prospective students or think about being a
> > mentor this year!
>
> > gsoc page:http://www.google-melange.com/gsoc/org/google/gsoc2013/sage
> > ideas:http://goo.gl/l0CRl(check back for updates)
>
> > Harald

-- 
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

[Jeroen Demeyer]

On 04/11/2013 11:48 PM, Tobias Hansen wrote:

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.
I agree. I see no reason at all for having separate packages for c_lib 
and the sage library for example. Perhaps Gentoo has its reasons, but 
normally I expect this to remain one package.


--
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] Re: new optional (or experimental) package CSDP?

[Dima Pasechnik]

On 2013-04-11, Nathann Cohen  wrote:
> --=_Part_629_6688666.1365672308379
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> +1
>
> I had never heard of Flagmatic before. Looks GREAT :-D
it implements a range of recent ideas due to Razborov et al, which
produced a lot of progress in extremal (hyper)graph theory recently.

Dima 
>
> Nathann
>
> On Thursday, April 11, 2013 6:56:45 AM UTC+2, Snark wrote:
>>
>> Le 11/04/2013 06:32, Nils Bruin a =EF=BF=BDcrit :=20
>> > On Apr 10, 8:52 pm, Dima Pasechnik  wrote:=20
>> >> 2) yes to CSDP becoming an experimental package.=20
>> >=20
>> > Doing that requires no different work from preparing it to be an=20
>> > optional package, so why not do that first? Once that's done I would=20
>> > expect it'll be pretty smooth sailing into optional status.=20
>>
>> +1=20
>>
>> Snark on #sagemath=20
>>

-- 
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] R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

[Andrzej Giniewicz]

Hi,

I tried to do some plotting in R after break from using R inside Sage,
but I encountered error:

Error in png() : X11 module cannot be loaded
In addition: Warning message:
In png() :
  unable to load shared object
'/usr/local/sage/sage-5.8-opt/local/lib/R//modules//R_X11.so':
  /usr/lib/libharfbuzz.so.0: undefined symbol: FT_Get_Advance

I checked it, and libharfbuzz.so.0 (dependency of pango/cairo) in my
system is 0.9.15, the symbol it looks for is defined in my system-wide
freetype installation ( 2.4.11 ), but is missing from Sage-installed
freetype (2.3.5) that is linked in R_X11.so.

rebuilding R with "--without-cairo" helps, and it still can generate
png files using grGraphics - was cairo enabled on purpose and is used
somewhere else in Sage version of R?

Thanks,
Andrzej.

-- 
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] Re: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

[Volker Braun]

Can you use the Xlib backend in R?

sage: print r.eval('capabilities()')
jpeg  png tifftcltk  X11 aqua http/ftp  sockets   
libxml fifo   cledit 
   FALSEFALSEFALSEFALSEFALSEFALSE TRUE TRUE 
TRUE TRUE TRUE 
   iconv  NLS  profmemcairo 
TRUE TRUEFALSEFALSE 

You need more than just the Sage minimal requirements for R graphics. At 
least X11 development, ideally a working cairo. I think we should just 
disable our own freetype if the OS provides a working freetype (with 
headers). Otherwise you need a pretty large stack, cairo + freetype + 
harfbuzz + ... to produce high-quality plots.




-- 
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] Blocker tickets

[Jeroen Demeyer]

There are 2 blocker tickets remaining for Sage 5.9, both of them need 
review:


#14371: Race condition in singular doctest
http://trac.sagemath.org/sage_trac/ticket/14371

#14426: Runaway/Segfaulting ECL processes
http://trac.sagemath.org/sage_trac/ticket/14426


There is already 1 blocker for Sage 5.10, which also needs review:
#14433: Increase number of matches to "tree" in sagedoc.py doctest
http://trac.sagemath.org/sage_trac/ticket/14433

--
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: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

[Andrzej Giniewicz]

Well, there are no X-es on this machine, but it is ready to use png
backend with or without cairo when compiled with freetype on host:

> capabilities()
jpeg  png tifftcltk  X11 aqua http/ftp  sockets
TRUE TRUE TRUE TRUEFALSEFALSE TRUE TRUE
  libxml fifo   clediticonv  NLS  profmemcairo
TRUE TRUE TRUE TRUE TRUEFALSE TRUE

I don't care much about X11 there, I'm actually testing this to do R
trough Sage Cell server for one of courses I teach. When I enter
capabilities inside Sage, I get "false" almost everywhere, but the
"unable to load shared object" shows up as well.

On Fri, Apr 12, 2013 at 3:33 PM, Volker Braun  wrote:
> Can you use the Xlib backend in R?
>
> sage: print r.eval('capabilities()')
> jpeg  png tifftcltk  X11 aqua http/ftp  sockets
> libxml fifo   cledit
>FALSEFALSEFALSEFALSEFALSEFALSE TRUE TRUE
> TRUE TRUE TRUE
>iconv  NLS  profmemcairo
> TRUE TRUEFALSEFALSE
>
> You need more than just the Sage minimal requirements for R graphics. At
> least X11 development, ideally a working cairo. I think we should just
> disable our own freetype if the OS provides a working freetype (with
> headers). Otherwise you need a pretty large stack, cairo + freetype +
> harfbuzz + ... to produce high-quality plots.
>
>
>
>
> --
> 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.
>
>

-- 
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: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

[Volker Braun]

On Friday, April 12, 2013 3:35:41 PM UTC+1, Andrzej Giniewicz wrote:

> Well, there are no X-es on this machine, but it is ready to use png 
> backend with or without cairo when compiled with freetype on host


There are 3 backends that can write png in R, and they are cairo, Xlib, and 
quartz. If you can generate png and have neither X11 nor cairo then you are 
on a Mac.

-- 
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: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

[Andrzej Giniewicz]

Well, to be more clear I have only xvfb + dependencies, so I should
have said I have "headless Xes"

On Fri, Apr 12, 2013 at 4:48 PM, Volker Braun  wrote:
> On Friday, April 12, 2013 3:35:41 PM UTC+1, Andrzej Giniewicz wrote:
>>
>> Well, there are no X-es on this machine, but it is ready to use png
>> backend with or without cairo when compiled with freetype on host
>
>
> There are 3 backends that can write png in R, and they are cairo, Xlib, and
> quartz. If you can generate png and have neither X11 nor cairo then you are
> on a Mac.
>
> --
> 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.
>
>

-- 
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] Blocker tickets

[Johannes]

Hi,
Tickt 14433 fails on my system:
sage:len(search_doc('tree', interact=False).splitlines()
3956
sage: version()
'Sage Version 5.8, Release Date: 2013-03-15'

bg,
Johannes

On 12.04.2013 16:01, Jeroen Demeyer wrote:
> There are 2 blocker tickets remaining for Sage 5.9, both of them need
> review:
> 
> #14371: Race condition in singular doctest
> http://trac.sagemath.org/sage_trac/ticket/14371
> 
> #14426: Runaway/Segfaulting ECL processes
> http://trac.sagemath.org/sage_trac/ticket/14426
> 
> 
> There is already 1 blocker for Sage 5.10, which also needs review:
> #14433: Increase number of matches to "tree" in sagedoc.py doctest
> http://trac.sagemath.org/sage_trac/ticket/14433
> 

-- 
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

[Felix Salfelder]

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

[Francois Bissey]

On 13/04/2013, at 4:24, "Felix Salfelder"  wrote:

> 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.

Yes and we currently do not use prefixed version singular was the last one
several year ago.

Francois

-- 
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] Sage notebook server virtual machine

[Nicolas M. Thiery]

Hi,

I just installed a new notebook server on:

https://combinat.sagemath.org:8080/

following http://wiki.sagemath.org/SageServer
Thanks Jason for the great step-by-step instructions!

This made me wonder: we currently are distributing a virtual machine
containing a sage notebook server for private usage, mostly for the
convenience of our windows users.

Would it make sense to distribute another virtual machine that would
be preconfigured as a public notebook server? Then, someone wanting to
run such a server at a meeting, or in his lab, or in a class, could
just fire the virtual machine and be basically, up to maybe some
virtualbox/qemu network configuration. It should be straightforward to
script the instructions on the wiki, to make the building of the
virtual machine roughly automatic.

Of course any long term usage of such a server would still require
more tweaking, but that would be a good easy starting point.

Just throwing the idea; I am not really volunteering ...

Cheers,

Nicolas

PS: by the way the instructions to create the sage user accounts are
currently broken on the wiki. I used this instead:

  for i in $(seq 0 9); do  cp ~sageserver/.ssh/id_dsa.pub 
/home/sage$i/.ssh/authorized_keys; done
  for i in $(seq 0 9); do  chmod 700 /home/sage$i/.ssh; done
  for i in $(seq 0 9); do  chmod 600 /home/sage$i/.ssh/authorized_keys; done
  for i in $(seq 0 9); do  chown -R sage$i:sageuser /home/sage$i/.ssh; done

--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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] Re: Sage notebook server virtual machine

[Volker Braun]

I don't think we really need a whole separate VM for that. Its just a few 
configurations that need to be changed. The problem is that we currently 
have no way to add any preferences into the VM session, so its only 
possible for those in the know. Same problem with changing the keyboard 
layout. We need some sort of plug-in structure in the notebook to be able 
to show additional preferences. 

On Friday, April 12, 2013 8:34:32 PM UTC+1, Nicolas M. Thiéry wrote:
>
> PS: by the way the instructions to create the sage user accounts are 
> currently broken on the wiki.
>

Well you know what a wiki is good for ;-) 

-- 
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: new optional (or experimental) package CSDP?

[Nathann Cohen]

>> I had never heard of Flagmatic before. Looks GREAT :-D
> it implements a range of recent ideas due to Razborov et al, which
> produced a lot of progress in extremal (hyper)graph theory recently.

I had no idea it had evolved into an open source project already :-)

Nathann

-- 
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

[David Roe]

First a disclaimer: I was at Sage Days 47 (working on the transition to
git), but I'm not a git expert and I don't know the technical justification
for some of the choices made (I think the best people to speak up in that
direction would be Andrew Ohana, Keshav Kini, Robert Bradshaw, Timo Kluck
or Julian Ruth).  I also use OS X so I personally have no interest in
working on packaging efforts, though I'm grateful to those of you who do,
both for the increased exposure of Sage in the Linux world and for the
progress toward the goal of being able to checkout different versions of
Sage with different spkgs installed and have them build and work.

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.

On Fri, Apr 12, 2013 at 2:59 AM, Tobias Hansen  wrote:

> Am 12.04.2013 10:25, schrieb Felix Salfelder:
> > 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.
>

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.

>
> > 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.
> >
>
> 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.
David

-- 
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] Re: Global options

[Andrew Mathas]

On Friday, 12 April 2013 19:23:31 UTC+10, Volker Braun wrote:
>
> It would be nice if we could implement the syntax in the IPython 
> configuration stuff:
>
> A.options.foobar = 1
>
> in addition to
>
> A.options(foobar=1)
>
> This would require us to rename the existing methods of GlobalOptions with 
> underscores. 
>

One advantage of this is of course would be tab-completion for the options. 
I'm not entirely sure about renaming the existing methods, however. The 
methods for a GlobalOptions object are currently:

category, db, default_value, dispatch, dump, dumps, rename, reset, reset_name, 
save, version

The methods in red are all "standard" SageObject methods which probably 
should not be renamed.


> Also, for consistency we should recommend / enforce a name for the 
> options. Should it be A.options or A.global_options or what? The docs use 
> various conventions.
>

I see two different use cases:

   - global options which control the general behaviour of one or more 
   classes (as with the currently implemented global_options methods of 
   Partitions, Tableaux, PartitionTuples, ...)
   - options which control how particular instances of class function

Encouraging global_options for the former and options for the latter would 
make sense.

Andrew

-- 
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.