Re: [sage-devel] Upgrading networkx - unpickling issue

[Nicolas M. Thiery]

Hi Greg!

On Thu, Jan 28, 2010 at 08:27:30PM -0800, Greg McWhirter wrote:
> I've been working on upgrading networkx to 1.0.1 for the past couple
> days and have things passing almost all the tests (modulo some answer
> correction for changed format of networkx representations)

Thanks for your work: +1 on staying synchronized with networkx!

> The other big block of tests that don't pass are unpickling tests from
> sage/structure/sage_object.pyx
> I am wondering how big a problem this really is?
> 
> Looking at some of the classes for some of the things it fails on
> (detailed at the bottom), it seems they use a graph object somewhere
> in the internals. I am guessing that since networkx removed the XGraph
> and XDiGraph objects somewhere between 0.36 (which is the version
> currently shipping with sage) and 1.0.1, the pickled objects can't
> find those classes and fail to unpickle. However, I don't know how to
> test that exactly, nor what to do about it (possibly patching networkx
> to do something when asked for those classes, loading up the up-to-
> date ones instead?)

A confirmation: dynkin diagrams inherit from DiGraph, and all crystals
point to a dynkin diagram. Similarly for posets. So if some type of
graphs don't unpickle, I am not surprised for all of this to fail.

The following command (to be run with Sage with the old networkx)
tells you what will happens upon later unpickling, say, a poset:

sage: P = Poset()
sage: explain_pickle(dumps(P))
pg_FinitePoset = unpickle_global('sage.combinat.posets.posets', 
'FinitePoset')
si1 = unpickle_newobj(pg_FinitePoset, ())
pg_HasseDiagram = unpickle_global('sage.combinat.posets.hasse_diagram', 
'HasseDiagram')
si2 = unpickle_newobj(pg_HasseDiagram, ())
pg_SparseGraphBackend = unpickle_global('sage.graphs.base.sparse_graph', 
'SparseGraphBackend')
si3 = unpickle_newobj(pg_SparseGraphBackend, ())
pg_SparseGraph = unpickle_global('sage.graphs.base.sparse_graph', 
'SparseGraph')
unpickle_build(si3, {'_cg_rev':pg_SparseGraph(0r, 16r, 10r, [], []), 
'directed':True, 'vertex_labels':{}, '_multiple_edges':False, '_directed':True, 
'_name':'', 'vertex_ints':{}, '_loops':False, 'edge_labels':{0r:None}, 
'_cg':pg_SparseGraph(0r, 16r, 10r, [], [])})
unpickle_build(si2, {'_weighted':False, '_pos':None, '_boundary':[], 
'_latex_opts':None, '_backend':si3})
unpickle_build(si1, {'_hasse_diagram':si2, '_embedding':None, 
'_convert_method_name':None, '_cdata':None, '_category':None, '_names':None, 
'_generators':None, '_elements':[], '_hash':None, '_pickle_version':1r, 
'_element_constructor':None, '_initial_convert_list':[], 
'_element_init_pass_parent':False, '_initial_action_list':[], 
'_initial_coerce_list':[], '_base':None})
si1

Then, you can just copy paste the commands in a Sage with the new
networkx, and see what breaks. Most likely it is the
SparseGraphBackend thing.  If it's just a question of renamed class,
then you can add something along the following lines somewhere in the
graph code:

from sage.structure.sage_object import register_unpickle_override

register_unpickle_override('sage.graphs.base.sparse_graph','SparseGraphBackend',
   )

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

-- 
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] #8044: Categories for finite/permutation/symmetric groups

[Nicolas M. Thiery]

Hi Robert,

On Thu, Jan 28, 2010 at 09:36:18AM -0800, Robert Miller wrote:
> On Thu, Jan 28, 2010 at 9:12 AM, Nicolas M. Thiery
>  wrote:
> > Rationale:
> >
> > (a) For the option name: that might be just me, but I find
> >``generators`` far more natural than ``connecting_set``.
> >This specifies an alternative set of generators for (a subgroup
> >of) G.
> 
> If it's just the name of the option, I'm fine with generators or connecting 
> set.

Ok. Further votes anyone?

> > (b) For removing connecting_set = a: this feature cannot be
> >implemented in a robust way. If a is a tuple or an iterator, how
> >can cayley_graph determines generically whether a is an iterable
> >of elements of G, or some data that can be coerced into a single
> >element of G?
> 
> I really thought you meant that {generators, connecting_set} = [a] was
> being deprecated. That's obviously ridiculous.

Definitely.

> I misunderstood what you originally wrote, and I was in quite a hurry,
> so I had little time to write a reply. You are completely correct, in
> that the interrogative tone was quite by mistake. I was just very
> surprised at the moment by my mistaken impression of what this patch
> did. Please accept my apology. :)

I gladly take my share of responsibility in throwing in the confusion
in the first place :-)

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

-- 
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] #8044: Categories for finite/permutation/symmetric groups

[Nicolas M. Thiery]

On Thu, Jan 28, 2010 at 12:32:48PM -0500, David Joyner wrote:
> Just generally speaking, I appreciate very much any "cleaning up"
> of this category of Sage objects. To me, it makes things more
> natural and hopefully makes it easier to add functionality in an
> organized way in the future.

Mrr, it feels good to be petted a bit. As would say Lucky Luke to Joly
Jumper: ``tu aimes ça, hein, vieux cabot'' :-)

Ok, I'll review a patch as penitence for shamelessly calling for it:-)

Seriously speaking: do you feel like reviewing my patch, once the
votes/discussions will be other?

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

-- 
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: OT: CPLEX anyone?

[Martin Albrecht]

On Thursday 28 January 2010, dahl.joac...@gmail.com wrote:
> MOSEK provides state-of-the-art commercial LP and SOCP solvers as
> well as MIP solvers.  They have a python interface and their academic
> license is free.

Actually, their academic license isn't free:

  http://www.mosek.com/index.php?id=126

Harald Schilly pointed me off list to 

  http://scip.zib.de/

which seems to be a decent MIP solver (+ other stuff), it comes with sources 
and is free for academic use. They have a sort of weird license though, where 
you are legally bound to cite them in your paper etc. (stopping myself now, 
further discussions on licenses -> [sage-flame])

Martin

-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinralbre...@jabber.ccc.de

-- 
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] cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[Minh Nguyen]

Hi folks,

With Sage 4.3.2.alpha0, one has two suspicious binary files under
SAGE_LOCAL/bin, as shown by the following hg report:

[mv...@sage bin]$ pwd
/dev/shm/mvngu/sage-4.3.2.alpha0-sage.math/local/bin
[mv...@sage bin]$ hg status
M sage-banner
M sage-gdb-commands
M sage-maxima.lisp
M sage-verify-pyc
? cdd_both_reps
? cdd_both_reps_gmp

The files in question are cdd_both_reps and cdd_both_reps_gmp. It
turns out that these two files were put there by the package
cddlib-094f.p2.spkg. I think they were put there due to using the
command "patch" in spkg-install for patching the upstream source under
src/.

A problem with cddlib-094f.p2.spkg is that it patches upstream source
using a patch file, rather than copying a patched file over to the
appropriate place under the src/ directory. Consequently, there is no
clean separation between upstream source and patches that we apply to
cddlib-094f. Looking at spkg-install of cddlib-094f.p2.spkg, you get
these two lines for applying Sage-specific patches:

cp patches/allfaces.c src/src/

patch -p0 < patches/cdd_both_reps-make.patch

The first line is the preferred way to patch an upstream source
because it copies the patched file patches/allfaces.c over to
src/src/. Even before running the installation script spkg-install,
the original upstream source is the file src/src/allfaces.c and its
corresponding patched version for Sage is patches/allfaces.c. And you
patch the upstream source using cp. In this way, you keep a clean
separation between the source provided by the upstream project and the
patches that the Sage project applies on top of the upstream source.

Now let's consider the second line in the above code listing, i.e.

patch -p0 < patches/cdd_both_reps-make.patch

Patching an upstream source in this way results in modified upstream
source and this modification now lives under src/, which is supposedly
where the clean upstream source lives. Subsequently, anytime you want
to update (not upgrade to latest upstream release) the
cddlib-094f.p2.spkg package, you have modified source under src/. This
can cause a lot of confusion for maintainers who need to have a clean
separation between upstream source and Sage-specific patches.

Here's an example illustrating that using the command "patch" in
spkg-install for patching upstream source is a bad idea. Say you have
a directory listing as follows:

[mv...@sage cddlib]$ pwd
/home/mvngu/spkg/standard/cddlib
[mv...@sage cddlib]$ ls
cddlib-094f.p0  cddlib-094f.p0.spkg  cddlib-094f.p2  cddlib-094f.p2.spkg

In cddlib-094f.p2.spkg, the content of the file
patches/cdd_both_reps-make.patch is

[mv...@sage cddlib]$ cat cddlib-094f.p2/patches/cdd_both_reps-make.patch
--- ../cddlib-094f/src/src-gmp/Makefile.am  2009-01-26 09:30:16.0 
+
+++ src/src-gmp/Makefile.am 2009-10-04 10:36:17.0 +0100
@@ -11,7 +11,8 @@
 testcdd2_gmp \
 testlp1_gmp \
 testlp2_gmp \
-testlp3_gmp
+testlp3_gmp \
+cdd_both_reps_gmp
 #cddmathlink

 scdd_gmp_SOURCES   = simplecdd.c
@@ -27,6 +28,7 @@
 testlp1_gmp_SOURCES= testlp1.c
 testlp2_gmp_SOURCES= testlp2.c
 testlp3_gmp_SOURCES= testlp3.c
+cdd_both_reps_gmp_SOURCES  = cdd_both_reps.c
 # cddmathlink_SOURCES= cddmathlink.c cddmlio.h cddmlio.c

 LDADD= ../lib-src-gmp/libcddgmp.a
--- ../cddlib-094f/src/src/Makefile.am  2009-01-26 09:30:03.0 +
+++ src/src/Makefile.am 2009-10-04 10:36:17.0 +0100
@@ -11,7 +11,8 @@
 testcdd2 \
 testlp1 \
 testlp2 \
-testlp3
+testlp3 \
+cdd_both_reps
 #cddmathlink

 scdd_SOURCES   = simplecdd.c
@@ -27,6 +28,7 @@
 testlp1_SOURCES= testlp1.c
 testlp2_SOURCES= testlp2.c
 testlp3_SOURCES= testlp3.c
+cdd_both_reps_SOURCES  = cdd_both_reps.c
 # cddmathlink_SOURCES= cddmathlink.c cddmlio.h cddmlio.c

 LDADD= ../lib-src/libcdd.a

Now compare cddlib-094f.p0/src/src-gmp/Makefile.am with
cddlib-094f.p2/src/src-gmp/Makefile.am and you'd get

[mv...@sage cddlib]$ diff -u cddlib-094f.p0/src/src-gmp/Makefile.am
cddlib-094f.p2/src/src-gmp/Makefile.am---
cddlib-094f.p0/src/src-gmp/Makefile.am  2009-01-26 01:30:16.0
-0800
+++ cddlib-094f.p2/src/src-gmp/Makefile.am  2009-10-15 13:25:26.0 
-0700
@@ -11,7 +11,8 @@
 testcdd2_gmp \
 testlp1_gmp \
 testlp2_gmp \
-testlp3_gmp
+testlp3_gmp \
+cdd_both_reps_gmp
 #cddmathlink

 scdd_gmp_SOURCES   = simplecdd.c
@@ -27,6 +28,7 @@
 testlp1_gmp_SOURCES= testlp1.c
 testlp2_gmp_SOURCES= testlp2.c
 testlp3_gmp_SOURCES= testlp3.c
+cdd_both_reps_gmp_SOURCES  = cdd_both_reps.c
 # cddmathlink_SOURCES= cddmathlink.c cddmlio.h cddmlio.c

 LDADD= ../lib-src-gmp/libcddgmp.a

As you can see, cddlib-094f.p2.spkg is mashing up upstream source and
Sage-specific patch together and put the result under the directory
where the clean 

[sage-devel] Re: Unknown control sequence '\texttt'

[lutusp]

> Give some examples, please.

var("y R")

a(y,R) = pi * (2*R - y) * y

lbl = text("$\int \  " + latex(a(y,R)) + "$",(3,20))

view(lbl)
 ... Graphics object consisting of 1 graphics primitive (not
displayed)
show(lbl)
 ...  Unknown control sequence '\texttt'

No graphics shown.

> By the way, have you tried the patch I mentioned in my other message today?

I initially dealt with Sage problems that way, but the patches keep
changing with each new version while the problem remains unsolved. I
eventually concluded it was simpler not to upgrade. The present
problem is less severe in earlier versions.

-- 
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] Re: Rational polynomials via FLINT (#4000)

[Bill Hart]

I wonder if it is possible to recreate the problem just using FLINT,
without any Sage, i.e. just write a short FLINT program which
replicates the problem.

I don't understand how the multiplication could take any serious
quantity of time unless the pow was screwed up somehow. But perhaps it
is.

Could you insert some traces to print the values of m, the number of
limbs of lead and (when it is computed) the number of limbs of t.

Bill.

On Jan 29, 2:10 am, Sebastian Pancratz  wrote:
> On Jan 29, 12:54 am, Bill Hart  wrote:
>
> > One possibility is that the problem occurs only on 32 bit machines or
> > only 64 bit machines and not the other kind. Have you got access to
> > both 32 and 64 bit architectures to try this on?
>
> Running the commands on a similar set up (Sage 4.3.1.rc0, with the
> patches from #383 and #4000) on a 64-bit machine at the department
> just now gave the following:
>
>     sage: R. = QQ[]
>     sage: f = 3/2*x - 1/3
>     sage: %time _ = f % f
>     CPU times: user 5.18 s, sys: 0.42 s, total: 5.60 s
>     Wall time: 5.60 s
>
> So the problem can also appear on 64-bit machines.  Moreover, I
> noticed that the run time can vary between Sage sessions.  Restarting
> Sage, I found this:
>
>     sage: R. = QQ[]
>     sage: f = 3/2*x - 1/3
>     sage: %time _ = f % f
>     CPU times: user 0.93 s, sys: 0.13 s, total: 1.06 s
>     Wall time: 1.06 s
>
> Of course, this now taking 1s still means something is very wrong, but
> perhaps this variability can help locate the error?  Interestingly,
> after trying this a couple of times, the above two timings (around
> 5.6s and around 1.1s) seem to be the only ones that come up.  They can
> also come up in the same Sage session by re-creating the polynomial:
>
>     sage: R. = QQ[]
>     sage: f = 3/2*x - 1/3
>     sage: %time _ = f % f
>     CPU times: user 0.93 s, sys: 0.13 s, total: 1.06 s
>     Wall time: 1.06 s
>     sage: %time _ = f % f
>     CPU times: user 0.94 s, sys: 0.10 s, total: 1.04 s
>     Wall time: 1.04 s
>     sage: R. = QQ[]
>     sage: f = 3/2*x - 1/3
>     sage: %time _ = f % f
>     CPU times: user 5.10 s, sys: 0.43 s, total: 5.53 s
>     Wall time: 5.53 s
>
> Kind regards,
>
> Sebastian

-- 
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] Re: #8044: Categories for finite/permutation/symmetric groups

[javier]

Hi Nicolas,

On Jan 27, 10:28 pm, "Nicolas M. Thiery" 
wrote:
>     * Puts all permutation groups and some other finite groups in the
>       corresponding categories. There remains to handle finite matrix
>       groups and Galois groups in sage/rings/number_field/.
>
>     * As a result, this standardizes the interface of those groups
>       (cardinality, one, ...).

Nice! I recently had some trouble trying to sort out where to put the
conjugacy classes code, this will be really helpful!
I can't really comment on the graph stuff, but since I'll have to
rebase the cc-patches anyway I might as well give a look to this one.

Which brings to the discussion: is there a standard way of reviewing
tickets? I imagine you all sage gurus have your systematic ways
perfected over the years. But what are precisely those steps?

For instance, something like:

1. Update sage to the latest version with sage -upgrade
2. Make a clone for testing patches with sage -clone testing
3. Apply the patch you want to review using...

etc. I checked in the developers wiki
http://wiki.sagemath.org/devel/TracGuidelines

but the suggestions are rather terse. How does one check 100%
doctests? It would be great it it could be upgraded with more detailed
instructions.

Cheers
J

-- 
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: sage-mode 0.6 / emacs21 init errors

[xtian]

Nick Alexander wrote:
> On 28-Jan-10, at 1:38 PM, xtian wrote:
> > On 28 Jan., 22:32, xtian  wrote:
> >> [...]
> >> This leaves me with one last thing to do for now: giving up.
> > ...which is not a big thing, I should add. No complaint or stuff
> > from my side. And thanks for all the fish. :-)
> Yes, it seems that I've used enough emacs 22 specific stuff that
> giving up is probably wise.  It certainly could be ported, but you'd
> need to know some elisp to do it and I haven't time or interest right
> now.

I kind of "solved" the problem by upgrading to emacs22.
Trouble no more.

I think it could be helpful to mention emacs22 as a requirement
for sage-mode somewhere in the docs (wiki maybe). A note about
sage-mode not working properly on emacs21 could be added.
This might save people some headaches. XEmacs might also be
affected (untested), so propagating emacs22 as the best shot
for trying sage-mode seems in place.

Greetings, xtian

-- 
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-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)

[Bill Hart]

OK, the problem is as follows. For very straightforward C programs, no
problems occur on t2 because the compiler emits inline code for
everything. However, once the program becomes too complicated for it
to do this, it uses libgcc:

http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

The problem is, when the compiler compiles such a program, the linker
does not know where to find libgcc on the machine. It needs to know
that it is in:

/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9

However, this is not in /etc/ld.so.conf, which does not exist on
Solaris machines, nor is it in LD_LIBRARY_PATH.

Why it won't work with this in LD_LIBRARY_PATH_64 I do not know.

But either way, this problem is not something we can work around in
MPIR, that I know of. It's just that MPIR uses some very complex
arithmetic expressions for which gcc is unable to emit inline
assembly. Even writing a basic test case that exhibits this failure
would be difficult.

I've no idea what the solution to the problem is. Back to the sparc
expert for this one!

Bill.

