On Tue, Nov 15, 2011 at 10:52 PM, Bill Janssen wrote:
>> > Again, installing libjpeg.dylib and/or libpng.dylib into $SAGE_LOCAL/
>> > lib has bad side effects on OS X, due to the use of DYLD_LIBRARY_PATH
>> > in the Sage framework overall. So, maybe make it an optional spkg,
>> > but having it as
On Tue, 15 Nov 2011 at 09:49PM -0800, William Stein wrote:
> On Tue, Nov 15, 2011 at 9:33 PM, Keshav Kini wrote:
> > Why separate it out into another function _list_plot?
I do like the idea of _list_plot() accepting only one format, and the
user-facing list_plot() doing the work of mangling your
On Tue, 15 Nov 2011 at 08:19PM -0800, William Stein wrote:
> Right now, we have:
>
> sage: list_plot([1+I, 2+I, 4-I])
> Traceback (most recent call last):
> ...
> TypeError: unable to simplify to float approximation
>
> I suppose you could rewrite list_plot so that it calls a function
> _list_plo
> > Again, installing libjpeg.dylib and/or libpng.dylib into $SAGE_LOCAL/
> > lib has bad side effects on OS X, due to the use of DYLD_LIBRARY_PATH
> > in the Sage framework overall. So, maybe make it an optional spkg,
> > but having it as a required or standard spkg would be bad.
>
> We already i
Yep.
On Tue, Nov 15, 2011 at 10:31 PM, Bill Janssen wrote:
> I'm a bit unclear on what the value of patchlevel should be in my new
> PIL package. I carry over the two patches from pil-1.1.6.p4, but it's
> a new PIL version, so I'm thinking pil-1.1.7.p0. Would that be
> correct?
>
> --
> To post
I'm a bit unclear on what the value of patchlevel should be in my new
PIL package. I carry over the two patches from pil-1.1.6.p4, but it's
a new PIL version, so I'm thinking pil-1.1.7.p0. Would that be
correct?
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscri
On Tue, Nov 15, 2011 at 9:33 PM, Keshav Kini wrote:
> Why separate it out into another function _list_plot? Why not just put a try
> block into the function? That seems like it would make the source harder to
> read and tracebacks longer without much benefit. It's also another matter
> whether or
Why separate it out into another function _list_plot? Why not just put a
try block into the function? That seems like it would make the source
harder to read and tracebacks longer without much benefit. It's also
another matter whether or not complex numbers being in the list are an
"exceptional
On Tue, Nov 15, 2011 at 8:44 PM, Dan Drake wrote:
> On Tue, 15 Nov 2011 at 07:59PM -0800, William Stein wrote:
>> To build, I had to install these packages:
>>
>> yum install gcc emacs make screen gcc-c++ gcc-gfortran
>
> You need emacs to build Sage? Wow, emacs really *is* an operating
> syste
It seems that I've discovered more broken things in the plotting code!
I'm trying to get my plots to look right, and I've discovered that I
can't alter the legend or aspect ratio with the relevant "set_" functions:
sage: q = plot(tan(x), (x,-1,1))
sage: q.set_aspect_ratio(5)
...which has no affe
On Tue, 15 Nov 2011 at 07:59PM -0800, William Stein wrote:
> To build, I had to install these packages:
>
>yum install gcc emacs make screen gcc-c++ gcc-gfortran
You need emacs to build Sage? Wow, emacs really *is* an operating
system...!
> The build literally took *4 DAYS* to complete (!).
On Tue, Nov 15, 2011 at 7:01 PM, Dan Drake wrote:
> Hello,
>
> At ticket #12035, I posted a patch that makes list_plot do the obvious
> thing when given a list such as
>
> [1+I, 2+I, 4-I]
>
> The only way I could see for detecting "genuine" complex number input
> was to iterate over the entir
HI Sage-Devel,
In case anybody is curious, I signed up for one of the free Amazon EC2
virtual machines, selected the "Amazon Linux AMI release 2011.09"
operating system, and built Sage-4.7.2 from source.This virtual
machine has one 2.6Ghz processor and 600MB RAM.
To build, I had to install t
On Tue, Nov 15, 2011 at 7:01 PM, Bill Janssen wrote:
> Are there any spkgs elsewhere in Sage which require libjpeg? If so,
> what version of it? I know that scipy has an imread function; anyone
> know what does it do for JPEG?
>
> Again, installing libjpeg.dylib and/or libpng.dylib into $SAGE_LO
On 11/15/11 9:25 PM, Dan Drake wrote:
Here are two skinny plots:
sage: foo = list_plot([(0, 0), (-4.85722573273506e-17, 0.251310273150262),
(4.85722573273506e-17, 0.502620546300524), (-3.46944695195361e-17,
0.753930819450786), (6.93889390390723e-18, 1.00524109260105),
(-2.08166817117217e
Here are two skinny plots:
sage: foo = list_plot([(0, 0), (-4.85722573273506e-17, 0.251310273150262),
(4.85722573273506e-17, 0.502620546300524), (-3.46944695195361e-17,
0.753930819450786), (6.93889390390723e-18, 1.00524109260105),
(-2.08166817117217e-17, 1.25655136575131), (6.93889390390723
On Nov 15, 7:01 pm, Bill Janssen wrote:
> Are there any spkgs elsewhere in Sage which require libjpeg? If so,
> what version of it? I know that scipy has an imread function; anyone
> know what does it do for JPEG?
I looked it up; it uses PIL.
--
To post to this group, send an email to sage-de
Hello,
At ticket #12035, I posted a patch that makes list_plot do the obvious
thing when given a list such as
[1+I, 2+I, 4-I]
The only way I could see for detecting "genuine" complex number input
was to iterate over the entire input, running CC() on everything and
looking for nonzero imagi
Are there any spkgs elsewhere in Sage which require libjpeg? If so,
what version of it? I know that scipy has an imread function; anyone
know what does it do for JPEG?
Again, installing libjpeg.dylib and/or libpng.dylib into $SAGE_LOCAL/
lib has bad side effects on OS X, due to the use of DYLD_L
On 11/15/11 8:49 PM, William Stein wrote:
Yes. A standard function in matlab is imread [1], which can read in
jpg images.
It appears from the documentation that the scipy imread function
requires PIL (which presumably would require libjpeg):
http://docs.scipy.org/doc/scipy/reference/genera
On Tue, Nov 15, 2011 at 6:01 PM, kcrisman wrote:
>
>
> On Nov 15, 5:34 pm, William Stein wrote:
>> On Tue, Nov 15, 2011 at 2:10 PM, Bill Janssen wrote:
>> > On Nov 15, 1:02 pm, "Georg S. Weber"
>> > wrote:
>> >> Some people buidling
>> >> Sage from source do *want* a libjpeg on their system to
On Tue, Nov 15, 2011 at 5:46 PM, Bill Janssen wrote:
>> One trivial thing you could do would be to build from source in /tmp/,
>> then just move your install to your home directory. Sage supports
>> moving complete installs.
>
> That's basically what I am doing. Still breaks because it's trying
On Nov 15, 8:46 pm, Bill Janssen wrote:
> > One trivial thing you could do would be to build from source in /tmp/,
> > then just move your install to your home directory. Sage supports
> > moving complete installs.
>
> That's basically what I am doing. Still breaks because it's trying to
> do
On Nov 15, 5:34 pm, William Stein wrote:
> On Tue, Nov 15, 2011 at 2:10 PM, Bill Janssen wrote:
> > On Nov 15, 1:02 pm, "Georg S. Weber"
> > wrote:
> >> Some people buidling
> >> Sage from source do *want* a libjpeg on their system to be taken into
> >> accont by their PIL in Sage!
>
> > Reall
On Nov 15, 12:29 pm, "Georg S. Weber"
wrote:
> it installs quite some files e.g. under $SAGE_LOCAL/bin/ which
> no Sage user needs (or even knows of, I guess), thus "polluting" the
> tree without having cleanup mechansims at hand.
I've just reviewed the scripts in Imaging-1.1.7/Scripts/, and I se
> One trivial thing you could do would be to build from source in /tmp/,
> then just move your install to your home directory. Sage supports
> moving complete installs.
That's basically what I am doing. Still breaks because it's trying to
do stuff in ~janssen/.sage/ as part of the build. I can
> The only real advantages of keeping the upstream sources packaged is
> that (1) you can know what's in them, check md5sums, etc., and (2)
> there's less chance of introducing hard-to-find errors by fat-
> fingering a particular unpacked source file. But I'm happy to unpack,
> too.
>
Hi,
In my
The only real advantages of keeping the upstream sources packaged is
that (1) you can know what's in them, check md5sums, etc., and (2)
there's less chance of introducing hard-to-find errors by fat-
fingering a particular unpacked source file. But I'm happy to unpack,
too.
On Nov 15, 2:01 pm, Maa
On Tue, Nov 15, 2011 at 2:10 PM, Bill Janssen wrote:
> On Nov 15, 1:02 pm, "Georg S. Weber"
> wrote:
>> Some people buidling
>> Sage from source do *want* a libjpeg on their system to be taken into
>> accont by their PIL in Sage!
>
> Really? Do you have user studies or other evidence of that I c
On Tue, Nov 15, 2011 at 2:13 PM, Bill Janssen wrote:
> On Nov 15, 1:29 pm, "Georg S. Weber"
> wrote:
>> On 15 Nov., 18:51, Bill Janssen wrote:
>>
>> > It would be nice if the developer's guide talked about using sage -i
>> > and sage -f to test new spkg's. In the section about building spkg's,
The function (unpacked from main.js) below limits the title to 30
characters. Can we instead,
a) Make the limit larger by default, and possibly,
b) let the CSS/JS dynamically limit the size on the page horizontally
by either displaying ellipsis or by wrapping the text within the div
element, or
c
On Nov 15, 1:29 pm, "Georg S. Weber"
wrote:
> On 15 Nov., 18:51, Bill Janssen wrote:
>
> > It would be nice if the developer's guide talked about using sage -i
> > and sage -f to test new spkg's. In the section about building spkg's,
> > perhaps.
>
> Yes.
>
> Two or three sentences, maybe?
Some
On Nov 15, 1:02 pm, "Georg S. Weber"
wrote:
> Some people buidling
> Sage from source do *want* a libjpeg on their system to be taken into
> accont by their PIL in Sage!
Really? Do you have user studies or other evidence of that I could
look at on that? It's surprising to me; I'd think that one
>
>
> Hi,
>
> there is another reason:
> "tar" is not necessarily equal to "tar". The Sage build scripts try to
> use only the most generic options, and provenly work on the supported
> number of systems. If you provide some file tarred upstream, then this
> might not be "out-of-the-box" read
On Nov 15, 2011, at 12:19 , William Stein wrote:
> On Tue, Nov 15, 2011 at 12:05 PM, Georg S. Weber
> wrote:
>>
>>
>> On 15 Nov., 18:18, Jeroen Demeyer wrote:
>>> On 2011-11-15 18:09, Maarten Derickx wrote:> I think 102400 byte wich
>>> is about 1 gigabyte is a bit to much to
alloca
On 15 Nov., 18:51, Bill Janssen wrote:
> It would be nice if the developer's guide talked about using sage -i
> and sage -f to test new spkg's. In the section about building spkg's,
> perhaps.
Yes.
Two or three sentences, maybe? I think you could better formulate what
you (it seems) have soug
Thanks for the quick replies! So it seems that the errors are not due to
sage, but due to the machine not having enough memory. This info will be
very useful.
For your info. The machine I installed it on was a vm I got acces to from
the sys admins here, and they want to make it the new sage se
On 15 Nov., 21:35, Bill Janssen wrote:
> Georg,
>
> I'll fix those problems (unwanted binaries in $SAGE_LOCAL/bin/, and
> linking against unintended libraries), in my new spkg.
>
Please be careful to not throw away "too much". Some people buidling
Sage from source do *want* a libjpeg on their s
On 15 Nov., 21:38, Bill Janssen wrote:
> Fine with me.
>
> But if the src directory is allowed to be a modified version of
> upstream, why not just integrate the Sage-specific patches directly
> into the sources, too?
>
> Bill
>
> On Nov 15, 11:29 am, William Stein wrote:
>
Ease of workflow.
On 11/15/11 2:38 PM, Bill Janssen wrote:
Fine with me.
But if the src directory is allowed to be a modified version of
upstream, why not just integrate the Sage-specific patches directly
into the sources, too?
For ease in updating. Most of the time, the src is just a vanilla copy
of the rea
On 15 Nov., 20:29, William Stein wrote:
> On Tue, Nov 15, 2011 at 11:13 AM, Bill Janssen wrote:
> > I'm a bit unclear as to why third-party source packages are unpacked
> > in an spkg? Since the patching protocol is very strict, would it make
> > sense for me to include Imaging-1.1.7.tar in th
Fine with me.
But if the src directory is allowed to be a modified version of
upstream, why not just integrate the Sage-specific patches directly
into the sources, too?
Bill
On Nov 15, 11:29 am, William Stein wrote:
> On Tue, Nov 15, 2011 at 11:13 AM, Bill Janssen wrote:
> > I'm a bit unclear
Georg,
I'll fix those problems (unwanted binaries in $SAGE_LOCAL/bin/, and
linking against unintended libraries), in my new spkg.
Little-known fact about PIL: it doesn't actually use libtiff -- the
checks are in there for an experimental module which doesn't ship with
the distribution.
I've dec
On 15 Nov., 20:03, Bill Janssen wrote:
> I'm building a new spkg for PIL 1.1.7.
>
> I'd like to build PIL, then run its test suite, then if that passes,
> install it. Should I just do all of that in spkg-install, or should I
> run the test suite in spkg-check? If I install it before I test it,
On Tue, Nov 15, 2011 at 12:05 PM, Georg S. Weber
wrote:
>
>
> On 15 Nov., 18:18, Jeroen Demeyer wrote:
>> On 2011-11-15 18:09, Maarten Derickx wrote:> I think 102400 byte wich is
>> about 1 gigabyte is a bit to much to
>> > allocate just at once. So the main question is where does this numbe
On 15 Nov., 18:18, Jeroen Demeyer wrote:
> On 2011-11-15 18:09, Maarten Derickx wrote:> I think 102400 byte wich is
> about 1 gigabyte is a bit to much to
> > allocate just at once. So the main question is where does this number
> > come from and why is it so huge?
>
> The Heegner test simp
Oh, I see. However, this is not made explicit in the documentation, and it
does work with symbolics sometimes. For example,
find_maximum_on_interval(-x^2 + 9*x, 1, 3)
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-de
On Tue, Nov 15, 2011 at 11:13 AM, Bill Janssen wrote:
> I'm a bit unclear as to why third-party source packages are unpacked
> in an spkg? Since the patching protocol is very strict, would it make
> sense for me to include Imaging-1.1.7.tar in the "src" directory of
> the spkg, instead of unpacki
On Tue, Nov 15, 2011 at 11:03 AM, Bill Janssen wrote:
> I'm building a new spkg for PIL 1.1.7.
>
> I'd like to build PIL, then run its test suite, then if that passes,
> install it. Should I just do all of that in spkg-install, or should I
> run the test suite in spkg-check?
You should run the t
As you probably saw with the Sage Days 36 / 35.5 confusion just now,
there has been some confusion about assigning numbers for Sage Days.
The confusion stemmed from two different places that numbers were
claimed: on the wiki home page and on the Workshops wiki page.
We've cleaned that duplicat
I'm a bit unclear as to why third-party source packages are unpacked
in an spkg? Since the patching protocol is very strict, would it make
sense for me to include Imaging-1.1.7.tar in the "src" directory of
the spkg, instead of unpacking it into raw files?
--
To post to this group, send an email
Here is a typical short one, from the R spkg.
#!/bin/bash
if [ "$SAGE_LOCAL" = "" ]; then
echo "SAGE_LOCAL undefined ... exiting";
exit 1
fi
cd src
make check
if [ $? -ne 0 ]; then
echo "Error while running the R testsuite ... exiting"
exit 1
fi
Less typically, here is the c
On 11/15/11 10:03 AM, Jason Grout wrote:
We are pleased to announce Sage Days 36:
Justin W. brought to our attention that Sage Days 36 was already taken
by the padic Sage Days, so we are now calling the bug days Sage Days
35.5, and the new web page is here:
http://wiki.sagemath.org/days35.
I'm building a new spkg for PIL 1.1.7.
I'd like to build PIL, then run its test suite, then if that passes,
install it. Should I just do all of that in spkg-install, or should I
run the test suite in spkg-check? If I install it before I test it,
that means that broken code could overwrite workin
On Nov 15, 1:46 pm, Bill Janssen wrote:
> Sorry, I mean "spkg-check".
>
spkg-check is supposed to be run when the env variable
SAGE_CHECK
is set to "yes", or perhaps to something non-empty. There is ...
flexibility on what different spkgs do with this. They would be in
spkg files, in the to
Sorry, I mean "spkg-check".
Bill
On Nov 15, 10:40 am, Bill Janssen wrote:
> Can someone please point me to an example of a sage-check file? I
> don't see any explanation in the developer docs.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this grou
Can someone please point me to an example of a sage-check file? I
don't see any explanation in the developer docs.
--
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, vi
It would be nice if the developer's guide talked about using sage -i
and sage -f to test new spkg's. In the section about building spkg's,
perhaps.
--
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...@goog
On 2011-11-15 18:09, Maarten Derickx wrote:
> I think 102400 byte wich is about 1 gigabyte is a bit to much to
> allocate just at once. So the main question is where does this number
> come from and why is it so huge?
The Heegner test simply needs that much memory...
Normally you need between
Dear All,
Today I managed to install sage 4.7.2 from source on Suse Linux Enterprise
Server (sles) 11 SP 1. Almost all doctest pass except for:
The following tests failed:
sage -t devel/sage/sage/sandpiles/sandpile.py # Time out
sage -t devel/sage/sage/schemes/elliptic_curves
On 11/14/11 1:13 PM, Tom Boothby wrote:
I'll doctest polynomial_compiled this week, since it's 100% my fault.
Thanks. I just doctested interpolation.pyx, which uses GSL's for
splines. It was very straightforward. Please review it at
http://trac.sagemath.org/sage_trac/ticket/12036
In
Hi there,
I'm trying to make sage aware of indexed variables. For the information, this
is a long standing Sage-Combinat wish. more precisely, basically I need a sage
object Y such that, for any object (say hashable) o:
1 - the call Y[o] returns a variable which is legal in symbolic express
On Tuesday, November 15, 2011 2:15:39 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2011-11-15 11:06, Jeroen Demeyer wrote:
> > To somebody with access to a OS X 10.7 machine: please test whether the
> spkg
> >
> >
> http://boxen.math.washington.edu/home/jdemeyer/spkg/ecl-11.1.2.cvs2007.p0.spkg
We are pleased to announce Sage Days 36:
http://wiki.sagemath.org/days36
to be held immediately after the Joint Mathematics Meetings, at Gordon
College in Wenham, Mass. This will be, like Sage Days 19 and 27, a
post-Joint Math Meetings Bug Days event.
We expect the primary emphasis to be fi
I created a ticket ...
http://trac.sagemath.org/sage_trac/ticket/12042
I will also email H. Shilly about it
--
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 thi
Just a note from a less than satisfied customer... From
http://ask.sagemath.org/question/904/sage-on-windows-not-working?answer=1476#1476
Yes, when I had trouble installing this several months ago and wasted
a bunch of my time because I tried to use VMWare, I suggested that the
documentation be c
On Nov 15, 7:30 am, Rita Morgan wrote:
> Hello,
>
> Just curious what the status of Python 2.7.x is with SAGE.
See http://trac.sagemath.org/sage_trac/ticket/9958 for the latest
info.
- kcrisman
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this gr
Hello,
Just curious what the status of Python 2.7.x is with SAGE.
--
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/
On 2011-11-15 11:06, Jeroen Demeyer wrote:
> To somebody with access to a OS X 10.7 machine: please test whether the spkg
>
> http://boxen.math.washington.edu/home/jdemeyer/spkg/ecl-11.1.2.cvs2007.p0.spkg
Also please test
http://boxen.math.washington.edu/home/jdemeyer/spkg/ecl-11.1.2.cvs2011
To somebody with access to a OS X 10.7 machine: please test whether the spkg
http://boxen.math.washington.edu/home/jdemeyer/spkg/ecl-11.1.2.cvs2007.p0.spkg
compiles properly (see #11884).
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group,
On 2011-11-13 08:15, William Stein wrote:
> On Sat, Nov 12, 2011 at 11:10 PM, William Stein wrote:
>> I'll look into it.
>> On Sat, Nov 12, 2011 at 10:42 PM, Dima Pasechnik wrote:
>>> It's still 4.7.
>
> I can't easily upgrade because of the bug that makes upgrading
> completely broken these day
On Nov 14, 6:11 pm, William Stein wrote:
> On 11/14/11 8:44 AM, David Roe wrote:
>
>
>
> > I think I'd describe it as a feature to reduce the number of GF(7)s
> > floating around. There's no coercion from ZZ[x] to GF(p), regardless
> > of the choice of modulus. The modulus function on
> > Fini
This is now #12038, which has a patch which eliminates the segfault.
The problem was that you shouldn't be using coerce like that: the
first argument should be a parent, not the element class. That
element class requires two inputs: both the parent and the data to
make a new element out of. In t
73 matches
Mail list logo
