[sage-devel] Re: SAGE development machines
I'm not sure about VMware. One advantage to laptops is that, because of the number of student developers in the UW area, they could be used as loaners as well. Also, I've heard rumors that vista does not play nice with dual boots. Also, William used the word "dedicated". Will a big machine running n OSs via VMware provide an accurate picture of timings and performance issues? Moreover, a bunch of laptops can be hooked into a LAN to do some testing of SAGE's distributed computing capabilites. Anyway, it's just an idea for discussion. Really, I would like to have SAGE tested on a debian stable machine (as opposed to ubuntu or any other debian-based system). I know the package management system is the same but I believe the packages are a bit different in some cases. (I used to have a debian laptop and am much happier that it is now ubuntu.) In particular, I remember having trouble with java. I'm not a java fan and not an computer literate as you all are so maybe my experiences were'nt typical. Nonetheless, I believe a 100% debian stable machine is a worthy test machine for SAGE, especially a 64 bit one. ++ Yi Qiang wrote: > On 12/12/06, David Joyner <[EMAIL PROTECTED]> wrote: > >> IMHO, it is also important to test specific flavors of linux >> (eg, debian, redhat, freeBSD) and windows types (windows XP, >> vista). Laptops could probably be used for this. >> >> > Wouldn't something like VMWare Server on a reasonably powerful machine > do exactly that? There are also other solutions such as OpenVZ and > Xen. I saw a demo of Virtuozzo by one of the employees and it looked > very cool. I think we should leverage the power and in this > particular case, space efficiency of virtualization as much as > possible :) I think that the OSX is the only exception, but I see a > Mac Pro is already on the list. > > Yi > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
> I agree completely with Yi. The point of purchasing machines is to test > different hardware platforms. For different OS installs, we just need > to use some virtualization software. That said, I tried pretty hard to > setup VMWare server once and failed miserably. If anybody (especially > a student at UW) were interested in setting up some sort of virtualization > system, it would be appreciated. I have a friend who works in a sysadmin sort of capacity for Disney, and is utterly enamored with Xen, but also knows VMWare. He's very helpful about such things, and he may be bribeable with food and beer. I'll ask him if he'd help out when I see him Saturday. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
On Wed, 13 Dec 2006 04:57:11 -0800, David Joyner <[EMAIL PROTECTED]> wrote: > > I'm not sure about VMware. One advantage to laptops is that, because > of the number of student developers in the UW area, they could be used > as loaners as well. I do not think laptops are suitable for creating a SAGE testing network. It is very desirable that the machines in the testing network are (1) always on, (2) always physically available Laptops are oftened "checked out" for weekends, and honestly do not do well being left on all the time running hard. Also, they are *much* more expensive for the same stats (memory, processor, etc), since, e.g., they have displays (which we don't need -- a kvm would be fine). Also, laptop hardware options are fairly constrained -- no itanium, no G5, etc. > Also, I've heard rumors that vista does not play nice > with dual boots. Dual booting in all contexts sucks. I've done that enough in my life to know I don't ever want to if it can be avoided. > Also, William used the word "dedicated". Will a big machine > running n OSs via VMware provide an accurate picture of timings > and performance issues? No. But timing and performance are primarily hardware issues not flavor-of-linux issues. Vmware would *only* be used to provide access to a range of Linux disributions for build testing (and this could already be set up on sage.math). For performance testing VMware wouldn't be used. Thanks for all your comments! William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
On 12/13/06, William Stein <[EMAIL PROTECTED]> wrote: > No. But timing and performance are primarily hardware issues > not flavor-of-linux issues. Vmware would *only* be used to > provide access to a range of Linux disributions for build testing > (and this could already be set up on sage.math). For performance > testing VMware wouldn't be used. I've had limited, but extremely positive experiences with VMWare (keep in mind it's free-as-in-beer now). It's easy to set up each image with a dedicated IP on a private subnet and have a user-accessible startup script that does something like: start_vmware_$OSFLAVOR sleep($BOOT_TIME) ssh $VIRTUAL_IP sage_test ssh $VIRTUAL_IP sudo shutdown This way, using a big machine with fast disks, 4 or more cores and gobs of RAM will give you an always-on build/test farm that can do multi-OS tests far more conveniently than anything else out there. I can't speak for Xen (never used it, I'm sure it's good too), but I'm a MAJOR fan of virtualization technologies these days. They really cut a lot of pain out of many common problems, and they beat dual booting by a million miles (unless you need direct OpenGL or other such hardware access, which is not the case here). Cheers, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 3D Java Visualization
On Dec 12, 2006, at 5:00 PM, William Stein wrote: > > On Tue, 12 Dec 2006 11:10:29 -0800, Robert Bradshaw > <[EMAIL PROTECTED]> wrote: >> On Dec 12, 2006, at 3:55 AM, David Joyner wrote: >> I would say that I think Java is the tool for the job, but the >> question is to roll our own "pure" java 3d viewer (without all the >> bells and whistles like colored lights, bump-maps, fog, and graphics- >> card acceleration) or use the already-existing java3d api. > > Is the java3d API easy to install on most modern computers? If so, > I think we should definitely use it for SAGE. I want SAGE to be > technically incredible. The true purpose of the notebook has also > been to provide a GUI for SAGE -- it's not to be a service like > gmail or something. If users have to also install the java3d api, > and it is not difficult to install, then it is a reasonable option. > If it is a major nightmare to install, that is a different story. Yes, it is very easy to install on modern computers. > > Is the java3d api Sun's property? If so, I think that means it will > be GPL'd, which is good. > > William Yes, it is owned (and licensed) buy Sun, though they call it a "community source project" which seems (currently) much more open than the core java libraries. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
William Stein wrote:
> On Tue, 12 Dec 2006 10:27:16 -0800, Nick Alexander <[EMAIL PROTECTED]>
> wrote:
>
> > Hi William,
> >
> > An oddity in ref.pdf. Pyrex filenames get embedded in the output, as
> > in:
> >
> > inverse mod()
> > File: sage/rings/integer.pyx (starting at line 1671)
> >
> > Is that on purpose?
>
> No. That is a result of a change in SAGE -- namely I added an option to
> SAGEX
> so it records the file and location where functions are defined. This is
> used at runtime for source code viewing, and displaying correct functions
> headers.
> The update_script.py script doesn't know about this change. It could be
> used
> to improve the quality of ref.tex (e.g., find the function headers easily).
I would very much like to enhance sagex to embed _more_ information
about cdef'd functions. At the moment, the python inspect module gives
very little information about them. While we might not be able to
include code pointers, etc, we can definitely include arguments and
default values. I'd like to use that information for better formatting
and better tested documentation, but it would also make for better
inline help.
I envision making docstrings hash tables, i.e. such that eval(__doc__)
returns a dict. Your patch would be upgraded to make the docstring
r"""
{ 'im_class' : 'sage.blah.module.Class'
, 'im_func' : { 'attributes about function' : 'blah' }
, '__doc__': 'original docstring'
}"""
etc.
There are downsides. First, we're carting around a lot of information
in the docstrings. There's a space penalty, and also a
not-using-the-natural-structure penalty. I think docstring has to be a
string, though, so we're stuck. If it can be an object with a
__repr__, I'd be much happier. Second, we'd be parsing the docstring
ourselves or calling eval. One tends to be a little brittle, the other
a security hole.
Let me know what you think,
Nick
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
Another consideration, since you've already decided on a Mac Pro, is to get Parallels (a commerical virtualization package for OS X). It will allow you to run all the Linux and Windows Distributions you want on the Mac Pro. Plus, if you wait until late Jan. to purchase the machine, it will probably have 2 Quad-core Xeons in it... that's 8 cores which is very well suited to virtualization. Load that thing up with (third party!) RAM and you'll have all the hardware you need for Intel Core 2 testing. On 12/13/06, Fernando Perez <[EMAIL PROTECTED]> wrote: > > On 12/13/06, William Stein <[EMAIL PROTECTED]> wrote: > > > No. But timing and performance are primarily hardware issues > > not flavor-of-linux issues. Vmware would *only* be used to > > provide access to a range of Linux disributions for build testing > > (and this could already be set up on sage.math). For performance > > testing VMware wouldn't be used. > > I've had limited, but extremely positive experiences with VMWare (keep > in mind it's free-as-in-beer now). It's easy to set up each image > with a dedicated IP on a private subnet and have a user-accessible > startup script that does something like: > > start_vmware_$OSFLAVOR > sleep($BOOT_TIME) > ssh $VIRTUAL_IP sage_test > ssh $VIRTUAL_IP sudo shutdown > > This way, using a big machine with fast disks, 4 or more cores and > gobs of RAM will give you an always-on build/test farm that can do > multi-OS tests far more conveniently than anything else out there. > > I can't speak for Xen (never used it, I'm sure it's good too), but I'm > a MAJOR fan of virtualization technologies these days. They really > cut a lot of pain out of many common problems, and they beat dual > booting by a million miles (unless you need direct OpenGL or other > such hardware access, which is not the case here). > > Cheers, > > f > > > > -- --- Jason Worth Martin Asst. Prof. of Mathematics James Madison University http://www.math.jmu.edu/~martin phone: (+1) 540-568-5101 fax: (+1) 540-568-6857 "Ever my heart rises as we draw near the mountains. There is good rock here." -- Gimli, son of Gloin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] 173.binary()?
Does anyone else think that 173.binary() should be legal? Currently the preparser mangles it into a syntax error, it thinks the dot is a decimal point. One currently needs to do (173).binary() instead. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
William Stein wrote: > If you would like, you could help me make a precise list of SAGE > development machines that I should buy, by editing this wiki > page (or emailing me): > > http://sage.math.washington.edu:9001/hardware > > All SAGE developers would have accounts on all these machines, > and they would be used for: > >(1) building binaries > >(2) benchmarking algorithms and code > One other point. It is not only a question of hardware. There is also the problem of system administration. Maybe it is easy to install some OS'es in virtual machines, but is not a sinecure to keep them up to date. Even when you install from the latest CD's or DVD, there is a lot of upgrading to do. Possibly part of this process can be automated. Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
> Does anyone else think that 173.binary() should be legal? Currently > the > preparser mangles it into a syntax error, it thinks the dot is a > decimal point. One currently needs to do (173).binary() instead. IMO it should be legal. And moreover tab completion should be made to work. Will be tricky! ciao --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
On Wed, 13 Dec 2006 09:45:51 -0800, Nick Alexander <[EMAIL PROTECTED]>
wrote:
>> No. That is a result of a change in SAGE -- namely I added an option to
>> SAGEX
>> so it records the file and location where functions are defined. This
>> is
>> used at runtime for source code viewing, and displaying correct
>> functions
>> headers.
>> The update_script.py script doesn't know about this change. It could
>> be
>> used
>> to improve the quality of ref.tex (e.g., find the function headers
>> easily).
>
> I would very much like to enhance sagex to embed _more_ information
> about cdef'd functions. At the moment, the python inspect module gives
> very little information about them. While we might not be able to
> include code pointers, etc, we can definitely include arguments and
> default values. I'd like to use that information for better formatting
> and better tested documentation, but it would also make for better
> inline help.
Currently the file and line number allows one to extract all
necessary additional information with almost no additional
space overhead. Likewise, the Python inspect module
extracts much information of usual .py code from the actual
source files (and does not work if they are not present).
So I think the thing to do is implement (using the fact that
filename and location information are embedded in the docstring)
an inspect-like API for pyrex files. I do *not* think you should
change sagex to embed _more_ information -- since Python doesn't
even take that approach. Maybe information about function inputs
would be good though.
> I envision making docstrings hash tables, i.e. such that eval(__doc__)
> returns a dict. Your patch would be upgraded to make the docstring
>
> r"""
> { 'im_class' : 'sage.blah.module.Class'
> , 'im_func' : { 'attributes about function' : 'blah' }
> , '__doc__': 'original docstring'
> }"""
>
> etc.
>
> There are downsides. First, we're carting around a lot of information
> in the docstrings. There's a space penalty, and also a
> not-using-the-natural-structure penalty. I think docstring has to be a
> string, though, so we're stuck. If it can be an object with a
> __repr__, I'd be much happier.
No it is a string.
> Second, we'd be parsing the docstring
> ourselves or calling eval. One tends to be a little brittle, the other
> a security hole.
>
> Let me know what you think,
I am against enhancing the docstrings as you suggest. I think we should
write code to parse the original .pyx files, given the filename and line
number information. There is no extra overhead spacewise, and this fits
with how the rest of Python works better. Also, it is what I already
planned to do, but hadn't got to yet All I did was put something for
parsing out the source code -- try ?? on a sagex function.
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: 3D Java Visualization
On Wed, 13 Dec 2006 09:43:08 -0800, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > On Dec 12, 2006, at 5:00 PM, William Stein wrote: >> On Tue, 12 Dec 2006 11:10:29 -0800, Robert Bradshaw >> <[EMAIL PROTECTED]> wrote: >>> On Dec 12, 2006, at 3:55 AM, David Joyner wrote: >>> I would say that I think Java is the tool for the job, but the >>> question is to roll our own "pure" java 3d viewer (without all the >>> bells and whistles like colored lights, bump-maps, fog, and graphics- >>> card acceleration) or use the already-existing java3d api. >> >> Is the java3d API easy to install on most modern computers? If so, >> I think we should definitely use it for SAGE. I want SAGE to be >> technically incredible. The true purpose of the notebook has also >> been to provide a GUI for SAGE -- it's not to be a service like >> gmail or something. If users have to also install the java3d api, >> and it is not difficult to install, then it is a reasonable option. >> If it is a major nightmare to install, that is a different story. > > Yes, it is very easy to install on modern computers. Then I say definitely use it for SAGE. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
On Wed, 13 Dec 2006 10:07:31 -0800, Jason Martin <[EMAIL PROTECTED]> wrote: > > Another consideration, since you've already decided on a Mac Pro, is > to get Parallels (a commerical virtualization package for OS X). It > will allow you to run all the Linux and Windows Distributions you want > on the Mac Pro. Plus, if you wait until late Jan. to purchase the > machine, it will probably have 2 Quad-core Xeons in it... that's 8 > cores which is very well suited to virtualization. Load that thing up > with (third party!) RAM and you'll have all the hardware you need for > Intel Core 2 testing. Cool. I have a licensed copy of Parallels on my laptop that I use all the time, which I realy like. Last week when I was at the coffee shop across the street from my apartment, I randomly met one of the guys who works at Parallels (which is a local Seattle company + 85 "offshore" devs in Russia...). william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
On Wed, 13 Dec 2006 11:17:35 -0800, Jaap Spies <[EMAIL PROTECTED]> wrote: >> >> All SAGE developers would have accounts on all these machines, >> and they would be used for: >> >>(1) building binaries >> >>(2) benchmarking algorithms and code >> > > One other point. It is not only a question of hardware. There is also > the problem of system administration. Maybe it is easy to install some > OS'es in virtual machines, but is not a sinecure to keep them up to date. > Even when you install from the latest CD's or DVD, there is a lot of > upgrading to do. Possibly part of this process can be automated. Does anybody on sage-devel want to volunteer to help with this upgrading of linux distros on a virtual internal machine, when it ever gets created? :-) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
On Wed, 13 Dec 2006 10:54:58 -0800, David Harvey <[EMAIL PROTECTED]> wrote: > > Does anyone else think that 173.binary() should be legal? Currently the > preparser mangles it into a syntax error, it thinks the dot is a > decimal point. One currently needs to do (173).binary() instead. This question comes up somewhat regularly. A very relevant fact is that in normal un-prepared non-SAGE Python, accessing a method of an integer literal is considered a Syntax error: sha:~ was$ python Python 2.5 (r25:51908, Nov 25 2006, 00:28:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> n = 5 >>> n.__add__(7) 12 >>> 5.__add__(7) File "", line 1 5.__add__(7) ^ SyntaxError: invalid syntax --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
My first response to this was revulsion. I find the consequences intriguing,
but also a little revolting.
sage: 173.is_prime()
True
sage: 173.integrate('t') #173 is a function?
865*t
sage: 173.sqrt()
13.1529
Ok... fine. But how do we know what type 173 is, off the bat? ZZ can be
redefined... so ZZ(173) might be quite different in certain contexts. Say, I'm
working in 4x4 matrices or something, and I don't want to always write
17*M.identity_matrix()... I don't think tab completion can be expected to know
the type of the literal 173 without executing ZZ(173) which might change the
environment somehow.
Also, if 173.sqrt() works, why shouldn't 173.12.sqrt()?
Extreme silliness:
sage: 173.
173.0173.10 ...
173.1173.11 ...
173.2173.12 ...
. .
. .
. .
173.additive_order()
.
.
.
On Wed, 13 Dec 2006, David Harvey wrote:
>
> Does anyone else think that 173.binary() should be legal? Currently the
> preparser mangles it into a syntax error, it thinks the dot is a
> decimal point. One currently needs to do (173).binary() instead.
>
> David
>
>
> >
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
On Wed, 13 Dec 2006, Iftikhar Burhanuddin wrote: > > > Does anyone else think that 173.binary() should be legal? Currently > > the > > preparser mangles it into a syntax error, it thinks the dot is a > > decimal point. One currently needs to do (173).binary() instead. > > IMO it should be legal. And moreover tab completion should be made to > work. Will be tricky! On the same lines, I would be happy is tab completion worked in the following scenario. sage: SupersingularModule(11). Should this be legal? And should be implemented without actually creating the oject with *just* syntatic checking? What say folks? Ifti. ps: I'm fixated on tab completions because a lot of my work is done via the command line and I'm annoyed when things don't work the way *I* would like them to work! :) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
On Dec 13, 2006, at 3:06 PM, Iftikhar Burhanuddin wrote: > On the same lines, I would be happy is tab completion worked in the > following scenario. > > sage: SupersingularModule(11). > > Should this be legal? And should be implemented without actually > creating > the oject with *just* syntatic checking? What say folks? How on earth would one implement that? There's no guarantee that the object being returned would be a SupersingularModule, and if it there was such a guarantee, you wouldn't know what methods were attached to the object. I presume actually computing the SupersingularModule is expensive? David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
William Stein wrote:
> On Wed, 13 Dec 2006 09:45:51 -0800, Nick Alexander <[EMAIL PROTECTED]>
> wrote:
> >> No. That is a result of a change in SAGE -- namely I added an option to
> >> SAGEX
> >> so it records the file and location where functions are defined. This
> >> is
> >> used at runtime for source code viewing, and displaying correct
> >> functions
> >> headers.
> >> The update_script.py script doesn't know about this change. It could
> >> be
> >> used
> >> to improve the quality of ref.tex (e.g., find the function headers
> >> easily).
> >
> > I would very much like to enhance sagex to embed _more_ information
> > about cdef'd functions. At the moment, the python inspect module gives
> > very little information about them. While we might not be able to
> > include code pointers, etc, we can definitely include arguments and
> > default values. I'd like to use that information for better formatting
> > and better tested documentation, but it would also make for better
> > inline help.
>
> Currently the file and line number allows one to extract all
> necessary additional information with almost no additional
> space overhead. Likewise, the Python inspect module
> extracts much information of usual .py code from the actual
> source files (and does not work if they are not present).
> So I think the thing to do is implement (using the fact that
> filename and location information are embedded in the docstring)
> an inspect-like API for pyrex files. I do *not* think you should
> change sagex to embed _more_ information -- since Python doesn't
> even take that approach. Maybe information about function inputs
> would be good though.
>
> > I envision making docstrings hash tables, i.e. such that eval(__doc__)
> > returns a dict. Your patch would be upgraded to make the docstring
> >
> > r"""
> > { 'im_class' : 'sage.blah.module.Class'
> > , 'im_func' : { 'attributes about function' : 'blah' }
> > , '__doc__': 'original docstring'
> > }"""
> >
> > etc.
> >
> > There are downsides. First, we're carting around a lot of information
> > in the docstrings. There's a space penalty, and also a
> > not-using-the-natural-structure penalty. I think docstring has to be a
> > string, though, so we're stuck. If it can be an object with a
> > __repr__, I'd be much happier.
>
> No it is a string.
>
> > Second, we'd be parsing the docstring
> > ourselves or calling eval. One tends to be a little brittle, the other
> > a security hole.
> >
> > Let me know what you think,
>
> I am against enhancing the docstrings as you suggest. I think we should
> write code to parse the original .pyx files, given the filename and line
> number information. There is no extra overhead spacewise, and this fits
> with how the rest of Python works better. Also, it is what I already
> planned to do, but hadn't got to yet All I did was put something for
> parsing out the source code -- try ?? on a sagex function.
Okay, this sounds like a good task for me. I personally am not
comfortable with ad-hoc parsing, so I avoid it like the plague, but
I'll take a look at inspect and see what the 'officially sanctioned'
technique is.
On an unrelated note, is there a reason that ?, ??, hg_sage.diff(), etc
use the pager as opposed to printing normally? Is this configurable?
Nick
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
> On the same lines, I would be happy is tab completion worked in the
> following scenario.
>
> sage: SupersingularModule(11).
>
> Should this be legal? And should be implemented without actually creating
> the oject with *just* syntatic checking? What say folks?
No! If you want to know the type of object returned by a function, use a
strongly typed language. Consider the following.
def f() {
if round(random):
return CC(7,3)
else:
return lambda x: x^2
What should a tab completion of
f().
look like?
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
> > sage: SupersingularModule(11). > > > > Should this be legal? And should be implemented without actually > > creating > > the oject with *just* syntatic checking? What say folks? > > How on earth would one implement that? There's no guarantee that the We need to think about how to implement this carefully. And currently I cannot *think* as I'm mechanically grading student finals :) Let's not thrash the idea because it is difficult to implement! First lets answer this Q: is there any value-addition to user-friendliness due to this feature? IMO ... yes! What say? > object being returned would be a SupersingularModule, and if it there > was such a guarantee, you wouldn't know what methods were attached to > the object. I presume actually computing the SupersingularModule is > expensive? Goes without saying ... only as the arguments get bigger :) Ifti. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
On Wed, 13 Dec 2006 12:09:25 -0800, Nick Alexander <[EMAIL PROTECTED]> wrote: >> I am against enhancing the docstrings as you suggest. I think we should >> write code to parse the original .pyx files, given the filename and line >> number information. There is no extra overhead spacewise, and this fits >> with how the rest of Python works better. Also, it is what I already >> planned to do, but hadn't got to yet All I did was put something for >> parsing out the source code -- try ?? on a sagex function. > > Okay, this sounds like a good task for me. I'd be very happy if you were to do this. Thanks! > I personally am not > comfortable with ad-hoc parsing, so I avoid it like the plague, but > I'll take a look at inspect and see what the 'officially sanctioned' > technique is. Keep in mind that as languages go, Python is very easy to parse. E.g., if f is a function definition: def f(x): blah It's really easy to know where the definition ends. > On an unrelated note, is there a reason that ?, ??, hg_sage.diff(), etc > use the pager as opposed to printing normally? Is this configurable? For ?, ?? this is an IPython question. I think for IPython this is determined by the environment variable PAGER. For hg, less is used except in the notebook. This should be changed (by changing part of misc/hg.py) to use the environment variable PAGER instead, and default to less. Feel free to send me a patch. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
On 12/13/06, William Stein <[EMAIL PROTECTED]> wrote: > > On an unrelated note, is there a reason that ?, ??, hg_sage.diff(), etc > > use the pager as opposed to printing normally? Is this configurable? > > For ?, ?? this is an IPython question. I think for IPython > this is determined by the environment variable PAGER. > For hg, less is used except in the notebook. This should be changed > (by changing part of misc/hg.py) to use the environment variable > PAGER instead, and default to less. Feel free to send me a patch. And IPython actually calls genutils.page(), which only invokes $PAGER if the text is too long to fit in a screen. This way, small printouts don't call out to the pager, but long ones do. Regards, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
William Stein wrote: > > > Does anybody on sage-devel want to volunteer to help with this > upgrading of linux distros on a virtual internal machine, when > it ever gets created? :-) > As I am retired, I do have time(?) and can do almost as much as I please. I could volonteer, but during the summer I'm out sailing with little or no access to the internet (laptop with cell phone). So ;-) Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
William Stein wrote: > On Wed, 13 Dec 2006 12:09:25 -0800, Nick Alexander <[EMAIL PROTECTED]> > wrote: > >> I am against enhancing the docstrings as you suggest. I think we should > >> write code to parse the original .pyx files, given the filename and line > >> number information. There is no extra overhead spacewise, and this fits > >> with how the rest of Python works better. Also, it is what I already > >> planned to do, but hadn't got to yet All I did was put something for > >> parsing out the source code -- try ?? on a sagex function. > > > > Okay, this sounds like a good task for me. > > I'd be very happy if you were to do this. Thanks! > > > I personally am not > > comfortable with ad-hoc parsing, so I avoid it like the plague, but > > I'll take a look at inspect and see what the 'officially sanctioned' > > technique is. > > Keep in mind that as languages go, Python is very easy to parse. > E.g., if f is a function definition: > > def f(x): > blah > > It's really easy to know where the definition ends. Parsers have this funny way of bit-rotting over time... I'll write tests :) BTW, inspect.py does not parse source code. All the information is stored at compile time (as you would expect -- the syntax tree is still live) and inspect.py just provides a nicer interface to query the stored information. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
> Let's not thrash the idea because it is difficult to implement! First lets > answer this Q: is there any value-addition to user-friendliness due to > this feature? IMO ... yes! What say? It's not difficult. It would be _impossible_ without rewriting the entire Python language. Go ahead, take a crack at it. Don't expect anybody else to apply the patch. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
On Wed, 13 Dec 2006 [EMAIL PROTECTED] wrote: > > Let's not thrash the idea because it is difficult to implement! First lets > > answer this Q: is there any value-addition to user-friendliness due to > > this feature? IMO ... yes! What say? > > It's not difficult. It would be _impossible_ without rewriting the > entire Python language. Go ahead, take a crack at it. Don't expect > anybody else to apply the patch. Hmmm, no workarounds, eh? That's encouraging ... reality happens! Would BDFL share his thoughts? Ifti. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
On Wed, 13 Dec 2006 12:26:26 -0800, Iftikhar Burhanuddin
<[EMAIL PROTECTED]> wrote:
>
>> > sage: SupersingularModule(11).
>> >
>> > Should this be legal? And should be implemented without actually
>> > creating
>> > the oject with *just* syntatic checking? What say folks?
>>
>> How on earth would one implement that? There's no guarantee that the
>
> We need to think about how to implement this carefully. And currently I
> cannot *think* as I'm mechanically grading student finals :)
>
> Let's not thrash the idea because it is difficult to implement! First
> lets
> answer this Q: is there any value-addition to user-friendliness due to
> this feature? IMO ... yes! What say?
(1) I'm against allowing 5.factor() to work.
(2) I'm against syntactic parsing to do tab completion. However,
I'm open to the possibility of having the tab complete function
work on any syntatically correct expression (for which eval works).
At least, I would consider
implementing it and trying it out before rejecting the idea out of hand.
In the notebook the relevant function is completions in
sage/server/support.py:
def completions(s, globs, format=False, width=90):
"""
Return a list of completions in the context of globs.
"""
Right now s is assumed to be an identifier (possibly with dots, e.g.,
foo or foo.bar.spam). But this is an easy assumption to get around.
E.g., if you replace the completions function by the function below, then
the following works:
sage: sage.server.support.completions('SupersingularModule(11)', globals())
['SupersingularModule(Integer(11)).Hom',
'SupersingularModule(Integer(11)).T',
'SupersingularModule(Integer(11)).ambient',
'SupersingularModule(Integer(11)).ambient_module',
'SupersingularModule(Integer(11)).anemic_hecke_algebra',
'SupersingularModule(Integer(11)).atkin_lehner_operator',
'SupersingularModule(Integer(11)).base',
...
Of course, tab completing on
SupersingularModule(11).hecke_operator()
would take a while... but one can always cancel it (in the SAGE notebook
at least).
More general version:
def completions(s, globs, format=False, width=90):
"""
Return a list of completions in the context of globs.
"""
n = len(s)
if n == 0:
return '(empty string)'
if not '.' in s and not '(' in s:
v = [x for x in globs.keys() if x[:n] == s]
else:
if not ')' in s:
i = s.rfind('.')
method = s[i+1:]
obj = s[:i]
n = len(method)
else:
obj = s
method = ''
try:
O = eval(obj, globs)
D = dir(O)
try:
D += O.trait_names()
except (AttributeError, TypeError):
pass
if method == '':
v = [obj + '.'+x for x in D if x and x[0] != '_']
else:
v = [obj + '.'+x for x in D if x[:n] == method]
except Exception, msg:
print msg
v = []
v = list(set(v)) # make uniq
v.sort()
if format:
if len(v) == 0:
return "no completions of %s"%s
else:
return tabulate(v, width)
return v
---
So I'm open to more flexible tab completion...
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
> (1) I'm against allowing 5.factor() to work. > (2) I'm against syntactic parsing to do tab completion. Please support your against-ness. Regards, Ifti. ps: > So I'm open to more flexible tab completion... It's good to have an open BDFL at the helm! --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
>> def f(x): >> blah >> >> It's really easy to know where the definition ends. > > Parsers have this funny way of bit-rotting over time... I'll write > tests :) Definitely! > BTW, inspect.py does not parse source code. All the information is > stored at compile time (as you would expect -- the syntax tree is still > live) and inspect.py just provides a nicer interface to query the > stored information. You could modify sagex to save the parse information at compile time. It parses .pyx files, then discards the results after using them to generate .c files. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 173.binary()?
On Wed, 13 Dec 2006 15:43:27 -0800, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote: > >> (1) I'm against allowing 5.factor() to work. > >> (2) I'm against syntactic parsing to do tab completion. > > Please support your against-ness. I think my against-ness has been very amply supported by other arguments in this thread. In summery, Python is dynamically typed, so it doesn't make sense to do tab completion based purely on parsing. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
William Stein wrote: > >> def f(x): > >> blah > >> > >> It's really easy to know where the definition ends. > > > > Parsers have this funny way of bit-rotting over time... I'll write > > tests :) > > Definitely! > > > BTW, inspect.py does not parse source code. All the information is > > stored at compile time (as you would expect -- the syntax tree is still > > live) and inspect.py just provides a nicer interface to query the > > stored information. > > You could modify sagex to save the parse information at compile time. > It parses .pyx files, then discards the results after using them > to generate .c files. I could, but if I'm not going to embed the results in docstrings I'd have to find them at run-time, and the hassles of doing that are probably worse than the hassles of parsing in the first place. On an unrelated note: how do I alter what ipython does for ? and ?? (this might be a question for Fernando Perez). We have code in server.support that duplicates what ipython does; we should factor that out and modify ipython to run our unified, sagex enhanced, version. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE -- filenames for pyrex code in ref?
On Wed, 13 Dec 2006 17:26:41 -0800, Nick Alexander <[EMAIL PROTECTED]> wrote: > I could, but if I'm not going to embed the results in docstrings I'd > have to find them at run-time, and the hassles of doing that are > probably worse than the hassles of parsing in the first place. You could pickle (as .pyxc files?) the data structures that sagex creates at runtime. > On an unrelated note: how do I alter what ipython does for ? and ?? > (this might be a question for Fernando Perez). We have code in > server.support that duplicates what ipython does; we should factor that > out and modify ipython to run our unified, sagex enhanced, version. See the end of misc/interpreter.py. It is already factored out -- when you do ? or ?? from Ipython, it just calls a SAGE version, which is the one for server support. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE development machines
William Stein wrote: > Hello, > > If you would like, you could help me make a precise list of SAGE > development machines that I should buy, by editing this wiki > page (or emailing me): > > http://sage.math.washington.edu:9001/hardware Just in case they are being considered, laptops are a bad idea. One reason is that they often have different performance characteristics to deskop machines. The second reason is that some laptops do not have hardware performance counters that their desktop siblings do have. This makes it hard to get accurate timings. I'm personally aiming to support machines of 500MHz or more with FLINT. But I wouldn't be disappointed if all the machines were very recent and at the high end of the performance curve. Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] sage-1.5.0.2
Hello, I've released sage-1.5.0.2. You should be able to "sage -upgrade" to it from previous versions of SAGE. Enjoy! william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