2010/1/28 Bill Hart :
> One sensible solution would seem to be to set
> LD_LIBRARY_PATH_64=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 on t2,
> but this actually doesn't seem to work. I'm not sure why.
>
> However it seems that one can just add
> /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 to the LD_LIBRARY_PATH (it
> doesn't matter whether at the beginning or end) and this fixes the
> problems on t2. Shouldn't this be done globally for all users?
>
> Bill.
>
> 2010/1/28 Bill Hart :
>> 2010/1/28 Dr. David Kirkby :
>>> Bill Hart wrote:

 2010/1/28 Dr. David Kirkby :
>
> The problem is that 64-bit libraries should never be in /usr/local/lib.
> Instead they should be in /usr/local/lib/sparcv9.

 I am not installing MPIR on these machines, as I do not have root
 access on either. Thus whatever is in /usr/local/lib is not my
 responsibility.
>>>
>>> But I was using a compiler installed in /usr/local. When that compiler was
>>> installed, by default it uses
>>>
>>> /usr/local/man - man pages
>>> /usr/local/bin - binaries
>>> /usr/local/lib  - 32-bit libraries
>>> /usr/local/lib/sparcv9 - 64-bit libraries.
>>>
>>> To answer your other question about 't2'. Agreed it has no
>>> /usr/local/lib/sparcv9, but gcc is not installed in /usr/local.
>>>
>>> Instead gcc is installed under /usr/local/gcc-4.4.1-sun-linker/
>>>
>>> So the 32-bit libraries will be under /usr/local/gcc-4.4.1-sun-linker/lib
>>> and the 64-bit libraries under /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9.
>>
>> And indeed if I add this to LD_LIBRARY_PATH, MPIR passes its tests.
>>
>> Is this a standard directory that libtool should know to look in?
>>
>>>
>>> $ ls /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9
>>> libgcc_s.so           libgomp.so.1          libssp.so.0.0.0
>>> libgcc_s.so.1         libgomp.so.1.0.0      libstdc++.a
>>> libgfortran.a         libgomp.spec          libstdc++.la
>>> libgfortran.la        libiberty.a           libstdc++.so
>>> libgfortran.so        libssp.a              libstdc++.so.6
>>> libgfortran.so.3      libssp.la             libstdc++.so.6.0.12
>>> libgfortran.so.3.0.0  libssp_nonshared.a    libsupc++.a
>>> libgomp.a             libssp_nonshared.la   libsupc++.la
>>> libgomp.la            libssp.so
>>> libgomp.so            libssp.so.0
>>>
 Libtool builds the MPIR library in a directory in the MPIR source
 tree, then links against that. This works on every other architecture
 I am aware of.
>>>
>>> libtool picks the right libraries under many programs in Solaris. I would
>>> suggest there is some error in how libtool is being used. I would ask on the
>>> libtool mailing list, and see if they can help you.
>>>
>>> Most platforms do not support both 32 and 64-bit builds, so most platforms
>>> do not have to have different directories for 32 and 64-bit libraries.
>>>
>>> The compiler should know to pick up the correct library. I've no idea why it
>>> is not in this case, but I can assure you there are many programs I've built
>>> as 64-bit under Solaris on SPARC which use libtool.
>>
>> It's because LD_LIBRARY_PATH is set incorrectly on t2.
>>
>>>
>>> You said it did not build on UltraSPARC II. I suspect you will find it will
>>> not build on any SPARC system.
>>
>> It does build in the UltraSPARC II. I was only looking at the output
>> of the C++ tests, and these had always failed on that machine, but
>> this is due to a library which is completely missing from the machine.
>> I can't change that as I do not have root access. It has failed for
>> every version of MPIR.
>>
>>>
 Libtool builds the MPIR library in a directory in the MPIR source
 tree, then links against that. This works on every other architecture
 I am aware of.
>>>
>>> Loads of packages build in Sage with libtool, and do not have this problem.
>>> Perhaps there is some mis-configuration of libtool. If the compiler is
>>> called with the -m64 option, and asked to link again

Re: [sage-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)

[Bill Hart]

Ah, got it. LD_LIBRARY_PATH_64 needs to also contain
/home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not
specified at all, i.e. left blank, the linker uses whatever is in
LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively,
which means that *all* 64 bit library paths must be in
LD_LIBRARY_PATH_64.

So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to
be set globally for users *and* we'd need libtool to recognise that it
needs to set LD_LIBRARY_PATH_64.

Unfortunately libtool doesn't do this automatically. So this is seems
to be a bug in the version of libtool we use. Another solution is to
set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually
works because the substitution is done live by the shell. In other
words, if LD_LIBRARY_PATH_64 is set to
/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all
users of t2 globally, I believe MPIR will work just fine on that
machine.

Bill.

2010/1/29 Bill Hart :
> OK, the problem is as follows. For very straightforward C programs, no
> problems occur on t2 because the compiler emits inline code for
> everything. However, once the program becomes too complicated for it
> to do this, it uses libgcc:
>
> http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
>
> The problem is, when the compiler compiles such a program, the linker
> does not know where to find libgcc on the machine. It needs to know
> that it is in:
>
> /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9
>
> However, this is not in /etc/ld.so.conf, which does not exist on
> Solaris machines, nor is it in LD_LIBRARY_PATH.
>
> Why it won't work with this in LD_LIBRARY_PATH_64 I do not know.
>
> But either way, this problem is not something we can work around in
> MPIR, that I know of. It's just that MPIR uses some very complex
> arithmetic expressions for which gcc is unable to emit inline
> assembly. Even writing a basic test case that exhibits this failure
> would be difficult.
>
> I've no idea what the solution to the problem is. Back to the sparc
> expert for this one!
>
> Bill.
>
> 2010/1/28 Bill Hart :
>> One sensible solution would seem to be to set
>> LD_LIBRARY_PATH_64=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 on t2,
>> but this actually doesn't seem to work. I'm not sure why.
>>
>> However it seems that one can just add
>> /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9 to the LD_LIBRARY_PATH (it
>> doesn't matter whether at the beginning or end) and this fixes the
>> problems on t2. Shouldn't this be done globally for all users?
>>
>> Bill.
>>
>> 2010/1/28 Bill Hart :
>>> 2010/1/28 Dr. David Kirkby :
 Bill Hart wrote:
>
> 2010/1/28 Dr. David Kirkby :
>>
>> The problem is that 64-bit libraries should never be in /usr/local/lib.
>> Instead they should be in /usr/local/lib/sparcv9.
>
> I am not installing MPIR on these machines, as I do not have root
> access on either. Thus whatever is in /usr/local/lib is not my
> responsibility.

 But I was using a compiler installed in /usr/local. When that compiler was
 installed, by default it uses

 /usr/local/man - man pages
 /usr/local/bin - binaries
 /usr/local/lib  - 32-bit libraries
 /usr/local/lib/sparcv9 - 64-bit libraries.

 To answer your other question about 't2'. Agreed it has no
 /usr/local/lib/sparcv9, but gcc is not installed in /usr/local.

 Instead gcc is installed under /usr/local/gcc-4.4.1-sun-linker/

 So the 32-bit libraries will be under /usr/local/gcc-4.4.1-sun-linker/lib
 and the 64-bit libraries under /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9.
>>>
>>> And indeed if I add this to LD_LIBRARY_PATH, MPIR passes its tests.
>>>
>>> Is this a standard directory that libtool should know to look in?
>>>

 $ ls /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9
 libgcc_s.so           libgomp.so.1          libssp.so.0.0.0
 libgcc_s.so.1         libgomp.so.1.0.0      libstdc++.a
 libgfortran.a         libgomp.spec          libstdc++.la
 libgfortran.la        libiberty.a           libstdc++.so
 libgfortran.so        libssp.a              libstdc++.so.6
 libgfortran.so.3      libssp.la             libstdc++.so.6.0.12
 libgfortran.so.3.0.0  libssp_nonshared.a    libsupc++.a
 libgomp.a             libssp_nonshared.la   libsupc++.la
 libgomp.la            libssp.so
 libgomp.so            libssp.so.0

> Libtool builds the MPIR library in a directory in the MPIR source
> tree, then links against that. This works on every other architecture
> I am aware of.

 libtool picks the right libraries under many programs in Solaris. I would
 suggest there is some error in how libtool is being used. I would ask on 
 the
 libtool mailing list, and see if they can help you.

 Most platforms do not support both 32 and 64-bit builds, so most platforms
 do not have to have different directories for 32 and 64-bit libra

[sage-devel] Re: OT: CPLEX anyone?

[dahl.joac...@gmail.com]

If you go to
http://mosek.com/index.php?id=99

you can get a free license for academics,  but you have to renew it
after 30 days.


On Jan 29, 11:05 am, Martin Albrecht 
wrote:
> On Thursday 28 January 2010, dahl.joac...@gmail.com wrote:
>
> > MOSEK provides state-of-the-art commercial LP and SOCP solvers as
> > well as MIP solvers.  They have a python interface and their academic
> > license is free.
>
> Actually, their academic license isn't free:
>
>  http://www.mosek.com/index.php?id=126
>
> Harald Schilly pointed me off list to
>
>  http://scip.zib.de/
>
> which seems to be a decent MIP solver (+ other stuff), it comes with sources
> and is free for academic use. They have a sort of weird license though, where
> you are legally bound to cite them in your paper etc. (stopping myself now,
> further discussions on licenses -> [sage-flame])
>
> Martin
>
> --
> name: Martin Albrecht
> _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
> _www:http://www.informatik.uni-bremen.de/~malb
> _jab: martinralbre...@jabber.ccc.de

-- 
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: #8044: Categories for finite/permutation/symmetric groups

[Nicolas M. Thiery]

Dear Javier, Sébastien, Robert, ...

On Fri, Jan 29, 2010 at 02:27:25AM -0800, javier wrote:
> On Jan 27, 10:28 pm, "Nicolas M. Thiery" 
> wrote:
> > about #8044: categories for finite/permutation/symmetric groups
> >
> >     * Puts all permutation groups and some other finite groups in the
> >       corresponding categories. There remains to handle finite matrix
> >       groups and Galois groups in sage/rings/number_field/.
> >
> >     * As a result, this standardizes the interface of those groups
> >       (cardinality, one, ...).
> 
> Nice! I recently had some trouble trying to sort out where to put the
> conjugacy classes code, this will be really helpful!

In fact, it is your question about conjugacy class codes that
triggered my work on categories for extension types, and then this one :-)

To answer your e-mail, I wanted to say that all the generic code
should go in the Groups() category and friends instead of the Group
class in sage.groups.group which I would like to see progressively
disappear, or at least get very thin. But for that it had to be
*possible* to do it.

Sometimes an e-mail on sage-devel can have much underground effect
even if apparently there is not much immediate feedback!

> I can't really comment on the graph stuff, but since I'll have to
> rebase the cc-patches anyway I might as well give a look to this
> one.

Excellent!

Sébastien Labbé: you played quite some with the Cayley graph
code. Would you be ok reviewing this part? (unless Robert beats you to
it). As a teaser, you might like the following:

sage: M = Monoids().example(); M
An example of a monoid: the free monoid generated by ('a', 'b', 'c', 'd')
sage: elements = [ M.prod(w) for w in 
sum((list(Words(M.semigroup_generators(),k)) for k in range(4)),[]) ]
sage: G = M.cayley_graph(elements = elements)
sage: G.show3d(color_by_label=True, edge_size=0.001, vertex_size=0.01)

(and I take your suggestions for a better way to create all words of
length <=3)

By the way, Sébastien, if you want to make a small patch on top of
#8044 which would include the cl Cayley graph examples from
cayley_graph-sl.patch, it would make sense to merge it in the same
ticket, and I'll be happy to review it.

> Which brings to the discussion: is there a standard way of reviewing
> tickets? I imagine you all sage gurus have your systematic ways
> perfected over the years. But what are precisely those steps?
> 
> For instance, something like:
> 
> 1. Update sage to the latest version with sage -upgrade
> 2. Make a clone for testing patches with sage -clone testing
> 3. Apply the patch you want to review using...
> 
> etc. I checked in the developers wiki
> http://wiki.sagemath.org/devel/TracGuidelines
> 
> but the suggestions are rather terse. How does one check 100%
> doctests? It would be great it it could be upgraded with more detailed
> instructions.

Most patches I review are in the Sage-Combinat queue, so I do the
review there. Otherwise, I do as you mention above, with

hg qinit
hg qimport ...nameofthe.patch
hg qpush
sage -b
sage -testall
... go to sleep ...

Anyone a pointer to where this procedure could already have been well
documented? It would be nice to have it in the TracGuidelines.

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

-- 
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] Re: Rational polynomials via FLINT (#4000)

[Sebastian Pancratz]

On Jan 29, 10:13 am, Bill Hart  wrote:
> I wonder if it is possible to recreate the problem just using FLINT,
> without any Sage, i.e. just write a short FLINT program which
> replicates the problem.
>
> I don't understand how the multiplication could take any serious
> quantity of time unless the pow was screwed up somehow. But perhaps it
> is.
>
> Could you insert some traces to print the values of m, the number of
> limbs of lead and (when it is computed) the number of limbs of t.
>
> Bill.

Dear Bill,

At least using a naive approach of simply writing a short C program to
go through the same FLINT calls with the same mathematical objects
did, unsurprisingly, not reproduce the problem. However, I did not
ensure that all objects had the same state (length of the coefficient
array of polynomials, limbs for the coefficients, limbs of all other
fmpz_t's involved).  Other than the above three pieces of data, which
I can print out between the FLINT calls in the code for every
fmpz_poly_t and fmpz_t involved --- I'll do this right after a seminar
which begins in a few minutes ---, is there any other piece of
information that is relevant to representing the state?

Thanks,

Sebastian

-- 
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] Re: Rational polynomials via FLINT (#4000)

[Bill Hart]

Not that I can think of at the moment.

Sometimes these bugs can be terribly subtle. The other day I tracked
down a bug in FLINT's F_mpz_div_2exp on 32 bit machines. In the end I
found the following code gave the wrong answer:

ulong a = 573498595893479UL;
ulong b = 42;
printf("%lu\n", a>>b);

The problem is, on a 32 bit machine 42 >= 32 and the shift operator
does not work on some architectures when that is the case. For the
longest time I thought this was a compiler bug!!

Bill.

On Jan 29, 11:48 am, Sebastian Pancratz  wrote:
> On Jan 29, 10:13 am, Bill Hart  wrote:
>
> > I wonder if it is possible to recreate the problem just using FLINT,
> > without any Sage, i.e. just write a short FLINT program which
> > replicates the problem.
>
> > I don't understand how the multiplication could take any serious
> > quantity of time unless the pow was screwed up somehow. But perhaps it
> > is.
>
> > Could you insert some traces to print the values of m, the number of
> > limbs of lead and (when it is computed) the number of limbs of t.
>
> > Bill.
>
> Dear Bill,
>
> At least using a naive approach of simply writing a short C program to
> go through the same FLINT calls with the same mathematical objects
> did, unsurprisingly, not reproduce the problem. However, I did not
> ensure that all objects had the same state (length of the coefficient
> array of polynomials, limbs for the coefficients, limbs of all other
> fmpz_t's involved).  Other than the above three pieces of data, which
> I can print out between the FLINT calls in the code for every
> fmpz_poly_t and fmpz_t involved --- I'll do this right after a seminar
> which begins in a few minutes ---, is there any other piece of
> information that is relevant to representing the state?
>
> Thanks,
>
> Sebastian

-- 
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] Sage Web Service / UI

[Ivan Andrus]

On Jan 29, 2010, at 7:37 AM, Robert Bradshaw wrote:

> The issue is that the Sage window is mixed up with all the other browser 
> windows, with irrelevant menu items, doesn't have its own icon in the dock, 
> and the Sage session doesn't stop when the window is closed. Now there are 
> several advantages to this from a remote users perspective, but in some ways 
> it's not as "nice" as a native app (and how much you find that annoying is a 
> matter of personal preference). Separate instances of Firefox can be started 
> up with their own user profiles--perhaps the same can be done with Safari. 
> (Well, it obviously can, see Fluid--thought that's not open source.)

I have many of the same concerns, but as I mentioned in an email a few weeks 
ago [1], Fluid is now open source (apache license) [2] and I have an example of 
what a first stab at a Fluid-based Sage.app might look like at
http://math.byu.edu/~gvol/files/fluidium-app.spkg

-Ivan

[1] 
http://groups.google.com/group/sage-devel/browse_thread/thread/814114f9f246886a/940a5cc16ac217df>
[2]

-- 
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: Sage Web Service / UI

[Ivan Andrus]

On Jan 29, 2010, at 12:21 AM, Jason Grout wrote:

> Andy Somogyi wrote:
>> Hi All
>> This was originally a discussion of how to make Sage a better desktop app.
> 
> I've wondered what the possibility was of making a Firefox extension that  
> customized firefox to be an all-in-one Sage app.  I think Firefox extensions 
> can modify the "chrome" of the browser, at least if they are given the 
> appropriate permissions to do so.

It should be possible.  Last time I looked at Prism (probably almost 2 years 
ago) I couldn't even figure out how to build it, though to be honest I didn't 
try very hard since I don't really like Firefox.  With a little hacking on a 
prebuilt version (replacing the binary with a script which called the original 
binary) I was able to get something that sort of worked (i.e. it started up the 
sage -notebook in the background).

-Ivan

 http://prism.mozilla.com/

-- 
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] Re: cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[Volker Braun]

The cdd_both_reps/cdd_both_reps_gmp are used by the new polyhedra
package, and are indeed introduced in cddlib-094f.p2.spkg.

I have no idea what the patches/allfaces.c is for - it does not part
of the cddlib library, but only some utility binary. As far as I can
tell the allfaces binary is never used by sage. Maybe whoever added it
can shed some light on this? Its not documented in the SPKG.txt, sigh.

As for the patches/cdd_both_reps-make.patch, this only records the
changes to the automake source files. You still need to run autoconf/
automake to generate the makefiles from that. I still don't know the
correct way of handling this:
  * The automake sources might be automake-version dependent.
  * Not everyone has all versions of automake installed, so spkg-
install can't call automake.
  * Running autoconf/automake generates big shell scripts (configure,
makefile). Differences in these need not be recorded.
  * But different versions of automake will produce different scripts,
which would clutter up naive patches.
See also: http://trac.sagemath.org/sage_trac/ticket/8079

I didn't realize that /src is supposed to be the pristine upstream
source. Note that I previously entered a cddlib-094f.p3.spkg into trac
for review at http://trac.sagemath.org/sage_trac/ticket/3304 to build
cddlib as a shared library as well as a couple of other improvements.
I'll try to merge the changes from your .p3 with mine and report back.

Best wishes,
Volker




On Jan 29, 10:09 am, Minh Nguyen  wrote:
> Hi folks,
>
> With Sage 4.3.2.alpha0, one has two suspicious binary files under
> SAGE_LOCAL/bin, as shown by the following hg report:
>
> [mv...@sage bin]$ pwd
> /dev/shm/mvngu/sage-4.3.2.alpha0-sage.math/local/bin
> [mv...@sage bin]$ hg status
> M sage-banner
> M sage-gdb-commands
> M sage-maxima.lisp
> M sage-verify-pyc
> ? cdd_both_reps
> ? cdd_both_reps_gmp
>
> The files in question are cdd_both_reps and cdd_both_reps_gmp. It
> turns out that these two files were put there by the package
> cddlib-094f.p2.spkg. I think they were put there due to using the
> command "patch" in spkg-install for patching the upstream source under
> src/.
>
> A problem with cddlib-094f.p2.spkg is that it patches upstream source
> using a patch file, rather than copying a patched file over to the
> appropriate place under the src/ directory. Consequently, there is no
> clean separation between upstream source and patches that we apply to
> cddlib-094f. Looking at spkg-install of cddlib-094f.p2.spkg, you get
> these two lines for applying Sage-specific patches:
>
> cp patches/allfaces.c src/src/
>
> patch -p0 < patches/cdd_both_reps-make.patch
>
> The first line is the preferred way to patch an upstream source
> because it copies the patched file patches/allfaces.c over to
> src/src/. Even before running the installation script spkg-install,
> the original upstream source is the file src/src/allfaces.c and its
> corresponding patched version for Sage is patches/allfaces.c. And you
> patch the upstream source using cp. In this way, you keep a clean
> separation between the source provided by the upstream project and the
> patches that the Sage project applies on top of the upstream source.
>
> Now let's consider the second line in the above code listing, i.e.
>
> patch -p0 < patches/cdd_both_reps-make.patch
>
> Patching an upstream source in this way results in modified upstream
> source and this modification now lives under src/, which is supposedly
> where the clean upstream source lives. Subsequently, anytime you want
> to update (not upgrade to latest upstream release) the
> cddlib-094f.p2.spkg package, you have modified source under src/. This
> can cause a lot of confusion for maintainers who need to have a clean
> separation between upstream source and Sage-specific patches.
>
> Here's an example illustrating that using the command "patch" in
> spkg-install for patching upstream source is a bad idea. Say you have
> a directory listing as follows:
>
> [mv...@sage cddlib]$ pwd
> /home/mvngu/spkg/standard/cddlib
> [mv...@sage cddlib]$ ls
> cddlib-094f.p0  cddlib-094f.p0.spkg  cddlib-094f.p2  cddlib-094f.p2.spkg
>
> In cddlib-094f.p2.spkg, the content of the file
> patches/cdd_both_reps-make.patch is
>
> [mv...@sage cddlib]$ cat cddlib-094f.p2/patches/cdd_both_reps-make.patch
> --- ../cddlib-094f/src/src-gmp/Makefile.am      2009-01-26 09:30:16.0 
> +
> +++ src/src-gmp/Makefile.am     2009-10-04 10:36:17.0 +0100
> @@ -11,7 +11,8 @@
>  testcdd2_gmp \
>  testlp1_gmp \
>  testlp2_gmp \
> -testlp3_gmp
> +testlp3_gmp \
> +cdd_both_reps_gmp
>  #cddmathlink
>
>  scdd_gmp_SOURCES                   = simplecdd.c
> @@ -27,6 +28,7 @@
>  testlp1_gmp_SOURCES                = testlp1.c
>  testlp2_gmp_SOURCES                = testlp2.c
>  testlp3_gmp_SOURCES                = testlp3.c
> +cdd_both_reps_gmp_SOURCES          = cdd_both_reps.c
>  # cddmathlink_SOURCES                = cddmathlink.c cddmlio.h cddmlio.c
>
>  LDADD        = ../li

[sage-devel] Sage patches added directly to symmetica source

[Dr. David Kirkby]

Minh's comment about cddlib-094f.p2.spkg reminded me that Symmetrica does this 
too. In fact, I have a patch I'd like to add, but it's anyone's guess how to do 
it properly. I have the revised package at


http://boxen.math.washington.edu/home/kirkby/portability/symmetrica-2.0.p5/

There's a patch to the makefile, and another to spkg-install.


Dave

--
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] Re: Rational polynomials via FLINT (#4000)

[Sebastian Pancratz]

I think there might have been some progress:

sage: R. = QQ[]
sage: f = 3/2*x - 1/3
sage: _ = f % f
Begin: fmpz_poly_pseudo_divrem(quo, r.num, &m, a.num, b.num)
  a.num = 9*t-2
  fmpz_poly_length(a.num) = 2
  fmpz_poly_max_limbs(a.num) = 1
  b.num = 9*t-2
  fmpz_poly_length(b.num) = 2
  fmpz_poly_max_limbs(b.num) = 1
  quo   = 1
  r.num = 0
  m = 120658626
End: fmpz_poly_pseudo_divrem
Begin: fmpz_pow_ui(t, lead, m)
  t = 0   fmpz_size(t) = 0
  lead = 9   fmpz_size(lead) = 1
  m = 120658626
End: fmpz_pow_ui

--- I'll upload a patch to #4000 in a few minutes so that someone else
(Alex?) could confirm that the problem they experience arises in a
similar way. ---

The above output shows that the "fmpz_pow_ui" takes a long time for a
good reason:  it's computing t = 9^120658626.  So the next question
is, why is the m this large?

The value of m is set by the call "fmpz_poly_pseudo_divrem(quo, r.num,
&m, a.num, b.num)", where as the output above shows we have a.num and
b.num both equal the polynomial 9*t-2.  From the FLINT (1.5.0) manual,
this call should set quo=Q, r.num=R and m such that

lead(B)^m*A = B*Q + R

and the degree of R is less than the degree of B, where a.num=A,
b.num=B and lead(B) is the leading coefficient of B.  Here we have A =
B = 9*t-2 and lead(B) = 9.  The output above shows that Q and R are
computed correctly as 1 and 0, but I would expect that m should be set
to 0 rather than 120658626.

Nonetheless, I haven't managed to reproduce this in plain C (with
std=c99 and FLINT) yet, so at the moment I am still clueless regarding
how to fix this problem.

Sebastian

-- 
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] Re: cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[mhampton]

The allfaces.c file is mentioned in the cddlib manual as an example
file.  Its been in the sage spkg for a long time, I think.  Probably
it was originally included to show sage developers how to use the
library.  So it seems to make sense to get rid of it after #8115 is
sorted out, since cdd_both_reps provides an example that is actually
used.

My apologies for missing this issue in review - makefiles and
libraries are not my strong suit.

-Marshall

On Jan 29, 7:11 am, Volker Braun  wrote:
> The cdd_both_reps/cdd_both_reps_gmp are used by the new polyhedra
> package, and are indeed introduced in cddlib-094f.p2.spkg.
>
> I have no idea what the patches/allfaces.c is for - it does not part
> of the cddlib library, but only some utility binary. As far as I can
> tell the allfaces binary is never used by sage. Maybe whoever added it
> can shed some light on this? Its not documented in the SPKG.txt, sigh.
>
> As for the patches/cdd_both_reps-make.patch, this only records the
> changes to the automake source files. You still need to run autoconf/
> automake to generate the makefiles from that. I still don't know the
> correct way of handling this:
>   * The automake sources might be automake-version dependent.
>   * Not everyone has all versions of automake installed, so spkg-
> install can't call automake.
>   * Running autoconf/automake generates big shell scripts (configure,
> makefile). Differences in these need not be recorded.
>   * But different versions of automake will produce different scripts,
> which would clutter up naive patches.
> See also:http://trac.sagemath.org/sage_trac/ticket/8079
>
> I didn't realize that /src is supposed to be the pristine upstream
> source. Note that I previously entered a cddlib-094f.p3.spkg into trac
> for review athttp://trac.sagemath.org/sage_trac/ticket/3304to build
> cddlib as a shared library as well as a couple of other improvements.
> I'll try to merge the changes from your .p3 with mine and report back.
>
> Best wishes,
> Volker
>
> On Jan 29, 10:09 am, Minh Nguyen  wrote:
>
> > Hi folks,
>
> > With Sage 4.3.2.alpha0, one has two suspicious binary files under
> > SAGE_LOCAL/bin, as shown by the following hg report:
>
> > [mv...@sage bin]$ pwd
> > /dev/shm/mvngu/sage-4.3.2.alpha0-sage.math/local/bin
> > [mv...@sage bin]$ hg status
> > M sage-banner
> > M sage-gdb-commands
> > M sage-maxima.lisp
> > M sage-verify-pyc
> > ? cdd_both_reps
> > ? cdd_both_reps_gmp
>
> > The files in question are cdd_both_reps and cdd_both_reps_gmp. It
> > turns out that these two files were put there by the package
> > cddlib-094f.p2.spkg. I think they were put there due to using the
> > command "patch" in spkg-install for patching the upstream source under
> > src/.
>
> > A problem with cddlib-094f.p2.spkg is that it patches upstream source
> > using a patch file, rather than copying a patched file over to the
> > appropriate place under the src/ directory. Consequently, there is no
> > clean separation between upstream source and patches that we apply to
> > cddlib-094f. Looking at spkg-install of cddlib-094f.p2.spkg, you get
> > these two lines for applying Sage-specific patches:
>
> > cp patches/allfaces.c src/src/
>
> > patch -p0 < patches/cdd_both_reps-make.patch
>
> > The first line is the preferred way to patch an upstream source
> > because it copies the patched file patches/allfaces.c over to
> > src/src/. Even before running the installation script spkg-install,
> > the original upstream source is the file src/src/allfaces.c and its
> > corresponding patched version for Sage is patches/allfaces.c. And you
> > patch the upstream source using cp. In this way, you keep a clean
> > separation between the source provided by the upstream project and the
> > patches that the Sage project applies on top of the upstream source.
>
> > Now let's consider the second line in the above code listing, i.e.
>
> > patch -p0 < patches/cdd_both_reps-make.patch
>
> > Patching an upstream source in this way results in modified upstream
> > source and this modification now lives under src/, which is supposedly
> > where the clean upstream source lives. Subsequently, anytime you want
> > to update (not upgrade to latest upstream release) the
> > cddlib-094f.p2.spkg package, you have modified source under src/. This
> > can cause a lot of confusion for maintainers who need to have a clean
> > separation between upstream source and Sage-specific patches.
>
> > Here's an example illustrating that using the command "patch" in
> > spkg-install for patching upstream source is a bad idea. Say you have
> > a directory listing as follows:
>
> > [mv...@sage cddlib]$ pwd
> > /home/mvngu/spkg/standard/cddlib
> > [mv...@sage cddlib]$ ls
> > cddlib-094f.p0  cddlib-094f.p0.spkg  cddlib-094f.p2  cddlib-094f.p2.spkg
>
> > In cddlib-094f.p2.spkg, the content of the file
> > patches/cdd_both_reps-make.patch is
>
> > [mv...@sage cddlib]$ cat cddlib-094f.p2/patches/cdd_both_reps-make.patch
> > --- ../cddlib-094f/src/s

Re: [sage-devel] Re: Rational polynomials via FLINT (#4000)

[Willem Jan Palenstijn]

On Fri, Jan 29, 2010 at 05:58:39AM -0800, Sebastian Pancratz wrote:
> The value of m is set by the call "fmpz_poly_pseudo_divrem(quo, r.num,
> &m, a.num, b.num)", where as the output above shows we have a.num and
> b.num both equal the polynomial 9*t-2.  From the FLINT (1.5.0) manual,
> this call should set quo=Q, r.num=R and m such that
> 
> lead(B)^m*A = B*Q + R
> 
> and the degree of R is less than the degree of B, where a.num=A,
> b.num=B and lead(B) is the leading coefficient of B.  Here we have A =
> B = 9*t-2 and lead(B) = 9.  The output above shows that Q and R are
> computed correctly as 1 and 0, but I would expect that m should be set
> to 0 rather than 120658626.

fmpz_poly_pseudo_divrem has a bug in the special case for A == B, where it sets
d instead of *d to 0.

-Willem Jan

-- 
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] Re: cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[Minh Nguyen]

Hi folks,

On Fri, Jan 29, 2010 at 9:09 PM, Minh Nguyen  wrote:



> A problem with cddlib-094f.p2.spkg is that it patches upstream source
> using a patch file, rather than copying a patched file over to the
> appropriate place under the src/ directory. Consequently, there is no
> clean separation between upstream source and patches that we apply to
> cddlib-094f.

I just want to clarify some points about my previous email.

* I'm not arguing that the command "patch" should never be used in the
installation script of an spkg. You can use it if you wish, but please
be careful not to mix and match. Try to be consistent across the whole
spkg-install file.

* When you're packaging an spkg, ensure that your patch(es) are not
already applied to the relevant files under src/. This is the case
with cddlib-094f.p2.spkg, which has modified source under src/. The
patching process should be done during the (re)installation of the
spkg.

Thanks to Willem Jan Palenstijn for clarifying my thoughts on the
subject of this thread. In the same spirit as ticket #8079 [1], I'm
more interested in documenting best practices for patching spkg's.

[1] http://trac.sagemath.org/sage_trac/ticket/8079

-- 
Regards
Minh Van Nguyen

-- 
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] Re: Rational polynomials via FLINT (#4000)

[Sebastian Pancratz]

On Jan 29, 2:22 pm, Willem Jan Palenstijn  wrote:
> On Fri, Jan 29, 2010 at 05:58:39AM -0800, Sebastian Pancratz wrote:
> > The value of m is set by the call "fmpz_poly_pseudo_divrem(quo, r.num,
> > &m, a.num, b.num)", where as the output above shows we have a.num and
> > b.num both equal the polynomial 9*t-2.  From the FLINT (1.5.0) manual,
> > this call should set quo=Q, r.num=R and m such that
>
> >     lead(B)^m*A = B*Q + R
>
> > and the degree of R is less than the degree of B, where a.num=A,
> > b.num=B and lead(B) is the leading coefficient of B.  Here we have A =
> > B = 9*t-2 and lead(B) = 9.  The output above shows that Q and R are
> > computed correctly as 1 and 0, but I would expect that m should be set
> > to 0 rather than 120658626.
>
> fmpz_poly_pseudo_divrem has a bug in the special case for A == B, where it 
> sets
> d instead of *d to 0.
>
> -Willem Jan

Thanks!

Later tonight I'll update the patch on ticket #4000 to work around
that.  By the way, it seems the problem only appears when A == B, not
when they are different objects in memory merely representing the same
integer polynomials.

Sebastian

-- 
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: cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[Dag Sverre Seljebotn]

Minh Nguyen wrote:

Hi folks,

On Fri, Jan 29, 2010 at 9:09 PM, Minh Nguyen  wrote:



  

A problem with cddlib-094f.p2.spkg is that it patches upstream source
using a patch file, rather than copying a patched file over to the
appropriate place under the src/ directory. Consequently, there is no
clean separation between upstream source and patches that we apply to
cddlib-094f.



I just want to clarify some points about my previous email.

* I'm not arguing that the command "patch" should never be used in the
installation script of an spkg. You can use it if you wish, but please
be careful not to mix and match. Try to be consistent across the whole
spkg-install file.
  

But does not Volker Braun have a point when it comes to autotools?

IMO, in the specific case of autotools, it makes perfect sense to 
include a diff for configure.in etc. in patches, but include the 
generated Makefiles verbatim in patches -- since after patching 
configure.in and rerunning autotools (perhaps with a different version 
of autotools than upstream), the diffs really do not contain useful 
information beyond what the full generated Makefiles does -- the 
human-readable difference information is in the configure.in patch.


I hope the Sage reviewers are willing to make an exception for autotools 
in this respect in SPKGs.


Dag Sverre

--
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] Re: cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[Volker Braun]

Another question about keeping src/ unmodified: Often the upstream
packages contain large examples and package 3rd-party libraries. For
example, cddlib-0.94f.spkg (before .p2) had already deleted ~2MB of
example files as well as a bundled gmp library that is in the upstream
package. This was documented in the SPKG.txt "Special Update/Build
Instructions" section. Is deleting cruft from src/ ok?

Cheers,
Volker



On Jan 29, 2:27 pm, Minh Nguyen  wrote:
> Hi folks,
>
> On Fri, Jan 29, 2010 at 9:09 PM, Minh Nguyen  wrote:
>
> 
>
> > A problem with cddlib-094f.p2.spkg is that it patches upstream source
> > using a patch file, rather than copying a patched file over to the
> > appropriate place under the src/ directory. Consequently, there is no
> > clean separation between upstream source and patches that we apply to
> > cddlib-094f.
>
> I just want to clarify some points about my previous email.
>
> * I'm not arguing that the command "patch" should never be used in the
> installation script of an spkg. You can use it if you wish, but please
> be careful not to mix and match. Try to be consistent across the whole
> spkg-install file.
>
> * When you're packaging an spkg, ensure that your patch(es) are not
> already applied to the relevant files under src/. This is the case
> with cddlib-094f.p2.spkg, which has modified source under src/. The
> patching process should be done during the (re)installation of the
> spkg.
>
> Thanks to Willem Jan Palenstijn for clarifying my thoughts on the
> subject of this thread. In the same spirit as ticket #8079 [1], I'm
> more interested in documenting best practices for patching spkg's.
>
> [1]http://trac.sagemath.org/sage_trac/ticket/8079
>
> --
> Regards
> Minh Van Nguyen

-- 
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-support] Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)

[Dr. David Kirkby]

Bill Hart wrote:

Ah, got it. LD_LIBRARY_PATH_64 needs to also contain
/home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not
specified at all, i.e. left blank, the linker uses whatever is in
LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively,
which means that *all* 64 bit library paths must be in
LD_LIBRARY_PATH_64.

So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to
be set globally for users *and* we'd need libtool to recognise that it
needs to set LD_LIBRARY_PATH_64.

Unfortunately libtool doesn't do this automatically. So this is seems
to be a bug in the version of libtool we use. Another solution is to
set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually
works because the substitution is done live by the shell. In other
words, if LD_LIBRARY_PATH_64 is set to
/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all
users of t2 globally, I believe MPIR will work just fine on that
machine.

Bill.


I do not believe it is correct to add the sparcv9 directory to LD_LIBRARY_PATH, 
though I accept it might solve the issue. If anything, that would be added to 
LD_LIBRARY_PATH_64, but that is not working here.


I would speak to the libtool developers - I know Ralf is very helpful, and has 
an account on 't2'. Perhaps he can solve this.


Are you using the latest libtool ? If not, an upgrade might work.

Dave

--
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: cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[Minh Nguyen]

Hi Volker,

On Sat, Jan 30, 2010 at 2:37 AM, Volker Braun  wrote:



> package. This was documented in the SPKG.txt "Special Update/Build
> Instructions" section. Is deleting cruft from src/ ok?

Yes, I think that's OK. Many spkg's do that to reduce its sizes.

-- 
Regards
Minh Van Nguyen

-- 
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: Sage Web Service / UI

[Andy Somogyi]

I'm putting together a quick and dirty app, that basically consists of a form 
which holds a WebKit widget, and the main process just forks, and initiates the 
Sage process, and hooks the WebKit view up to it. Should be ready this weekend. 
Its super simple, but its a start. 

Its tiny, a few 100K, and completely native. It literally took ONE SINGLE line 
of code to hook up the webkit view to the Sage server. I'm just cleaning up up 
the forking a bit which is a tad more complex, but will probably be around 10 - 
20 lines or so. Then, the entire sage directory can just be copied into the 
.app directory, and will look and feel and run like a standard app. Also, there 
is NO ADDITIONAL DEPENDENCIES, WebKit is a library that is standard on OSX, and 
any Linux distro that has KDE. Safari is just a simple app that hosts the 
WebKit widget.  

FYI, how Mac applications are structured is each application is a special 
directory, which ends in .app. This directory contains the executable, icons, 
property lists, configuration, and whatever else the developer wants to shove 
in it (like the whole sage distribution). This way, the whole directory just 
looks like a single app to the end user. 

I don't do Windows (anymore), but I'm sure someone out there is a C# person who 
could whip up a Windows equivalent in a few hours, i.e. take the WebKit or 
Firefox ActiveX control, and drop it on a form, hook up the process bits, and 
package it up into a directory. 

The other HUGE thing that HTML5 gives is interactivity, so its fully capable of 
having the same kind of interactivity that Mathematica 6+ has with the 
'Manipulate' function. 



On Jan 29, 2010, at 7:58 AM, Ivan Andrus wrote:

> On Jan 29, 2010, at 12:21 AM, Jason Grout wrote:
> 
>> Andy Somogyi wrote:
>>> Hi All
>>> This was originally a discussion of how to make Sage a better desktop app.
>> 
>> I've wondered what the possibility was of making a Firefox extension that  
>> customized firefox to be an all-in-one Sage app.  I think Firefox extensions 
>> can modify the "chrome" of the browser, at least if they are given the 
>> appropriate permissions to do so.
> 
> It should be possible.  Last time I looked at Prism (probably almost 2 years 
> ago) I couldn't even figure out how to build it, though to be honest I didn't 
> try very hard since I don't really like Firefox.  With a little hacking on a 
> prebuilt version (replacing the binary with a script which called the 
> original binary) I was able to get something that sort of worked (i.e. it 
> started up the sage -notebook in the background).
> 
> -Ivan
> 
> http://prism.mozilla.com/
> 
> -- 
> 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

-- 
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] compiling Sage 4.3.2.alpha0 consistently hangs on sage.math

[Minh Nguyen]

Hi folks,

When compiling Sage 4.3.2.alpha0 [1] on the machine sage.math, the
build always hang when running the configuration script of
libgcrypt-1.4.4.p2.spkg, here's a relevant snippet of where the build
consistently hangs, regardless of whether my compilation took place
under /scratch/mvngu/release or /dev/shm/mvngu:

checking for getrusage... yes
checking for gethrtime... no
checking for clock_gettime... no
checking for syslog... yes
checking for fcntl... yes
checking for ftruncate... yes
checking for mlock... yes
checking for sysconf... (cached) yes
checking for getpagesize... (cached) yes
checking whether mlock is broken...

The build just hangs at this line.

This follows when, from within a screen session, I was parallel
doctesting with 12 threads on sage.math. After a few minutes, my
screen session froze and I logged off sage.math by closing my terminal
window. I now have a bunch of zombie processes floating around on
sage.math.

[1] http://sage.math.washington.edu/home/mvngu/sage-src/sage-4.3.2.alpha0.tar

-- 
Regards
Minh Van Nguyen

-- 
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] Re: compiling Sage 4.3.2.alpha0 consistently hangs on sage.math

[William Stein]

On Fri, Jan 29, 2010 at 8:38 AM, Minh Nguyen  wrote:
> Hi folks,
>
> When compiling Sage 4.3.2.alpha0 [1] on the machine sage.math, the
> build always hang when running the configuration script of

As another data point, I also build sage-4.3.2.alpha0 on sage.math in

   /scratch/wstein/build/sage-4.3.2.alpha0

It worked fine (no trouble at all with libgcrypt) and passed all tests except
multi_polynomial_libsingular.pyx.

I see you have one running process:

10108 mvngu 20   0 000 R  100  0.0 205:19.43 optimal

I ran tests on skynet 2 days ago and *also* end up with that "optimal"
running process sticking around.  It ended up possibly crashing
skynet, by the way.

What is this "optimal" program in Sage??!

I just tried to kill -9 yours... with no real luck.

Optimal is in sage-4.3.2.alpha0's local/bin:

wst...@sage:~/build/sage-4.3.2.alpha0/local/bin$ ./optimal -?
using quarter turn metric
no search limit
using symmetry reductions
finding all solutions

initializing transformation tables
initializing distance table ... this will take several minutes
distance positions (quotient)
  0q 1 (   1)

It's also in sage-4.3:

wst...@sage:~/build/sage-4.3/local/bin$ ./optimal
using quarter turn metric
no search limit


Checking the timestamp of optimal in my build and comparing to the
time stamps of the files in spkg/installed/ tells us something about
which package installed 'optimal':

It has to be one of these programs:

-rw-r--r-- 1 wstein wstein 253 2010-01-26 17:10 zn_poly-0.9.p1
-rw-r--r-- 1 wstein wstein 254 2010-01-26 17:10 ratpoints-2.1.3
-rw-r--r-- 1 wstein wstein 251 2010-01-26 17:09 ecm-6.2.1.p1
-rw-r--r-- 1 wstein wstein 258 2010-01-26 17:09 rubiks-20070912.p10
-rw-r--r-- 1 wstein wstein 247 2010-01-26 17:09 r-2.10.1
-rw-r--r-- 1 wstein wstein 249 2010-01-26 17:09 rpy2-2.0.8

I'm guessing it was rubiks, so I try "sage -f" 'ing that to see if it
changes the timestamp of local/bin/optimal:

wst...@sage:~/build/sage-4.3.2.alpha0$ ls -lh local/bin/optimal
-rwxr-xr-x 1 wstein wstein 144K 2010-01-29 08:57 local/bin/optimal

It does!   So your hung optimal is in the rubik's package, which has
been unchanged for years.  Hmmm.




> libgcrypt-1.4.4.p2.spkg, here's a relevant snippet of where the build
> consistently hangs, regardless of whether my compilation took place
> under /scratch/mvngu/release or /dev/shm/mvngu:
>
> checking for getrusage... yes
> checking for gethrtime... no
> checking for clock_gettime... no
> checking for syslog... yes
> checking for fcntl... yes
> checking for ftruncate... yes
> checking for mlock... yes
> checking for sysconf... (cached) yes
> checking for getpagesize... (cached) yes
> checking whether mlock is broken...
>
> The build just hangs at this line.
>
> This follows when, from within a screen session, I was parallel
> doctesting with 12 threads on sage.math. After a few minutes, my
> screen session froze and I logged off sage.math by closing my terminal
> window. I now have a bunch of zombie processes floating around on
> sage.math.
>
> [1] http://sage.math.washington.edu/home/mvngu/sage-src/sage-4.3.2.alpha0.tar
>
> --
> Regards
> Minh Van Nguyen
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage.math users" group.
> To post to this group, send email to sagemath-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> sagemath-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/sagemath-users?hl=en.
>
>



-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

-- 
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: compiling Sage 4.3.2.alpha0 consistently hangs on sage.math

[Minh Nguyen]

Hi William,

On Sat, Jan 30, 2010 at 3:58 AM, William Stein  wrote:



> I ran tests on skynet 2 days ago and *also* end up with that "optimal"
> running process sticking around.  It ended up possibly crashing
> skynet, by the way.

I have no such luck ;-)

After my last doctest on skynet which crashed eno, I'm no longer able
to ssh to eno. In some ways this can be a good thing. I have thrice
crashed some machines on skynet while doctesting. I don't fancy having
another doctesting session that results in a fourth crash.


> What is this "optimal" program in Sage??!
>
> I just tried to kill -9 yours... with no real luck.

Me neither. I spent the better half of the last hour trying to "kill
-9" that optimal process, but to no avail.

-- 
Regards
Minh Van Nguyen

-- 
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] Sage patches added directly to symmetica source

[Minh Nguyen]

Hi David,

On Sat, Jan 30, 2010 at 12:49 AM, Dr. David Kirkby
 wrote:
> Minh's comment about cddlib-094f.p2.spkg reminded me that Symmetrica does
> this too.

Could you please open a ticket for this?

-- 
Regards
Minh Van Nguyen

-- 
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] Re: Upgrading networkx - unpickling issue

[Greg McWhirter]

Thanks for the rely. I tried that with boh Graph and Poset (since
graph failed as well) under networkx-0.36 and networkx-1.0.1 both un
un-patched 4.3.1 and patched to account for 1.0.1.
However, everything went through without a hitch.

Un tar-ing the pickle_jar and load
("_class__sage_graphs_graph_Graph__.sobj") or load
("_class__sage_combinat_posets_posets_FinitePoset__.sobj") gives the
error of "ImportError: No module named xgraph" or "ImportError: No
module named xdigraph" respectively (these modules held the classes
removed between 0.36 and 1.0.1). I don't know where these are getting
called if the lines output by explain(dumps(P)) all work?

- Greg

On Jan 29, 1:27 am, "Nicolas M. Thiery" 
wrote:
>         Hi Greg!
>
> On Thu, Jan 28, 2010 at 08:27:30PM -0800, Greg McWhirter wrote:
> > I've been working on upgrading networkx to 1.0.1 for the past couple
> > days and have things passing almost all the tests (modulo some answer
> > correction for changed format of networkx representations)
>
> Thanks for your work: +1 on staying synchronized with networkx!
>
> > The other big block of tests that don't pass are unpickling tests from
> > sage/structure/sage_object.pyx
> > I am wondering how big a problem this really is?
>
> > Looking at some of the classes for some of the things it fails on
> > (detailed at the bottom), it seems they use a graph object somewhere
> > in the internals. I am guessing that since networkx removed the XGraph
> > and XDiGraph objects somewhere between 0.36 (which is the version
> > currently shipping with sage) and 1.0.1, the pickled objects can't
> > find those classes and fail to unpickle. However, I don't know how to
> > test that exactly, nor what to do about it (possibly patching networkx
> > to do something when asked for those classes, loading up the up-to-
> > date ones instead?)
>
> A confirmation: dynkin diagrams inherit from DiGraph, and all crystals
> point to a dynkin diagram. Similarly for posets. So if some type of
> graphs don't unpickle, I am not surprised for all of this to fail.
>
> The following command (to be run with Sage with the old networkx)
> tells you what will happens upon later unpickling, say, a poset:
>
>     sage: P = Poset()
>     sage: explain_pickle(dumps(P))
>     pg_FinitePoset = unpickle_global('sage.combinat.posets.posets', 
> 'FinitePoset')
>     si1 = unpickle_newobj(pg_FinitePoset, ())
>     pg_HasseDiagram = unpickle_global('sage.combinat.posets.hasse_diagram', 
> 'HasseDiagram')
>     si2 = unpickle_newobj(pg_HasseDiagram, ())
>     pg_SparseGraphBackend = unpickle_global('sage.graphs.base.sparse_graph', 
> 'SparseGraphBackend')
>     si3 = unpickle_newobj(pg_SparseGraphBackend, ())
>     pg_SparseGraph = unpickle_global('sage.graphs.base.sparse_graph', 
> 'SparseGraph')
>     unpickle_build(si3, {'_cg_rev':pg_SparseGraph(0r, 16r, 10r, [], []), 
> 'directed':True, 'vertex_labels':{}, '_multiple_edges':False, 
> '_directed':True, '_name':'', 'vertex_ints':{}, '_loops':False, 
> 'edge_labels':{0r:None}, '_cg':pg_SparseGraph(0r, 16r, 10r, [], [])})
>     unpickle_build(si2, {'_weighted':False, '_pos':None, '_boundary':[], 
> '_latex_opts':None, '_backend':si3})
>     unpickle_build(si1, {'_hasse_diagram':si2, '_embedding':None, 
> '_convert_method_name':None, '_cdata':None, '_category':None, '_names':None, 
> '_generators':None, '_elements':[], '_hash':None, '_pickle_version':1r, 
> '_element_constructor':None, '_initial_convert_list':[], 
> '_element_init_pass_parent':False, '_initial_action_list':[], 
> '_initial_coerce_list':[], '_base':None})
>     si1
>
> Then, you can just copy paste the commands in a Sage with the new
> networkx, and see what breaks. Most likely it is the
> SparseGraphBackend thing.  If it's just a question of renamed class,
> then you can add something along the following lines somewhere in the
> graph code:
>
>         from sage.structure.sage_object import register_unpickle_override
>         
> register_unpickle_override('sage.graphs.base.sparse_graph','SparseGraphBack 
> end',
>                                     the previous thing>)
>
> Cheers,
>                                 Nicolas
> --
> Nicolas M. Thi ry "Isil" http://Nicolas.Thiery.name/

-- 
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: Upgrading networkx - unpickling issue

[Robert Miller]

> Un tar-ing the pickle_jar and load
> ("_class__sage_graphs_graph_Graph__.sobj") or load
> ("_class__sage_combinat_posets_posets_FinitePoset__.sobj") gives the
> error of "ImportError: No module named xgraph" or "ImportError: No
> module named xdigraph" respectively (these modules held the classes
> removed between 0.36 and 1.0.1).

If you have an old NetworkX graph N, most of the information is in the
property N.adj. This is just an adjacency dictionary, and I can't
imagine the NX people deprecating that format as input for their new
graph classes.




-- 
Robert L. Miller
http://www.rlmiller.org/

-- 
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] problem with "text"

[John H Palmieri]

With Sage 4.3.2.alpha0, command line or notebook:

sage: text(r"$\left(2 a=b\right)$", (2,3))   # works fine
sage: text(r"$(2 \, a=b)$", (2,3))   # works fine
sage: text(r"$\left(2 \, a=b\right)$", (2,3))   # error!
Traceback (click to the left of this block for traceback)
...
AttributeError: 'Kern' object has no attribute 'height'

Any ideas what's going on?

--
John

-- 
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] Re: Unknown control sequence '\texttt'

[John H Palmieri]

On Jan 29, 2:09 am, lutusp  wrote:
> > Give some examples, please.
>
> var("y R")
>
> a(y,R) = pi * (2*R - y) * y
>
> lbl = text("$\int \  " + latex(a(y,R)) + "$",(3,20))
>
> view(lbl)
>  ... Graphics object consisting of 1 graphics primitive (not
> displayed)
> show(lbl)
>  ...  Unknown control sequence '\texttt'

When I evaluate "lbl", I don't get a picture; something is broken in
the "text" command.  Because there is no picture, "show" defaults to
trying to print a text description, leading to this message.  The
patch fixes it so the text description prints correctly.  I don't know
why "text" is broken, but  I bet someone can help.

By the way, if I run

var("y R")
a(y,R) = pi * (2*R - y) * y
lbl = text("$\int \  " + r"{\left(2 R - y\right)} \pi y" + "$",
(3,20))

then executing "lbl" or "show(lbl)" produce a picture.  If I change
the last line to

lbl = text("$\int \  " + r"{\left(2 \, R - y\right)} \pi y" + "$",
(3,20))   # insert \, between 2 and R

I get an error.

> No graphics shown.
>
> > By the way, have you tried the patch I mentioned in my other message today?
>
> I initially dealt with Sage problems that way, but the patches keep
> changing with each new version while the problem remains unsolved. I
> eventually concluded it was simpler not to upgrade. The present
> problem is less severe in earlier versions.

Then why do you bother posting things that look like requests for
help?

--
John

-- 
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] Re: Upgrading networkx - unpickling issue

[Greg McWhirter]

They didn't deprecate it, but they changed the format somewhat.

For instance:

sage: import networkx
sage: networkx.__version__
'0.36'
sage: N = networkx.complete_graph(4)
sage: N.adj
{0: {1: None, 2: None, 3: None}, 1: {0: None, 2: None, 3: None}, 2:
{0: None, 1: None, 3: None}, 3: {0: None, 1: None, 2: None}}

compared with:

sage: import networkx
sage: networkx.__version__
'1.0.1'
sage: N = networkx.complete_graph(4)
sage: N.adj
{0: {1: {}, 2: {}, 3: {}}, 1: {0: {}, 2: {}, 3: {}}, 2: {0: {}, 1: {},
3: {}}, 3: {0: {}, 1: {}, 2: {}}}

But that still doesn't entire answer what is asking for the xgraph or
xdigraph modules (so far as I can tell, though I could be wrong)

- Greg
On Jan 29, 9:48 am, Robert Miller  wrote:
> > Un tar-ing the pickle_jar and load
> > ("_class__sage_graphs_graph_Graph__.sobj") or load
> > ("_class__sage_combinat_posets_posets_FinitePoset__.sobj") gives the
> > error of "ImportError: No module named xgraph" or "ImportError: No
> > module named xdigraph" respectively (these modules held the classes
> > removed between 0.36 and 1.0.1).
>
> If you have an old NetworkX graph N, most of the information is in the
> property N.adj. This is just an adjacency dictionary, and I can't
> imagine the NX people deprecating that format as input for their new
> graph classes.
>
> --
> Robert L. Millerhttp://www.rlmiller.org/

-- 
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: compiling Sage 4.3.2.alpha0 consistently hangs on sage.math

[William Stein]

On Fri, Jan 29, 2010 at 9:12 AM, Minh Nguyen  wrote:
> Hi William,
>
> On Sat, Jan 30, 2010 at 3:58 AM, William Stein  wrote:
>
> 
>
>> I ran tests on skynet 2 days ago and *also* end up with that "optimal"
>> running process sticking around.  It ended up possibly crashing
>> skynet, by the way.
>
> I have no such luck ;-)
>
> After my last doctest on skynet which crashed eno, I'm no longer able
> to ssh to eno. In some ways this can be a good thing. I have thrice
> crashed some machines on skynet while doctesting. I don't fancy having
> another doctesting session that results in a fourth crash.
>
>
>> What is this "optimal" program in Sage??!
>>
>> I just tried to kill -9 yours... with no real luck.
>
> Me neither. I spent the better half of the last hour trying to "kill
> -9" that optimal process, but to no avail.

Did you try lsof to try to nail down what relevant resources might be
involved?  Often the kernel will not remove a process from the process
table until it frees up resources, which sometimes it can't do until
other
processes do.  Right now the line for optimal in top is:

10108 mvngu 20   0 000 R  100  0.0 281:36.96 optimal

This means that optimal is not using any memory resources at all (but
100% cpu, which is annoying).  The "R" means that there is a resource
that the kernel is waiting on before it will remove optimal from the
process table.

Given this:

r...@sage:/home/wstein# lsof -p 10108
COMMAND   PID  USER   FD  TYPE DEVICE SIZE/OFFNODE NAME
optimal 10108 mvngu  cwd   DIR8,10 1984176
/mnt/usb1/scratch/mvngu/release/sage-4.3.2.alpha0/devel/sage-main/sage/interfaces
(deleted)
optimal 10108 mvngu  rtd   DIR   8,33 4096   2 /
optimal 10108 mvngu  txt   unknown
/proc/10108/exe (readlink: No such file or directory)


I'm guessing there is something funny with how sage.math (=Ubuntu
9.10) deals with the external USB disk.   It may make sense to try
remounting that disk.I wonder if you deleting that directory (the
sage-4.3.2.alpha0) install also confused things... but I don't know.

William

-- 
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: cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[William Stein]

On Fri, Jan 29, 2010 at 6:27 AM, Minh Nguyen  wrote:
> Hi folks,
>
> On Fri, Jan 29, 2010 at 9:09 PM, Minh Nguyen  wrote:
>
> 
>
>> A problem with cddlib-094f.p2.spkg is that it patches upstream source
>> using a patch file, rather than copying a patched file over to the
>> appropriate place under the src/ directory. Consequently, there is no
>> clean separation between upstream source and patches that we apply to
>> cddlib-094f.
>
> I just want to clarify some points about my previous email.
>
> * I'm not arguing that the command "patch" should never be used in the
> installation script of an spkg. You can use it if you wish, but please
> be careful not to mix and match. Try to be consistent across the whole
> spkg-install file.

I think the command "patch" should absolutely never, ever be used in
the installation script of an spkg.There are platforms that don't
have patch preinstalled, and it is not a prerequisite for installing
Sage (according to the README).  It is also simply not necessary as
you explained.

 --William

>
> * When you're packaging an spkg, ensure that your patch(es) are not
> already applied to the relevant files under src/. This is the case
> with cddlib-094f.p2.spkg, which has modified source under src/. The
> patching process should be done during the (re)installation of the
> spkg.
>
> Thanks to Willem Jan Palenstijn for clarifying my thoughts on the
> subject of this thread. In the same spirit as ticket #8079 [1], I'm
> more interested in documenting best practices for patching spkg's.
>
> [1] http://trac.sagemath.org/sage_trac/ticket/8079
>
> --
> Regards
> Minh Van Nguyen
>
> --
> 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
>



-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

-- 
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] Sage Web Service / UI

[David Joyner]

On Fri, Jan 29, 2010 at 7:53 AM, Ivan Andrus  wrote:
> On Jan 29, 2010, at 7:37 AM, Robert Bradshaw wrote:
>
>> The issue is that the Sage window is mixed up with all the other browser 
>> windows, with irrelevant menu items, doesn't have its own icon in the dock, 
>> and the Sage session doesn't stop when the window is closed. Now there are 
>> several advantages to this from a remote users perspective, but in some ways 
>> it's not as "nice" as a native app (and how much you find that annoying is a 
>> matter of personal preference). Separate instances of Firefox can be started 
>> up with their own user profiles--perhaps the same can be done with Safari. 
>> (Well, it obviously can, see Fluid--thought that's not open source.)
>
> I have many of the same concerns, but as I mentioned in an email a few weeks 
> ago [1], Fluid is now open source (apache license) [2] and I have an example 
> of what a first stab at a Fluid-based Sage.app might look like at
> http://math.byu.edu/~gvol/files/fluidium-app.spkg


Can you describe how a mac user should try this out?
I guess, install using sage -i, but then what happens?

>
> -Ivan
>
> [1] 
> http://groups.google.com/group/sage-devel/browse_thread/thread/814114f9f246886a/940a5cc16ac217df>
> [2]
>
> --
> 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
>

-- 
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] #8044: Categories for finite/permutation/symmetric groups

[David Joyner]

On Fri, Jan 29, 2010 at 5:00 AM, Nicolas M. Thiery
 wrote:
> On Thu, Jan 28, 2010 at 12:32:48PM -0500, David Joyner wrote:
>> Just generally speaking, I appreciate very much any "cleaning up"
>> of this category of Sage objects. To me, it makes things more
>> natural and hopefully makes it easier to add functionality in an
>> organized way in the future.
>
> Mrr, it feels good to be petted a bit. As would say Lucky Luke to Joly
> Jumper: ``tu aimes ça, hein, vieux cabot'' :-)
>
> Ok, I'll review a patch as penitence for shamelessly calling for it:-)
>
> Seriously speaking: do you feel like reviewing my patch, once the
> votes/discussions will be other?


Yes, I'd be happy to.


>
> Cheers,
>                                Nicolas
> --
> Nicolas M. Thiéry "Isil" 
> http://Nicolas.Thiery.name/
>
> --
> 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
>

-- 
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] Sage patches added directly to symmetica source

[Dr. David Kirkby]

Minh Nguyen wrote:

Hi David,

On Sat, Jan 30, 2010 at 12:49 AM, Dr. David Kirkby
 wrote:

Minh's comment about cddlib-094f.p2.spkg reminded me that Symmetrica does
this too.


Could you please open a ticket for this?



Yes, no problem. It is here.

http://trac.sagemath.org/sage_trac/ticket/8122

Dave

--
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: cddlib-094f.p2.spkg copies binaries over to SAGE_LOCAL/bin and bad patching practice

[Dr. David Kirkby]

William Stein wrote:


I think the command "patch" should absolutely never, ever be used in
the installation script of an spkg.There are platforms that don't
have patch preinstalled, and it is not a prerequisite for installing
Sage (according to the README).  It is also simply not necessary as
you explained.

 --William


I'm not disagreeing with you that 'patch' should not be used. But it is a 
requirement for 2004 POSIX


http://www.opengroup.org/onlinepubs/009695399/utilities/patch.html

and 2008

http://www.opengroup.org/onlinepubs/9699919799/utilities/patch.html

so I would have thought any linux or Unix system would have had a 'patch' 
program.


Dave

--
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] Should sage-env exit if CFLAGS is set ?

[Dr. David Kirkby]

We know from recent discussions over sage-env and the hassles that

http://trac.sagemath.org/sage_trac/ticket/7818

caused, that setting CFLAGS, CXXFLAGS etc globally will cause a build failure in 
Sage. It would therefore seem sensible that we exit with an error message if 
someone sets CFLAGS when building Sage.


However, the downside of doing this is that if they later run Sage, with CFLAGS 
set, Sage will exit with an error message.



sage-env could easily be modified to check if CFLAGS is set, so catching cases 
where someone has set CFLAGS globally. Should this be done or not?



Dave

--
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] Sage Web Service / UI

[Ivan Andrus]

On Jan 29, 2010, at 7:27 PM, David Joyner wrote:
> On Fri, Jan 29, 2010 at 7:53 AM, Ivan Andrus  wrote:
>> On Jan 29, 2010, at 7:37 AM, Robert Bradshaw wrote:
>> 
>>> The issue is that the Sage window is mixed up with all the other browser 
>>> windows, with irrelevant menu items, doesn't have its own icon in the dock, 
>>> and the Sage session doesn't stop when the window is closed. Now there are 
>>> several advantages to this from a remote users perspective, but in some 
>>> ways it's not as "nice" as a native app (and how much you find that 
>>> annoying is a matter of personal preference). Separate instances of Firefox 
>>> can be started up with their own user profiles--perhaps the same can be 
>>> done with Safari. (Well, it obviously can, see Fluid--thought that's not 
>>> open source.)
>> 
>> I have many of the same concerns, but as I mentioned in an email a few weeks 
>> ago [1], Fluid is now open source (apache license) [2] and I have an example 
>> of what a first stab at a Fluid-based Sage.app might look like at
>> http://math.byu.edu/~gvol/files/fluidium-app.spkg
> 
> Can you describe how a mac user should try this out?
> I guess, install using sage -i, but then what happens?

Once it's done installing, it should open up the folder (namely $SAGE_ROOT) 
containing the application (called Sage.app).  You should then be able to move 
it, run it, etc.  When you first start it up, it will take a while before the 
server starts, but eventually it should open a browser window, and away you go.

-Ivan

-- 
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] Re: Should sage-env exit if CFLAGS is set ?

[Jaap Spies]

Dr. David Kirkby wrote:

We know from recent discussions over sage-env and the hassles that

http://trac.sagemath.org/sage_trac/ticket/7818

caused, that setting CFLAGS, CXXFLAGS etc globally will cause a build
failure in Sage. It would therefore seem sensible that we exit with an
error message if someone sets CFLAGS when building Sage.



I think it is more sensible that the spkgs involved do an 'unset CFLAGS', etc..
Laying the resposibilities were they belong.

A lot of spkgs will not built in 64 bit mode unless CFLAGS has a sensible flag.

Jaap


--
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] Re: problem with "text"

[John H Palmieri]

On Jan 29, 9:57 am, John H Palmieri  wrote:
> With Sage 4.3.2.alpha0, command line or notebook:
>
> sage: text(r"$\left(2 a=b\right)$", (2,3))   # works fine
> sage: text(r"$(2 \, a=b)$", (2,3))   # works fine
> sage: text(r"$\left(2 \, a=b\right)$", (2,3))   # error!
> Traceback (click to the left of this block for traceback)
> ...
> AttributeError: 'Kern' object has no attribute 'height'

I've created a ticket for this:



--
John

-- 
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] Remainder: please put the trac number is front of the log of your patches

[Florent Hivert]

  Dear All,

I lost quite a time tracking down patches because the following requirement of
the developer guide is not respected.

When you commit a patch :
"""
[...],
write a one line commit message of the form
   trac :  
where  is the Sage development tracking system ticket number (see
http://trac.sagemath.org).
"""

This is very useful to trac from "hg log" the sequence of ticket/patch which
were applied to a file. I really helps us (the combinat folks) getting the
compatibility patches which are necessary to allow our patch queue to work
with different release of sage.

Thanks,

Florent

-- 
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: Should sage-env exit if CFLAGS is set ?

[Dr. David Kirkby]

Jaap Spies wrote:

Dr. David Kirkby wrote:

We know from recent discussions over sage-env and the hassles that

http://trac.sagemath.org/sage_trac/ticket/7818

caused, that setting CFLAGS, CXXFLAGS etc globally will cause a build
failure in Sage. It would therefore seem sensible that we exit with an
error message if someone sets CFLAGS when building Sage.



I think it is more sensible that the spkgs involved do an 'unset 
CFLAGS', etc..

Laying the resposibilities were they belong.

A lot of spkgs will not built in 64 bit mode unless CFLAGS has a 
sensible flag.


Jaap


I would normally agree with you, but think this could be risky.

Having had my fingers burnt once over setting CFLAGS globally, I would avoid 
that at all costs. Which is why I wondered whether we should check they are not 
set, to avoid any surprises later on.


As I proposed the other day, which William liked, we set

SAGE_COMMON_CFLAGS

to a sensible set of compiler flags, suitable for most packages. spkg-install 
then use


CFLAGS="SAGE_COMMON_CFLAGS"
export CFLAGS

That way, CFLAGS is not set globally, but any package can get a sensible set if 
they choose to.


This may not be the most convenient approach, but it is the most risk-free.


Dave

--
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] Re: Should sage-env exit if CFLAGS is set ?

[Jaap Spies]

Dr. David Kirkby wrote:

Jaap Spies wrote:

Dr. David Kirkby wrote:

We know from recent discussions over sage-env and the hassles that

http://trac.sagemath.org/sage_trac/ticket/7818

caused, that setting CFLAGS, CXXFLAGS etc globally will cause a build
failure in Sage. It would therefore seem sensible that we exit with an
error message if someone sets CFLAGS when building Sage.



I think it is more sensible that the spkgs involved do an 'unset
CFLAGS', etc..
Laying the resposibilities were they belong.

A lot of spkgs will not built in 64 bit mode unless CFLAGS has a
sensible flag.

Jaap


I would normally agree with you, but think this could be risky.



Risky? What is wrong with cython unset CFLAGS?

I plea to put responsibilities where they belon.



Having had my fingers burnt once over setting CFLAGS globally, I would
avoid that at all costs. Which is why I wondered whether we should check
they are not set, to avoid any surprises later on.



Quite a few spkg-install are a simply: python setup.py install.
They fail on Open Solaris x64 if CFLAGS does not include -m64.



As I proposed the other day, which William liked, we set

SAGE_COMMON_CFLAGS

to a sensible set of compiler flags, suitable for most packages.
spkg-install then use

CFLAGS="SAGE_COMMON_CFLAGS"
export CFLAGS

That way, CFLAGS is not set globally, but any package can get a sensible
set if they choose to.

This may not be the most convenient approach, but it is the most risk-free.



Future music!

Jaap




Dave




--
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: Upgrading networkx - unpickling issue

[Nicolas M. Thiery]

On Fri, Jan 29, 2010 at 09:31:10AM -0800, Greg McWhirter wrote:
> Thanks for the rely. I tried that with boh Graph and Poset (since
> graph failed as well) under networkx-0.36 and networkx-1.0.1 both un
> un-patched 4.3.1 and patched to account for 1.0.1.
> However, everything went through without a hitch.
> 
> Un tar-ing the pickle_jar and load
> ("_class__sage_graphs_graph_Graph__.sobj") or load
> ("_class__sage_combinat_posets_posets_FinitePoset__.sobj") gives the
> error of "ImportError: No module named xgraph" or "ImportError: No
> module named xdigraph" respectively (these modules held the classes
> removed between 0.36 and 1.0.1). I don't know where these are getting
> called if the lines output by explain(dumps(P)) all work?

Hmm. Then the best is to call explain_pickle directly on those files,
rather than guessing which object causes trouble. What you can try is
to extract the pickle jar in /tmp:

tar jxvf /opt/sage-4.3.1/data/extcode/pickle_jar/pickle_jar.tar.bz2

and run:

sage: 
explain_pickle(file="/tmp/pickle_jar/_class__sage_graphs_graph_DiGraph__.sobj")
pg_DiGraph = unpickle_global('sage.graphs.graph', 'DiGraph')
si1 = unpickle_newobj(pg_DiGraph, ())
pg_NetworkXGraphBackend = 
unpickle_global('sage.graphs.base.graph_backends', 'NetworkXGraphBackend')
si2 = unpickle_newobj(pg_NetworkXGraphBackend, ())
pg_XDiGraph = unpickle_global('networkx.xdigraph', 'XDiGraph')
si3 = unpickle_newobj(pg_XDiGraph, ())
si4 = {}
unpickle_build(si3, {'name':'', 'pred':{}, 'selfloops':False, 'succ':si4, 
'adj':si4, 'multiedges':False})
unpickle_build(si2, {'_nxg':si3})
unpickle_build(si1, {'_weighted':False, '_boundary':[], '_backend':si2, 
'_pos':None})
si1

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

-- 
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] #8044: Categories for finite/permutation/symmetric groups

[Nicolas M. Thiery]

On Fri, Jan 29, 2010 at 01:38:54PM -0500, David Joyner wrote:
> > Seriously speaking: do you feel like reviewing my patch, once the
> > votes/discussions will be other?
>
> Yes, I'd be happy to.

Thanks! Let's wait one more day for possible feedback, and then it's
good to go. I let you see with Javier if/how you want to share the review.

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

-- 
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] Re: about complex and graphics

[Vincent D]

I created tiny patches for both trac 4838 and 8082. They now waits for
review.

I need more time to look at matplotlib and polar coordinates. Thanks
for pointing the different interrelated tickets.

Vincent

-- 
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] MPIR 1.3.0 released (at last)

[François Bissey]

On Fri, 29 Jan 2010 07:02:15 Bill Hart wrote:
> Hi all,
> 
> it is with pleasure that we (finally) officially release MPIR 1.3.0.
> It is available at our website http://www.mpir.org/
> 
Well I am making a Gentoo ebuild, it is already in the sage-on-gentoo 
overlay and will be in the science overlay soon.
But it does come with some QA problems which apparently were already there
in gmp:

 * QA Notice: The following files contain writable and executable sections
 *  Files with such sections will not work properly (or at all!) on some
 *  architectures/operating systems.  A bug should be filed at
 *  http://bugs.gentoo.org/ to make sure the issue is fixed.
 *  For more information, see http://hardened.gentoo.org/gnu-stack.xml
 *  Please include the following list of files in your report:
 *  Note: Bugs should be filed for the respective maintainers
 *  of the package in question and not harde...@g.o.
 * RWX --- --- usr/lib/libmpir.so.8.0.0
 * !WX --- --- usr/lib/libmpir.a:add_n.o
 * !WX --- --- usr/lib/libmpir.a:sub_n.o
 * !WX --- --- usr/lib/libmpir.a:mul_1.o
 * !WX --- --- usr/lib/libmpir.a:addmul_1.o
 * !WX --- --- usr/lib/libmpir.a:submul_1.o
 * !WX --- --- usr/lib/libmpir.a:lshift.o
 * !WX --- --- usr/lib/libmpir.a:rshift.o
 * !WX --- --- usr/lib/libmpir.a:dive_1.o
 * !WX --- --- usr/lib/libmpir.a:diveby3.o
 * !WX --- --- usr/lib/libmpir.a:divrem_1.o
 * !WX --- --- usr/lib/libmpir.a:mod_1.o
 * !WX --- --- usr/lib/libmpir.a:mod_34lsub1.o
 * !WX --- --- usr/lib/libmpir.a:mode1o.o
 * !WX --- --- usr/lib/libmpir.a:mul_basecase.o
 * !WX --- --- usr/lib/libmpir.a:sqr_basecase.o
 * !WX --- --- usr/lib/libmpir.a:umul.o
 * !WX --- --- usr/lib/libmpir.a:udiv.o
 * !WX --- --- usr/lib/libmpir.a:copyi.o
 * !WX --- --- usr/lib/libmpir.a:copyd.o
---
the link provided is instructive but I renounced fixing this for now due to the 
amount of source files that needs to be dealt with.
The fix for gmp doesn't apply because of the use of yasm on x86/amd64(x86_64).
I also don't quite work out yet how a proper assembler is selected in the 
config script.

Francois

-- 
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: Should sage-env exit if CFLAGS is set ?

[Robert Bradshaw]

On Jan 29, 2010, at 1:52 PM, Jaap Spies wrote:


Dr. David Kirkby wrote:

Jaap Spies wrote:

Dr. David Kirkby wrote:

We know from recent discussions over sage-env and the hassles that

http://trac.sagemath.org/sage_trac/ticket/7818

caused, that setting CFLAGS, CXXFLAGS etc globally will cause a  
build
failure in Sage. It would therefore seem sensible that we exit  
with an

error message if someone sets CFLAGS when building Sage.



I think it is more sensible that the spkgs involved do an 'unset
CFLAGS', etc..
Laying the resposibilities were they belong.

A lot of spkgs will not built in 64 bit mode unless CFLAGS has a
sensible flag.

Jaap


I would normally agree with you, but think this could be risky.



Risky? What is wrong with cython unset CFLAGS?

I plea to put responsibilities where they belon.


Having had my fingers burnt once over setting CFLAGS globally, I  
would
avoid that at all costs. Which is why I wondered whether we should  
check

they are not set, to avoid any surprises later on.



Quite a few spkg-install are a simply: python setup.py install.
They fail on Open Solaris x64 if CFLAGS does not include -m64.


There's nothing special about Cython, it basically is just another  
"python setup.py install" package. Are you saying we should unset  
CFLAGS for all of those? I seems extensions should be compiled with - 
m64 iff Python is compiled with -m64 (is it?).


Can you try running

>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('CFLAGS')

in your build of Python?

- Robert


--
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] Re: Should sage-env exit if CFLAGS is set ?

[Jaap Spies]

Robert Bradshaw wrote:

On Jan 29, 2010, at 1:52 PM, Jaap Spies wrote:


Dr. David Kirkby wrote:

Jaap Spies wrote:

Dr. David Kirkby wrote:

We know from recent discussions over sage-env and the hassles that

http://trac.sagemath.org/sage_trac/ticket/7818

caused, that setting CFLAGS, CXXFLAGS etc globally will cause a build
failure in Sage. It would therefore seem sensible that we exit with an
error message if someone sets CFLAGS when building Sage.



I think it is more sensible that the spkgs involved do an 'unset
CFLAGS', etc..
Laying the resposibilities were they belong.

A lot of spkgs will not built in 64 bit mode unless CFLAGS has a
sensible flag.

Jaap


I would normally agree with you, but think this could be risky.



Risky? What is wrong with cython unset CFLAGS?

I plea to put responsibilities where they belon.



Having had my fingers burnt once over setting CFLAGS globally, I would
avoid that at all costs. Which is why I wondered whether we should check
they are not set, to avoid any surprises later on.



Quite a few spkg-install are a simply: python setup.py install.
They fail on Open Solaris x64 if CFLAGS does not include -m64.


There's nothing special about Cython, it basically is just another
"python setup.py install" package. Are you saying we should unset CFLAGS
for all of those? I seems extensions should be compiled with -m64 iff
Python is compiled with -m64 (is it?).

Can you try running

 >>> import distutils.sysconfig
 >>> distutils.sysconfig.get_config_var('CFLAGS')

in your build of Python?



j...@opensolaris:~/Downloads/sage-4.3.2.alpha0$ ./sage -python
Python 2.6.4 (r264:75706, Jan 27 2010, 22:37:41)
[GCC 4.4.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('CFLAGS')
'-fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes'
>>>

As you see no -m64 as would be appropriate.

Jaap



- Robert





--
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] Re: Rational polynomials via FLINT (#4000)

[Bill Hart]

Thanks Willem. That's just a really silly bug on my part. I presume I
have been very naughty and not written test code for
fmpz_poly_pseudo_divrem. I mean, what can possibly go wrong with a cut
and paste. :-)

By the way, fmpz_poly_pseudo_rem should be faster if you don't require
the quotient.

Bill.

On Jan 29, 2:22 pm, Willem Jan Palenstijn  wrote:
> On Fri, Jan 29, 2010 at 05:58:39AM -0800, Sebastian Pancratz wrote:
> > The value of m is set by the call "fmpz_poly_pseudo_divrem(quo, r.num,
> > &m, a.num, b.num)", where as the output above shows we have a.num and
> > b.num both equal the polynomial 9*t-2.  From the FLINT (1.5.0) manual,
> > this call should set quo=Q, r.num=R and m such that
>
> >     lead(B)^m*A = B*Q + R
>
> > and the degree of R is less than the degree of B, where a.num=A,
> > b.num=B and lead(B) is the leading coefficient of B.  Here we have A =
> > B = 9*t-2 and lead(B) = 9.  The output above shows that Q and R are
> > computed correctly as 1 and 0, but I would expect that m should be set
> > to 0 rather than 120658626.
>
> fmpz_poly_pseudo_divrem has a bug in the special case for A == B, where it 
> sets
> d instead of *d to 0.
>
> -Willem Jan

-- 
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: Should sage-env exit if CFLAGS is set ?

[Robert Bradshaw]

On Jan 29, 2010, at 2:59 PM, Jaap Spies wrote:


Robert Bradshaw wrote:

On Jan 29, 2010, at 1:52 PM, Jaap Spies wrote:


Quite a few spkg-install are a simply: python setup.py install.
They fail on Open Solaris x64 if CFLAGS does not include -m64.


There's nothing special about Cython, it basically is just another
"python setup.py install" package. Are you saying we should unset  
CFLAGS

for all of those? I seems extensions should be compiled with -m64 iff
Python is compiled with -m64 (is it?).

Can you try running

>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('CFLAGS')

in your build of Python?



j...@opensolaris:~/Downloads/sage-4.3.2.alpha0$ ./sage -python
Python 2.6.4 (r264:75706, Jan 27 2010, 22:37:41)
[GCC 4.4.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('CFLAGS')
'-fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes'
>>>

As you see no -m64 as would be appropriate.


Hmm did Python not need an -m64 to build in 64-bit mode then?

- Robert


--
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] Problem with libpng 12.0.dylib when running Sphinx on Mac OS 10.6

[ablondin]

Hello, everyone !
I guess it's not the right place to post this problem but I haven't
found the answer anywhere else...
I have a MacBook Pro with Snow Leopard installed and I'm trying to
generate the doc with the command
sage -docbuild reference html

The problem is that I get the following messages (repeated about a
thousand of times) :

WARNING: display latex u'{\\rm SL}_2(\\ZZ)': latex exited with error:
[stderr]
dyld: Library not loaded: /opt/local/lib/libpng12.0.dylib
  Referenced from: /opt/local/bin/latex
  Reason: Incompatible library version: latex requires version 39.0.0
or later, but libpng12.0.dylib provides version 36.0.0

I've installed the latest version of libpng.
When I look with port, I get the following output

The following ports are currently installed:
  libpng @1.2.38_0
  libpng @1.2.40_0
  libpng @1.2.42_0 (active)
[~/Applications/sage/devel/sage-combinat]$

What's the problem ? Has anyone encountered it yet ? And what should I
do or where should I look at ? Thanks !
Alexandre Blondin Massé

-- 
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] Re: MPIR 1.3.0 released (at last)

[Bill Hart]

All of those object files seem to come from assembly code assembled by
yasm. I actually don't understand the bug report though. So I am not
sure what needs fixing. I don't know of any systems that these files
don't work on. Besides that, the only architectures they get used on
are x86_64!

Is the problem that the sections are writable? What sort of section
should be used? Perhaps yasm has an option to output sections of that
kind.

Regarding your question about how an assembler is chosen, yasm is only
used on x86/x86_64. The file /mpn/Makeasm.am defines the build rules
which distinguish files to be built with yasm and those to be built
with gas or gcc.

Bill.

On Jan 29, 10:48 pm, François Bissey  wrote:
> On Fri, 29 Jan 2010 07:02:15 Bill Hart wrote:> Hi all,
>
> > it is with pleasure that we (finally) officially release MPIR 1.3.0.
> > It is available at our websitehttp://www.mpir.org/
>
> Well I am making a Gentoo ebuild, it is already in the sage-on-gentoo
> overlay and will be in the science overlay soon.
> But it does come with some QA problems which apparently were already there
> in gmp:
>
>  * QA Notice: The following files contain writable and executable sections
>  *  Files with such sections will not work properly (or at all!) on some
>  *  architectures/operating systems.  A bug should be filed at
>  *  http://bugs.gentoo.org/to make sure the issue is fixed.
>  *  For more information, seehttp://hardened.gentoo.org/gnu-stack.xml
>  *  Please include the following list of files in your report:
>  *  Note: Bugs should be filed for the respective maintainers
>  *  of the package in question and not harde...@g.o.
>  * RWX --- --- usr/lib/libmpir.so.8.0.0
>  * !WX --- --- usr/lib/libmpir.a:add_n.o
>  * !WX --- --- usr/lib/libmpir.a:sub_n.o
>  * !WX --- --- usr/lib/libmpir.a:mul_1.o
>  * !WX --- --- usr/lib/libmpir.a:addmul_1.o
>  * !WX --- --- usr/lib/libmpir.a:submul_1.o
>  * !WX --- --- usr/lib/libmpir.a:lshift.o
>  * !WX --- --- usr/lib/libmpir.a:rshift.o
>  * !WX --- --- usr/lib/libmpir.a:dive_1.o
>  * !WX --- --- usr/lib/libmpir.a:diveby3.o
>  * !WX --- --- usr/lib/libmpir.a:divrem_1.o
>  * !WX --- --- usr/lib/libmpir.a:mod_1.o
>  * !WX --- --- usr/lib/libmpir.a:mod_34lsub1.o
>  * !WX --- --- usr/lib/libmpir.a:mode1o.o
>  * !WX --- --- usr/lib/libmpir.a:mul_basecase.o
>  * !WX --- --- usr/lib/libmpir.a:sqr_basecase.o
>  * !WX --- --- usr/lib/libmpir.a:umul.o
>  * !WX --- --- usr/lib/libmpir.a:udiv.o
>  * !WX --- --- usr/lib/libmpir.a:copyi.o
>  * !WX --- --- usr/lib/libmpir.a:copyd.o
> ---
> the link provided is instructive but I renounced fixing this for now due to 
> the
> amount of source files that needs to be dealt with.
> The fix for gmp doesn't apply because of the use of yasm on x86/amd64(x86_64).
> I also don't quite work out yet how a proper assembler is selected in the
> config script.
>
> Francois

-- 
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: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)

[Bill Hart]

It does work if you also add $LD_LIBRARY_PATH to LD_LIBRARY_PATH_64. I
have tested this, i.e. MPIR now builds and all tests now pass on t2,
so at least there is no problem for Sage.

We do not use the latest libtool. I tried upgrading it once before,
and not only could I not understand the documentation, but in the end,
I completely, abjectly failed. When I first started working on MPIR I
spent almost 3 months full time working on the build system of MPIR.

Bill.

On Jan 29, 3:37 pm, "Dr. David Kirkby" 
wrote:
> Bill Hart wrote:
> > Ah, got it. LD_LIBRARY_PATH_64 needs to also contain
> > /home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not
> > specified at all, i.e. left blank, the linker uses whatever is in
> > LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively,
> > which means that *all* 64 bit library paths must be in
> > LD_LIBRARY_PATH_64.
>
> > So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to
> > be set globally for users *and* we'd need libtool to recognise that it
> > needs to set LD_LIBRARY_PATH_64.
>
> > Unfortunately libtool doesn't do this automatically. So this is seems
> > to be a bug in the version of libtool we use. Another solution is to
> > set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually
> > works because the substitution is done live by the shell. In other
> > words, if LD_LIBRARY_PATH_64 is set to
> > /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all
> > users of t2 globally, I believe MPIR will work just fine on that
> > machine.
>
> > Bill.
>
> I do not believe it is correct to add the sparcv9 directory to 
> LD_LIBRARY_PATH,
> though I accept it might solve the issue. If anything, that would be added to
> LD_LIBRARY_PATH_64, but that is not working here.
>
> I would speak to the libtool developers - I know Ralf is very helpful, and has
> an account on 't2'. Perhaps he can solve this.
>
> Are you using the latest libtool ? If not, an upgrade might work.
>
> Dave

-- 
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] Re: Should sage-env exit if CFLAGS is set ?

[Jaap Spies]

Robert Bradshaw wrote:

On Jan 29, 2010, at 2:59 PM, Jaap Spies wrote:


Robert Bradshaw wrote:

On Jan 29, 2010, at 1:52 PM, Jaap Spies wrote:


Quite a few spkg-install are a simply: python setup.py install.
They fail on Open Solaris x64 if CFLAGS does not include -m64.


There's nothing special about Cython, it basically is just another
"python setup.py install" package. Are you saying we should unset CFLAGS
for all of those? I seems extensions should be compiled with -m64 iff
Python is compiled with -m64 (is it?).

Can you try running

>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('CFLAGS')

in your build of Python?



j...@opensolaris:~/Downloads/sage-4.3.2.alpha0$ ./sage -python
Python 2.6.4 (r264:75706, Jan 27 2010, 22:37:41)
[GCC 4.4.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('CFLAGS')
'-fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes'
>>>

As you see no -m64 as would be appropriate.


Hmm did Python not need an -m64 to build in 64-bit mode then?



Yes it needed -m64. As p5 get screwed up by William I put -m64 in at
a place I think was appropriate.

Maybe we have to sort out the p5 question first. David Kirkby had a patch,
which was overwritten by a following patch p5.

I made python build with 64 bit support on my Open Solaris.

Jaap



- Robert





--
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] Remainder: please put the trac number is front of the log of your patches

[Robert Miller]

How difficult would it be to automate this using the trac server
itself? I.e. any patch that gets uploaded checks for the ticket number
on the commit line, and if it's not there (or there is no commit
message), it would prepend "trac : ".

On Fri, Jan 29, 2010 at 1:24 PM, Florent Hivert
 wrote:
> When you commit a patch :
> """
> [...],
> write a one line commit message of the form
>   trac :  
> where  is the Sage development tracking system ticket number (see
> http://trac.sagemath.org).
> """



-- 
Robert L. Miller
http://www.rlmiller.org/

-- 
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] MPIR 1.3.0 released (at last)

[Bill Hart]

By the way, Solaris also has LD_LIBRARY_PATH_32. You can put 32 bit
libraries in that and leave the generic LD_LIBRARY_PATH for libtool to
play with. But you should put $LD_LIBRARY_PATH in $LD_LIBRARY_PATH_64
and probably in $LD_LIBRARY_PATH_32 as well, otherwise it won't work.

Bill.

On Jan 29, 11:28 pm, Bill Hart  wrote:
> It does work if you also add $LD_LIBRARY_PATH to LD_LIBRARY_PATH_64. I
> have tested this, i.e. MPIR now builds and all tests now pass on t2,
> so at least there is no problem for Sage.
>
> We do not use the latest libtool. I tried upgrading it once before,
> and not only could I not understand the documentation, but in the end,
> I completely, abjectly failed. When I first started working on MPIR I
> spent almost 3 months full time working on the build system of MPIR.
>
> Bill.
>
> On Jan 29, 3:37 pm, "Dr. David Kirkby" 
> wrote:
>
>
>
> > Bill Hart wrote:
> > > Ah, got it. LD_LIBRARY_PATH_64 needs to also contain
> > > /home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not
> > > specified at all, i.e. left blank, the linker uses whatever is in
> > > LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively,
> > > which means that *all* 64 bit library paths must be in
> > > LD_LIBRARY_PATH_64.
>
> > > So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to
> > > be set globally for users *and* we'd need libtool to recognise that it
> > > needs to set LD_LIBRARY_PATH_64.
>
> > > Unfortunately libtool doesn't do this automatically. So this is seems
> > > to be a bug in the version of libtool we use. Another solution is to
> > > set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually
> > > works because the substitution is done live by the shell. In other
> > > words, if LD_LIBRARY_PATH_64 is set to
> > > /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all
> > > users of t2 globally, I believe MPIR will work just fine on that
> > > machine.
>
> > > Bill.
>
> > I do not believe it is correct to add the sparcv9 directory to 
> > LD_LIBRARY_PATH,
> > though I accept it might solve the issue. If anything, that would be added 
> > to
> > LD_LIBRARY_PATH_64, but that is not working here.
>
> > I would speak to the libtool developers - I know Ralf is very helpful, and 
> > has
> > an account on 't2'. Perhaps he can solve this.
>
> > Are you using the latest libtool ? If not, an upgrade might work.
>
> > Dave

-- 
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] Re: Trac #7761 - was not integrated, despite trac says it is.

[Jaap Spies]

Dr. David Kirkby wrote:

http://trac.sagemath.org/sage_trac/ticket/7761

"Python 2.6.2.p4 faills to build on OpenSolaris"

is a fix of mine for python. But despite being shown as merged in
sage-4.3.1.alpha2, it is not in sage 4.3.1

Dave




I hope someone will step forward to resolve this mess!

Jaap



--
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] Remainder: please put the trac number is front of the log of your patches

[Minh Nguyen]

Hi Robert,

On Sat, Jan 30, 2010 at 10:38 AM, Robert Miller  wrote:
> How difficult would it be to automate this using the trac server
> itself?

The same discussion also took place in sage-combinat-devel

http://groups.google.com/group/sage-combinat-devel/browse_thread/thread/e7fab4e454dc2486

Mike Hansen suggested enhancing the merge script.

-- 
Regards
Minh Van Nguyen

-- 
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] Re: MPIR 1.3.0 released (at last)

[Bill Hart]

Also, from the Sun documentation:

Linking
The linker remains a 32-bit application, but this should be
transparent to most users, since it is normally invoked indirectly by
the compiler driver, for example, cc(1). If the linker is presented
with a collection of ELF32 object files as input, it creates an ELF32
output file; similarly, if it is presented with a collection of ELF64
object files as input, it creates an ELF64 output file. Attempts to
mix ELF32 and ELF64 input files are rejected by the linker.

LD_LIBRARY_PATH
The two separate dynamic linker programs for 32-bit applications and
for 64-bit applications are: /usr/lib/ld.so.1 and /usr/lib/sparcv9/
ld.so.1.

At runtime, both dynamic linkers search the same list of colon-
separated directories specified by the LD_LIBRARY_PATH environment
variable. However, the 32-bit dynamic linker binds only to 32-bit
libraries, while the 64-bit dynamic linker binds only to 64-bit
libraries. So directories containing both 32-bit and 64-bit libraries
can be specified via LD_LIBRARY_PATH, if needed.

The 64-bit dynamic linker's search path can be completely overridden
using the LD_LIBRARY_PATH_64 environment variable.



On Jan 29, 11:39 pm, Bill Hart  wrote:
> By the way, Solaris also has LD_LIBRARY_PATH_32. You can put 32 bit
> libraries in that and leave the generic LD_LIBRARY_PATH for libtool to
> play with. But you should put $LD_LIBRARY_PATH in $LD_LIBRARY_PATH_64
> and probably in $LD_LIBRARY_PATH_32 as well, otherwise it won't work.
>
> Bill.
>
> On Jan 29, 11:28 pm, Bill Hart  wrote:
>
>
>
> > It does work if you also add $LD_LIBRARY_PATH to LD_LIBRARY_PATH_64. I
> > have tested this, i.e. MPIR now builds and all tests now pass on t2,
> > so at least there is no problem for Sage.
>
> > We do not use the latest libtool. I tried upgrading it once before,
> > and not only could I not understand the documentation, but in the end,
> > I completely, abjectly failed. When I first started working on MPIR I
> > spent almost 3 months full time working on the build system of MPIR.
>
> > Bill.
>
> > On Jan 29, 3:37 pm, "Dr. David Kirkby" 
> > wrote:
>
> > > Bill Hart wrote:
> > > > Ah, got it. LD_LIBRARY_PATH_64 needs to also contain
> > > > /home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not
> > > > specified at all, i.e. left blank, the linker uses whatever is in
> > > > LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively,
> > > > which means that *all* 64 bit library paths must be in
> > > > LD_LIBRARY_PATH_64.
>
> > > > So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to
> > > > be set globally for users *and* we'd need libtool to recognise that it
> > > > needs to set LD_LIBRARY_PATH_64.
>
> > > > Unfortunately libtool doesn't do this automatically. So this is seems
> > > > to be a bug in the version of libtool we use. Another solution is to
> > > > set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually
> > > > works because the substitution is done live by the shell. In other
> > > > words, if LD_LIBRARY_PATH_64 is set to
> > > > /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all
> > > > users of t2 globally, I believe MPIR will work just fine on that
> > > > machine.
>
> > > > Bill.
>
> > > I do not believe it is correct to add the sparcv9 directory to 
> > > LD_LIBRARY_PATH,
> > > though I accept it might solve the issue. If anything, that would be 
> > > added to
> > > LD_LIBRARY_PATH_64, but that is not working here.
>
> > > I would speak to the libtool developers - I know Ralf is very helpful, 
> > > and has
> > > an account on 't2'. Perhaps he can solve this.
>
> > > Are you using the latest libtool ? If not, an upgrade might work.
>
> > > Dave

-- 
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] Remainder: please put the trac number is front of the log of your patches

[Florent Hivert]

  Hi Robert, 

On Fri, Jan 29, 2010 at 03:38:12PM -0800, Robert Miller wrote:
> How difficult would it be to automate this using the trac server
> itself? I.e. any patch that gets uploaded checks for the ticket number
> on the commit line, and if it's not there (or there is no commit
> message), it would prepend "trac : ".

How did you guess that you was the culprit which made me trac down the
different patch which where applied to the graphs directory ;-) I indeed made
the same suggestion on sage-combinat-devel after losing 2 hours playing a
stupid game.

Cheers,

Florent

-- 
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] Re: Upgrading networkx - unpickling issue

[Greg McWhirter]

Ah, ok then, thanks. =) Found the issue and almost solved it. Added

from sage.structure.sage_object import register_unpickle_override
import networkx.classes
register_unpickle_override('networkx.xgraph','XGraph',
networkx.classes.Graph, call_name=('networkx.classes','Graph'))
register_unpickle_override('networkx.xdigraph','XDiGraph',
networkx.classes.DiGraph, call_name=('networkx.classes','DiGraph'))

to the graph_backends.py

This will pass the tests but it still isn't quite right. The issue is
in unpickling graphs with multiple edges. Due to the nature of the
networkx library changes, unpickling a graph with multiple edges
results in one without multiple edges which is broken when calling
edges() on it.

I was thinking of writing a translation class that would take whatever
input from either of the two deprecated classes. Then, to use it,
require the user to call a convert() method or something on it, which
would return the proper networkx class with appropriate data. This
seems less than ideal, however, and some sort of post-unpickle hook
would seem better, but poking around it doesn't seem that one exists.
I would love suggestions for other ways to solve this.

- Greg

On Jan 29, 1:59 pm, "Nicolas M. Thiery" 
wrote:
> On Fri, Jan 29, 2010 at 09:31:10AM -0800, Greg McWhirter wrote:
> > Thanks for the rely. I tried that with boh Graph and Poset (since
> > graph failed as well) under networkx-0.36 and networkx-1.0.1 both un
> > un-patched 4.3.1 and patched to account for 1.0.1.
> > However, everything went through without a hitch.
>
> > Un tar-ing the pickle_jar and load
> > ("_class__sage_graphs_graph_Graph__.sobj") or load
> > ("_class__sage_combinat_posets_posets_FinitePoset__.sobj") gives the
> > error of "ImportError: No module named xgraph" or "ImportError: No
> > module named xdigraph" respectively (these modules held the classes
> > removed between 0.36 and 1.0.1). I don't know where these are getting
> > called if the lines output by explain(dumps(P)) all work?
>
> Hmm. Then the best is to call explain_pickle directly on those files,
> rather than guessing which object causes trouble. What you can try is
> to extract the pickle jar in /tmp:
>
>     tar jxvf /opt/sage-4.3.1/data/extcode/pickle_jar/pickle_jar.tar.bz2
>
> and run:
>
>     sage: 
> explain_pickle(file="/tmp/pickle_jar/_class__sage_graphs_graph_DiGraph__.so 
> bj")
>     pg_DiGraph = unpickle_global('sage.graphs.graph', 'DiGraph')
>     si1 = unpickle_newobj(pg_DiGraph, ())
>     pg_NetworkXGraphBackend = 
> unpickle_global('sage.graphs.base.graph_backends', 'NetworkXGraphBackend')
>     si2 = unpickle_newobj(pg_NetworkXGraphBackend, ())
>     pg_XDiGraph = unpickle_global('networkx.xdigraph', 'XDiGraph')
>     si3 = unpickle_newobj(pg_XDiGraph, ())
>     si4 = {}
>     unpickle_build(si3, {'name':'', 'pred':{}, 'selfloops':False, 'succ':si4, 
> 'adj':si4, 'multiedges':False})
>     unpickle_build(si2, {'_nxg':si3})
>     unpickle_build(si1, {'_weighted':False, '_boundary':[], '_backend':si2, 
> '_pos':None})
>     si1
>
> Good luck!
>                                 Nicolas
> --
> Nicolas M. Thi ry "Isil" http://Nicolas.Thiery.name/

-- 
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: #8044: Categories for finite/permutation/symmetric groups

[Nicolas M. Thiery]

On Fri, Jan 29, 2010 at 12:44:06PM +0100, Nicolas M. Thiery wrote:
Dear David, Javier, Sébastien, Robert, ...

> On Jan 27, 10:28 pm, "Nicolas M. Thiery" 
> By the way, Sébastien, if you want to make a small patch on top of
> #8044 which would include the cl Cayley graph examples from
> cayley_graph-sl.patch, it would make sense to merge it in the same
> ticket, and I'll be happy to review it.

Sébastien: thanks for putting this on trac!

Pushed by an example of Sébastien, I just worked a bit further to make
matrix groups use categories. In particular:

sage: G = GL(2,GF(3))
sage: G.category()
Category of finite groups
sage: G.cayley_graph().show3d()

I'll upload this on trac sometime this week-end after checking that
all tests pass.

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

-- 
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] Re: MPIR 1.3.0 released (at last)

[Bill Hart]

I tried a later libtool (the one distributed with the Ubuntu on
boxen.math) and this made no difference.

I also looked through the recent changelog of the libtool project and
there is no mention of this issue being fixed. I also did an extensive
search online and pretty much everyone just recommends setting
LD_LIBRARY_PATH_64 or LD_LIBRARY_PATH in the manner that I indicated.

Bill.

On Jan 29, 11:44 pm, Bill Hart  wrote:
> Also, from the Sun documentation:
>
> Linking
> The linker remains a 32-bit application, but this should be
> transparent to most users, since it is normally invoked indirectly by
> the compiler driver, for example, cc(1). If the linker is presented
> with a collection of ELF32 object files as input, it creates an ELF32
> output file; similarly, if it is presented with a collection of ELF64
> object files as input, it creates an ELF64 output file. Attempts to
> mix ELF32 and ELF64 input files are rejected by the linker.
>
> LD_LIBRARY_PATH
> The two separate dynamic linker programs for 32-bit applications and
> for 64-bit applications are: /usr/lib/ld.so.1 and /usr/lib/sparcv9/
> ld.so.1.
>
> At runtime, both dynamic linkers search the same list of colon-
> separated directories specified by the LD_LIBRARY_PATH environment
> variable. However, the 32-bit dynamic linker binds only to 32-bit
> libraries, while the 64-bit dynamic linker binds only to 64-bit
> libraries. So directories containing both 32-bit and 64-bit libraries
> can be specified via LD_LIBRARY_PATH, if needed.
>
> The 64-bit dynamic linker's search path can be completely overridden
> using the LD_LIBRARY_PATH_64 environment variable.
>
> On Jan 29, 11:39 pm, Bill Hart  wrote:
>
>
>
> > By the way, Solaris also has LD_LIBRARY_PATH_32. You can put 32 bit
> > libraries in that and leave the generic LD_LIBRARY_PATH for libtool to
> > play with. But you should put $LD_LIBRARY_PATH in $LD_LIBRARY_PATH_64
> > and probably in $LD_LIBRARY_PATH_32 as well, otherwise it won't work.
>
> > Bill.
>
> > On Jan 29, 11:28 pm, Bill Hart  wrote:
>
> > > It does work if you also add $LD_LIBRARY_PATH to LD_LIBRARY_PATH_64. I
> > > have tested this, i.e. MPIR now builds and all tests now pass on t2,
> > > so at least there is no problem for Sage.
>
> > > We do not use the latest libtool. I tried upgrading it once before,
> > > and not only could I not understand the documentation, but in the end,
> > > I completely, abjectly failed. When I first started working on MPIR I
> > > spent almost 3 months full time working on the build system of MPIR.
>
> > > Bill.
>
> > > On Jan 29, 3:37 pm, "Dr. David Kirkby" 
> > > wrote:
>
> > > > Bill Hart wrote:
> > > > > Ah, got it. LD_LIBRARY_PATH_64 needs to also contain
> > > > > /home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not
> > > > > specified at all, i.e. left blank, the linker uses whatever is in
> > > > > LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively,
> > > > > which means that *all* 64 bit library paths must be in
> > > > > LD_LIBRARY_PATH_64.
>
> > > > > So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to
> > > > > be set globally for users *and* we'd need libtool to recognise that it
> > > > > needs to set LD_LIBRARY_PATH_64.
>
> > > > > Unfortunately libtool doesn't do this automatically. So this is seems
> > > > > to be a bug in the version of libtool we use. Another solution is to
> > > > > set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually
> > > > > works because the substitution is done live by the shell. In other
> > > > > words, if LD_LIBRARY_PATH_64 is set to
> > > > > /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all
> > > > > users of t2 globally, I believe MPIR will work just fine on that
> > > > > machine.
>
> > > > > Bill.
>
> > > > I do not believe it is correct to add the sparcv9 directory to 
> > > > LD_LIBRARY_PATH,
> > > > though I accept it might solve the issue. If anything, that would be 
> > > > added to
> > > > LD_LIBRARY_PATH_64, but that is not working here.
>
> > > > I would speak to the libtool developers - I know Ralf is very helpful, 
> > > > and has
> > > > an account on 't2'. Perhaps he can solve this.
>
> > > > Are you using the latest libtool ? If not, an upgrade might work.
>
> > > > Dave

-- 
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: MPIR 1.3.0 released (at last)

[François Bissey]

Hi Bill,

Let me try to clarify a bit.

On Sat, 30 Jan 2010 12:18:54 Bill Hart wrote:
> All of those object files seem to come from assembly code assembled by
> yasm. I actually don't understand the bug report though. So I am not
> sure what needs fixing. I don't know of any systems that these files
> don't work on. Besides that, the only architectures they get used on
> are x86_64!

Do you mean x86/x86_64, I got the report from an x86 only machine. 

> 
> Is the problem that the sections are writable? What sort of section
> should be used? Perhaps yasm has an option to output sections of that
> kind.
> 
> Regarding your question about how an assembler is chosen, yasm is only
> used on x86/x86_64. The file /mpn/Makeasm.am defines the build rules
> which distinguish files to be built with yasm and those to be built
> with gas or gcc.
> 
It is a bit more subtle than that, it should work most of the time. The main
case where things could go south is if you have a hardened system with
the NX bit turned on - my guess.
It is a QA issue meaning that actual side effects are hard to predict depending 
on what is actually done. The check just points out to "bad practise".

I guess I gave you too much info in one go. A lot of stuff is explained there
with what kind of steps that can be taken to get rid of them:
http://hardened.gentoo.org/gnu-stack.xml

You inherited that stuff from gmp, it is a known issue there as well. The 
problem is you have an enormous amount of assembler files so some systematic
approach is needed. By the way 

My comment about yasm is that the fix is also different if you use yasm compared
to other assembler. In Gentoo gmp has a quite ugly patch that get rid of
all the problem in one go - on linux only - but wouldn't work with yasm.

Francois

-- 
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] Sage Web Service / UI

[David Joyner]

sage -i /Users/wdj/sagefiles/fluidium-app.spkg

gave

(lots of lines deleted)

x fluidium-spkg/.hg/store/data/spkg-install.i
Finished extraction
sage: After decompressing the directory fluidium-app does not exist
This means that the corresponding .spkg needs to be downloaded
again.
http://www.sagemath.org//packages/optional/fluidium-app.spkg -->
fluidium-app.spkg
[ ]
http://www.sagemath.org//packages/standard/fluidium-app.spkg -->
fluidium-app.spkg
[ ]
http://www.sagemath.org//packages/experimental/fluidium-app.spkg -->
fluidium-app.spkg
[ ]
http://www.sagemath.org//packages/archive/fluidium-app.spkg -->
fluidium-app.spkg
[ ]
**
* Unable to download fluidium-app
* Please see http://www.sagemath.org//packages for a list of valid
* packages or check the package name.
**
/Users/wdj/sagefiles/sage-4.3.2.alpha0/spkg/build
bunzip2: Can't open input file fluidium-app.spkg: No such file or directory.
tar: Error opening archive: Failed to open 'fluidium-app.spkg': No
such file or directory
Second download resulted in a corrupted package.



On Fri, Jan 29, 2010 at 3:50 PM, Ivan Andrus  wrote:
> On Jan 29, 2010, at 7:27 PM, David Joyner wrote:
>> On Fri, Jan 29, 2010 at 7:53 AM, Ivan Andrus  wrote:
>>> On Jan 29, 2010, at 7:37 AM, Robert Bradshaw wrote:
>>>
 The issue is that the Sage window is mixed up with all the other browser 
 windows, with irrelevant menu items, doesn't have its own icon in the 
 dock, and the Sage session doesn't stop when the window is closed. Now 
 there are several advantages to this from a remote users perspective, but 
 in some ways it's not as "nice" as a native app (and how much you find 
 that annoying is a matter of personal preference). Separate instances of 
 Firefox can be started up with their own user profiles--perhaps the same 
 can be done with Safari. (Well, it obviously can, see Fluid--thought 
 that's not open source.)
>>>
>>> I have many of the same concerns, but as I mentioned in an email a few 
>>> weeks ago [1], Fluid is now open source (apache license) [2] and I have an 
>>> example of what a first stab at a Fluid-based Sage.app might look like at
>>> http://math.byu.edu/~gvol/files/fluidium-app.spkg
>>
>> Can you describe how a mac user should try this out?
>> I guess, install using sage -i, but then what happens?
>
> Once it's done installing, it should open up the folder (namely $SAGE_ROOT) 
> containing the application (called Sage.app).  You should then be able to 
> move it, run it, etc.  When you first start it up, it will take a while 
> before the server starts, but eventually it should open a browser window, and 
> away you go.
>
> -Ivan
>
> --
> 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
>

-- 
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] Re: Rational polynomials via FLINT (#4000)

[Sebastian Pancratz]

> By the way, fmpz_poly_pseudo_rem should be faster if you don't require
> the quotient.
>
> Bill.

I originally wrote the Cython code against FLINT 1.4.0 and at the time
there was a bug in fmpz_poly_pseudo_mod, as a result of which I was
just using fmpz_poly_pseudo_divrem.  I think Sage currently uses FLINT
1.5.0 (according to the spkg name), which I think has that bug fixed,
so you're right I should probably revert to using _divrem, _div, and
_rem again.

In any case, I've now uploaded a patch which works around the bug
mentioned in this thread.

Sebastian

-- 
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] Sage Web Service / UI

[William Stein]

On Fri, Jan 29, 2010 at 5:22 PM, David Joyner  wrote:
> sage -i /Users/wdj/sagefiles/fluidium-app.spkg
>
> gave
>
> (lots of lines deleted)
>
> x fluidium-spkg/.hg/store/data/spkg-install.i

The person making the spkg made it incorrectly.
Put the relevant sources in a directory of the form

  package_name-version_number

then type

sage -pkg package_name-version_number

William

> Finished extraction
> sage: After decompressing the directory fluidium-app does not exist
> This means that the corresponding .spkg needs to be downloaded
> again.
> http://www.sagemath.org//packages/optional/fluidium-app.spkg -->
> fluidium-app.spkg
> [ ]
> http://www.sagemath.org//packages/standard/fluidium-app.spkg -->
> fluidium-app.spkg
> [ ]
> http://www.sagemath.org//packages/experimental/fluidium-app.spkg -->
> fluidium-app.spkg
> [ ]
> http://www.sagemath.org//packages/archive/fluidium-app.spkg -->
> fluidium-app.spkg
> [ ]
> **
> * Unable to download fluidium-app
> * Please see http://www.sagemath.org//packages for a list of valid
> * packages or check the package name.
> **
> /Users/wdj/sagefiles/sage-4.3.2.alpha0/spkg/build
> bunzip2: Can't open input file fluidium-app.spkg: No such file or directory.
> tar: Error opening archive: Failed to open 'fluidium-app.spkg': No
> such file or directory
> Second download resulted in a corrupted package.
>
>
>
> On Fri, Jan 29, 2010 at 3:50 PM, Ivan Andrus  wrote:
>> On Jan 29, 2010, at 7:27 PM, David Joyner wrote:
>>> On Fri, Jan 29, 2010 at 7:53 AM, Ivan Andrus  wrote:
 On Jan 29, 2010, at 7:37 AM, Robert Bradshaw wrote:

> The issue is that the Sage window is mixed up with all the other browser 
> windows, with irrelevant menu items, doesn't have its own icon in the 
> dock, and the Sage session doesn't stop when the window is closed. Now 
> there are several advantages to this from a remote users perspective, but 
> in some ways it's not as "nice" as a native app (and how much you find 
> that annoying is a matter of personal preference). Separate instances of 
> Firefox can be started up with their own user profiles--perhaps the same 
> can be done with Safari. (Well, it obviously can, see Fluid--thought 
> that's not open source.)

 I have many of the same concerns, but as I mentioned in an email a few 
 weeks ago [1], Fluid is now open source (apache license) [2] and I have an 
 example of what a first stab at a Fluid-based Sage.app might look like at
 http://math.byu.edu/~gvol/files/fluidium-app.spkg
>>>
>>> Can you describe how a mac user should try this out?
>>> I guess, install using sage -i, but then what happens?
>>
>> Once it's done installing, it should open up the folder (namely $SAGE_ROOT) 
>> containing the application (called Sage.app).  You should then be able to 
>> move it, run it, etc.  When you first start it up, it will take a while 
>> before the server starts, but eventually it should open a browser window, 
>> and away you go.
>>
>> -Ivan
>>
>> --
>> 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
>>
>
> --
> 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
>



-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

-- 
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] Re: problem with "text"

[John H Palmieri]

On Jan 29, 1:10 pm, John H Palmieri  wrote:
> On Jan 29, 9:57 am, John H Palmieri  wrote:
>
> > With Sage 4.3.2.alpha0, command line or notebook:
>
> > sage: text(r"$\left(2 a=b\right)$", (2,3))   # works fine
> > sage: text(r"$(2 \, a=b)$", (2,3))   # works fine
> > sage: text(r"$\left(2 \, a=b\right)$", (2,3))   # error!
> > Traceback (click to the left of this block for traceback)
> > ...
> > AttributeError: 'Kern' object has no attribute 'height'
>
> I've created a ticket for this:
>
> 

As far as I can tell, this is a bug in matplotlib.  I've reported it
to the matplotlib people, and we'll see if they can fix it.

--
John

-- 
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] Re: Unknown control sequence '\texttt'

[John H Palmieri]

On Jan 29, 2:09 am, lutusp  wrote:
> > Give some examples, please.
>
> var("y R")
>
> a(y,R) = pi * (2*R - y) * y
>
> lbl = text("$\int \  " + latex(a(y,R)) + "$",(3,20))
>
> view(lbl)
>  ... Graphics object consisting of 1 graphics primitive (not
> displayed)
> show(lbl)
>  ...  Unknown control sequence '\texttt'
>
> No graphics shown.

This is a bug with matplotlib.  For Sage, it's being tracked on this
ticket:



Meanwhile, you could try:

sage: s = latex(a(y,R)).replace('\\,', '')   # remove \,
sage: lbl = text(r"$\int \ " + s + "$", (3, 20))
sage: show(lbl)

--
John

-- 
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] Re: MPIR 1.3.0 released (at last)

[Bill Hart]

On Jan 30, 1:03 am, François Bissey  wrote:
> Hi Bill,
>
> Let me try to clarify a bit.
>
> On Sat, 30 Jan 2010 12:18:54 Bill Hart wrote:
>
> > All of those object files seem to come from assembly code assembled by
> > yasm. I actually don't understand the bug report though. So I am not
> > sure what needs fixing. I don't know of any systems that these files
> > don't work on. Besides that, the only architectures they get used on
> > are x86_64!
>
> Do you mean x86/x86_64, I got the report from an x86 only machine.

Yes, sorry, that was a typo on my part.

>
>
>
> > Is the problem that the sections are writable? What sort of section
> > should be used? Perhaps yasm has an option to output sections of that
> > kind.
>
> > Regarding your question about how an assembler is chosen, yasm is only
> > used on x86/x86_64. The file /mpn/Makeasm.am defines the build rules
> > which distinguish files to be built with yasm and those to be built
> > with gas or gcc.
>
> It is a bit more subtle than that, it should work most of the time. The main
> case where things could go south is if you have a hardened system with
> the NX bit turned on - my guess.
> It is a QA issue meaning that actual side effects are hard to predict 
> depending
> on what is actually done. The check just points out to "bad practise".

I see. Well I added the recommended defines to one of the yasm
assembler files and that didn't cause it to bomb out, so assuming this
has no performance side effects, I guess it would be possible to write
a script to update all the assembler files in MPIR (there's hundreds
of them, so you don't want to do it by hand).

>
> I guess I gave you too much info in one go. A lot of stuff is explained there
> with what kind of steps that can be taken to get rid of 
> them:http://hardened.gentoo.org/gnu-stack.xml
>
> You inherited that stuff from gmp, it is a known issue there as well. The
> problem is you have an enormous amount of assembler files so some systematic
> approach is needed. By the way
>
> My comment about yasm is that the fix is also different if you use yasm 
> compared
> to other assembler. In Gentoo gmp has a quite ugly patch that get rid of
> all the problem in one go - on linux only - but wouldn't work with yasm.
>

I can imagine something like that for the gas files. There aren't so
many yasm files in total, perhaps 50 or so.

We could give you svn access if you wanted to work on doing this in
MPIR. We would only accept the patch if there were no performance
degradations however.

It's very odd to me that assembly code needs to be rewritten to
support this hardware feature. It's certainly something I've never
heard about before.

Bill.

-- 
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] Question about set() in Python on different platforms

[kcrisman]

On #7325, we are getting hardware or software-dependent results, which
are easy to deal with as the results are equivalent, but which raises
the question of how to correctly use of Python's set().

On sage.math:
sage: set((x,y))
set([y, x])

On my Macintel 10.5:
sage: set((x,y))
set([x, y])

Then when one makes an iterator, it becomes dependent on this.  set()
is a pure Python thing, I believe.  Can anyone shed light on this - to
be precise, how to avoid this dependence in making an iterator without
(say) sorting?  Has this ever caused problems in Sage before?

Thanks for any insight on this Python question!

- kcrisman

-- 
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: MPIR 1.3.0 released (at last)

[François Bissey]

On Sat, 30 Jan 2010 15:26:51 Bill Hart wrote:
> > It is a bit more subtle than that, it should work most of the time. The
> > main case where things could go south is if you have a hardened system
> > with the NX bit turned on - my guess.
> > It is a QA issue meaning that actual side effects are hard to predict
> > depending on what is actually done. The check just points out to "bad
> > practise".
> 
> I see. Well I added the recommended defines to one of the yasm
> assembler files and that didn't cause it to bomb out, so assuming this
> has no performance side effects, I guess it would be possible to write
> a script to update all the assembler files in MPIR (there's hundreds
> of them, so you don't want to do it by hand).
> 

I have no idea if there is an impact on performance I must say. 
I don't think it would but I am not a specialist in assembly.

> > I guess I gave you too much info in one go. A lot of stuff is explained
> > there with what kind of steps that can be taken to get rid of
> > them:http://hardened.gentoo.org/gnu-stack.xml
> >
> > You inherited that stuff from gmp, it is a known issue there as well. The
> > problem is you have an enormous amount of assembler files so some
> > systematic approach is needed. By the way
> >
> > My comment about yasm is that the fix is also different if you use yasm
> > compared to other assembler. In Gentoo gmp has a quite ugly patch that
> > get rid of all the problem in one go - on linux only - but wouldn't work
> > with yasm.
> 
> I can imagine something like that for the gas files. There aren't so
> many yasm files in total, perhaps 50 or so.
> 
> We could give you svn access if you wanted to work on doing this in
> MPIR. We would only accept the patch if there were no performance
> degradations however.
> 

I will think about your offer when I figure a script/strategy to do it (or find 
the time). Actually I posted this in the bug for mpir in gentoo bugzilla
( http://bugs.gentoo.org/show_bug.cgi?id=293383 ), may be someone will
have an idea over there. 

For your info mpir 1.2.2 and 1.3.0 are available for Gentoo in the "science"
and "sage-on-gentoo" overlays (some special repositories to use debian/ubuntu 
jargon).

> It's very odd to me that assembly code needs to be rewritten to
> support this hardware feature. It's certainly something I've never
> heard about before.
> 
Assembly is supposed to be "close" to the hardware - it doesn't surprise 
me at all. The amount of change is rather minimal however.

Francois

-- 
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: MPIR 1.3.0 released (at last)

[David Kirkby]

On 30 January 2010 01:03, François Bissey  wrote:
> Hi Bill,

> It is a bit more subtle than that, it should work most of the time. The main
> case where things could go south is if you have a hardened system with
> the NX bit turned on - my guess.
> It is a QA issue meaning that actual side effects are hard to predict 
> depending
> on what is actually done. The check just points out to "bad practise".
>
> I guess I gave you too much info in one go. A lot of stuff is explained there
> with what kind of steps that can be taken to get rid of them:
> http://hardened.gentoo.org/gnu-stack.xml
>
> You inherited that stuff from gmp, it is a known issue there as well. The
> problem is you have an enormous amount of assembler files so some systematic
> approach is needed. By the way
>
> My comment about yasm is that the fix is also different if you use yasm 
> compared
> to other assembler. In Gentoo gmp has a quite ugly patch that get rid of
> all the problem in one go - on linux only - but wouldn't work with yasm.
>
> Francois

First, it should be noted the problem is occurring with Solaris on
SPARC, not x64.

MPIR 1.3 builds on Open Solaris on ny Sun Ultra 27, which has an Intel
Xeon W3580 3.33 GHz processor. The Intel Xeon has this "Execute
Disable Bit". So one might expect the problem to exist on my Intel
processor.

http://ark.intel.com/Product.aspx?id=39723

but it does not. Other things to note are:

 * SPARC processors have long had this feature well before Intel or
AMD. The protection was introduced in Solaris 2.6, which came out in
July 1997.

http://blogs.sun.com/gbrunett/entry/solaris_non_executable_stack_overview

 * The protection is not on by default on 32-bit code, though it is on
64-bit code. That could explain why this problem occurs on SPARC
64-bit, but not on SPARC 32-bit.

 * It is possible to disable this protection, though of course one
needs root access to do this and the machine will need rebooting.
Hence I do not wish to do this on 't2' just now, although I do have
root access on 't2'.

 * Not only is it possible to enable/disable this, but it is possible
to log this on Solaris, so one could determine who run what command
which attempted to exploit the stack.

I will however test this out later today (within the next 12 hours) on
the Sun Blade 2000 I own. That will at least enable us to determine if
it is the hardening in Solaris on SPARC which is causing this. The
fact this has been around since 13 years on Solaris, makes me a bit
suspicious this is not the reason. But the only way to be sure is to
disable the protection.

The only SPARC system I have running at home is busy, and I do not
wish to reboot it. However, I have another SPARC which is not running
now, but which I can run later today. My wife is asleep now, and since
that Blade 2000 sounds like a rocket engine until the fan speed
control kicks in, I can not start that machine now.

Hence later today I will boot a SPARC with the protection disabled,
which will determine if this is the cause or not.

Dave

-- 
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] Problem with libpng 12.0.dylib when running Sphinx on Mac OS 10.6

[Craig Citro]

Hi Alexandre,

> The problem is that I get the following messages (repeated about a
> thousand of times) :
>
> WARNING: display latex u'{\\rm SL}_2(\\ZZ)': latex exited with error:
> [stderr]
> dyld: Library not loaded: /opt/local/lib/libpng12.0.dylib
>  Referenced from: /opt/local/bin/latex
>  Reason: Incompatible library version: latex requires version 39.0.0
> or later, but libpng12.0.dylib provides version 36.0.0
>

I had that same problem on my machine. In my case, I made sure to
remove /usr/X11/lib from LD_LIBRARY_PATH and DYLD_LIBRARY_PATH,
because it was finding my system-wide libpng, and that was causing
trouble. (Sage builds its own libpng, so it should be finding that
one.) It looks like yours is in /opt/local -- I'd try removing that
from your path and then running Sage. (I can send you my edits to do
that as part of sage startup, if you'd like.) If that doesn't fix it,
let me know and I'll think harder. ;)

-cc

-- 
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: MPIR 1.3.0 released (at last)

[François Bissey]

On Sat, 30 Jan 2010 16:28:04 David Kirkby wrote:
> I will however test this out later today (within the next 12 hours) on
> the Sun Blade 2000 I own. That will at least enable us to determine if
> it is the hardening in Solaris on SPARC which is causing this. The
> fact this has been around since 13 years on Solaris, makes me a bit
> suspicious this is not the reason. But the only way to be sure is to
> disable the protection.
> 
I didn't post this with the idea it would solve your problem but it'd be
nice. However since the defect is in gmp too, and I expect you never 
had the problem with gmp, I am doubtful as well.

Francois

-- 
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] Re: Question about set() in Python on different platforms

[Dima Pasechnik]

it shows, by the way, that idea to use set() (or Set()) to remedy
differences in docstrings with
the output of randomised procedures, discussed
here: 
http://groups.google.com/group/sage-devel/browse_thread/thread/1f688f25bdd5dab2
does not really fly.


On Jan 30, 10:38 am, kcrisman  wrote:
> On #7325, we are getting hardware or software-dependent results, which
> are easy to deal with as the results are equivalent, but which raises
> the question of how to correctly use of Python's set().
>
> On sage.math:
> sage: set((x,y))
> set([y, x])
>
> On my Macintel 10.5:
> sage: set((x,y))
> set([x, y])
>
> Then when one makes an iterator, it becomes dependent on this.  set()
> is a pure Python thing, I believe.  Can anyone shed light on this - to
> be precise, how to avoid this dependence in making an iterator without
> (say) sorting?  Has this ever caused problems in Sage before?
>
> Thanks for any insight on this Python question!
>
> - kcrisman

-- 
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] Re: docstrings test failures for randomised computations

[Dima Pasechnik]

William,
I think TESTS:: would be a good idea!
Having an optional part TESTS:: where one can put more or less any
Sage code; if TESTS:: is present,
EXAMPLES:: is ignored, and otherwise EXAMPLES:: play the role of
TESTS::

Indeed, without this it is impossible to really test, say, a function
that
produces a matrix that is only known up to (unknown) permutations of
rows and columns.
An example of a test that is basically not possible to make
consistently, is
values()
sage/groups/class_function.py
(this function basically returns such a matrix, namely a character
table of a group, for which the
order of conj. classes etc is a priori not known)

Dima

On Jan 29, 2:09 pm, William Stein  wrote:
> On Thu, Jan 28, 2010 at 10:06 PM, John H Palmieri
>
>
>
>
>
>  wrote:
> > On Jan 28, 9:59 pm, Dima Pasechnik  wrote:
> >> as discussed recently here in connection with GAP interface, the
> >> following looks like an obvious deficiency of docstrings testing: a
> >> computation returns a list in some unpredictable order, and docstrings
> >> are in another order, even though the corresponding sets are the same.
>
> >> Just sorting the list in Sage does not work, as the object in question
> >> has a state maintained by an external program (e.g. GAP), and messing
> >> up this order is no fun at all.
> >> (well, yes, one can think of maintaining the permutation used for the
> >> sorting, etc etc, but this looks like an unnecessary kludge)
>
> >> It seems to me that the right way to deal with this is to extend the
> >> capabilities of the testing scheme so that it is able to handle sets,
> >> not only lists.
>
> > Maybe you can write doctests in one of these forms
>
> > sage: set([output from function...]) == set([what the output is
> > supposed to be])
> > True
>
> > (or use Set instead of set?)
>
> > sage: (some known element) in [output from function]
> > True
>
> > sage: convert output to string and do some string comparisons on it
>
> +1 to John's suggestion to rewrite your tests so that the lists are
> sorted in a sensible way.   There are many ways to do so as he pointed
> out.   If we can avoid it, we shouldn't  change the Python doctest
> framework any more than we already have (which is very minimal).
>
> We could add a function to Sage for testing purposes, such as:
>
> sage: strsort(v)
>
> which would takes it input (any iterable), convert all entries to
> strings, then sort, then output the result as a list.  Then your
> doctests would display that output.
>
> It's good to keep in mind that doctests are meant to be viewed by
> people, so tests like the above that maybe aren't so human readable
> should go in the
>
> TESTS::
>
> section instead of the EXAMPLES:: section.
>
>  -- William

-- 
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] Re: Question about set() in Python on different platforms

[John H Palmieri]

On Jan 29, 8:46 pm, Dima Pasechnik  wrote:
> it shows, by the way, that idea to use set() (or Set()) to remedy
> differences in docstrings with
> the output of randomised procedures, discussed
> here:http://groups.google.com/group/sage-devel/browse_thread/thread/1f688f...
> does not really fly.

How does it show this?  If your expected output is a list [x,y] or
[y,x], but you can't tell which, then

sage: set(OUTPUT) == set([x,y])
True
sage: x in OUTPUT
True
sage: y in OUTPUT
True
sage: len(OUTPUT)
2

I see that you can't do

sage: OUTPUT
set([x,y])

but why not the other options?  I feel like I'm missing something...

> On Jan 30, 10:38 am, kcrisman  wrote:
>
>
>
> > On #7325, we are getting hardware or software-dependent results, which
> > are easy to deal with as the results are equivalent, but which raises
> > the question of how to correctly use of Python's set().
>
> > On sage.math:
> > sage: set((x,y))
> > set([y, x])
>
> > On my Macintel 10.5:
> > sage: set((x,y))
> > set([x, y])
>
> > Then when one makes an iterator, it becomes dependent on this.  set()
> > is a pure Python thing, I believe.  Can anyone shed light on this - to
> > be precise, how to avoid this dependence in making an iterator without
> > (say) sorting?  Has this ever caused problems in Sage before?

I think you should only use set when you don't care about ordering.
That's its whole point, right?

--
John

-- 
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: docstrings test failures for randomised computations

[Robert Bradshaw]

On Jan 29, 2010, at 9:27 PM, Dima Pasechnik wrote:


William,
I think TESTS:: would be a good idea!
Having an optional part TESTS:: where one can put more or less any
Sage code; if TESTS:: is present,
EXAMPLES:: is ignored, and otherwise EXAMPLES:: play the role of
TESTS::


We already use TESTS blocks. Both should be tested if both exist.


Indeed, without this it is impossible to really test, say, a function
that
produces a matrix that is only known up to (unknown) permutations of
rows and columns.
An example of a test that is basically not possible to make
consistently, is
values()
sage/groups/class_function.py
(this function basically returns such a matrix, namely a character
table of a group, for which the
order of conj. classes etc is a priori not known)


The thing to do here is something like

sage: M = x.values(); M # random permutation
[your matrix here]

then demonstrate that M has the right properties (not sure what they  
are in your case, but there should be something you can do that tests  
correct matrices from incorrect ones, and as well as making good tests  
this kind of thing is mathematically instructive as well).


- Robert

--
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: MPIR 1.3.0 released (at last)

[Dr. David Kirkby]

François Bissey wrote:

On Sat, 30 Jan 2010 16:28:04 David Kirkby wrote:

I will however test this out later today (within the next 12 hours) on
the Sun Blade 2000 I own. That will at least enable us to determine if
it is the hardening in Solaris on SPARC which is causing this. The
fact this has been around since 13 years on Solaris, makes me a bit
suspicious this is not the reason. But the only way to be sure is to
disable the protection.


I didn't post this with the idea it would solve your problem but it'd be
nice. However since the defect is in gmp too, and I expect you never 
had the problem with gmp, I am doubtful as well.


Francois

To be honest, I'm not sure if I've ever built GMP with an ABI of 64 on SPARC. I 
just checked the on SPARC I have running at the minute, and there are no 64-bit 
libraries - only 32-bit ones. I believe I have had issues before with GMP and 
64-bit. So you could well have hit on something here.


I've never worried too much about the lack of a 64-bit ABI, as the Sage build 
was defaulting to 32-bit on Solaris, and there was no easy way to make it 
64-bit. In any case, gcc has historically been a lot more buggy on 64-bit SPARC 
than it has on 32-bit SPARC.


It is only more recently, I've changed some of the packages  so they can build 
64-bit. Jaap Spies is also changing some. It is one of the most boring tasks 
there is, changing


if [ 'uname' = "Darwin" -a $SAGE64 = "yes" ] ; then

to:

if [ $SAGE64 = yes ] ; then

in 100 or so .spkg files.

The need for 64-bit has increased with Open Solaris, since I do not see any 
point in making a 32-bit build of Sage on Open Solaris. That, coupled with the 
fact I could not even get the SSL libraries to build as 32-bit, convinced me 
that 32-bit was a waste of time for Sage, and that we should go directly for 
64-bit.


I'll test mpir with the protection disabled on Solaris 10 on a SPARC. At least 
we will know for sure, but I need to wait for my wife to wake up before I can 
power up the Blade 2000, as it is extremely loud for a minute or two after 
powering on, until the fan speed control system kicks in.


Dave

--
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] Re: Request for "gamma" distribution

[Gokhan Sever]

On Jan 23, 3:04 pm, gsever  wrote:
> Hello,
>
> Is there any plan to add some other distributions mentioned in:
>
> http://hg.sagemath.org/sage-main/file/21efb0b3fc47/sage/gsl/probabili...
>
>  50 #TODO: Add more distributions available in gsl
>  51 #available but not currently wrapped are exponential, laplace,
> cauchy, landau, gamma,
>  52 #gamma, beta logistic.
>
> particularly, the "gamma" one?

I have been working on the 
http://hg.sagemath.org/sage-main/file/21efb0b3fc47/sage/gsl/probability_distribution.pyx
file for a few days. I have completed the TODO list except the
doctests. However while looking at the GSL manual (http://www.gnu.org/
software/gsl/manual/html_node/Random-Number-Distributions.html) I have
realized that some functionality is missing in this wrapper.
(Particulary CDF's for Q and inverse CDF Q's) I am not sure why these
are skipped in the wrapper.

Moreover while browsing for the other language bindings I have come
across almost a full binding from Perl guys using SWIG --@
http://search.cpan.org/~leto/Math-GSL/
They are approach is different what is currently implemented for the
SAGE's. They automate the binding process throughout the templates.
Could someone enlighten me why SAGE takes the manual approach? (No
need for that sophisticated wrapping or lack or man-power / time type
of deal?)

Once these questions of mine answered I would continue working where I
have left the code. I also sent an e-mail asking PyGSL guys to improve
the GSL-SAGE integration further.

Thanks for your time.

Gökhan

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