Re: [sage-devel] Re: Tracebacks please!
On Thu, Oct 5, 2017 at 5:43 AM, Maarten Derickx wrote:
> I want to add to this that including both your operation system and sage
> version are also very useful in this respect (and sometimes even your
> processor type).
>
Couple quick tips:
1. IPython's `%xmode verbose` automatically gives extra detailed tracebacks
that are particularly useful for this:
In [25]: x=0
In [26]: y=1
In [27]: y/x
---
ZeroDivisionError Traceback (most recent call last)
in ()
> 1 y/x
ZeroDivisionError: division by zero
In [28]: %xmode verbose
Exception reporting mode: Verbose
In [29]: y/x
---
ZeroDivisionError Traceback (most recent call last)
in ()
> 1 y/x
global y = 1
global x = 0
ZeroDivisionError: division by zero
2. IPython's sys_info() prints system details:
In [20]: from IPython import sys_info
In [21]: print(sys_info())
{'commit_hash': '36ab971de',
'commit_source': 'repository',
'default_encoding': 'UTF-8',
'ipython_path': '/Users/fperez/dev/ipython/ipython/IPython',
'ipython_version': '6.2.0.dev',
'os_name': 'posix',
'platform': 'Darwin-16.7.0-x86_64-i386-64bit',
'sys_executable': '/Users/fperez/usr/conda/bin/python',
'sys_platform': 'darwin',
'sys_version': '3.6.2 |Anaconda, Inc.| (default, Oct 5 2017, 03:00:07) \n'
'[GCC 4.2.1 Compatible Clang 4.0.1
(tags/RELEASE_401/final)]'}
In fact, IPython's crash handler (its internal sys.excepthook) consists
more or less of a traceback made with verbose mode + the output of
sys_info, and it can be very handy.
Cheers,
f
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Abandon Python 2.6 support?
On Mon, Jun 13, 2016 at 3:16 PM, William Stein wrote: > This is only for our build system / bootstrapping scripts, not for sage > itself. Ah, I missed that part in the discussion... Sorry for the noise! -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Abandon Python 2.6 support?
On Mon, Jun 13, 2016 at 1:18 AM, Erik Bray wrote: > On Sat, Jun 11, 2016 at 4:28 PM, William Stein wrote: > > > > > > On Saturday, June 11, 2016, Volker Braun wrote: > >> > >> Note that we can trivially support Python 2.6 just by vendoring > >> argparse.py. Make user's lives easier or save a few kilobytes of disk > space? > >> How is this not a total slam-dunk?-- > > > > > > Huge +1 > > +1 here too. You folks obviously decide what's best for sage, but as a minor comment on this point, from our experience on IPython: it's a fair bit harder to make the transition to a python 2/3 compatible codebase while supporting 2.6 than if you only support 2.7. Lots of things from 3 were backported to 2.7 to minimize the gap between the two, but that wasn't the case with 2.6. It may be the right tradeoff for Sage, obviously, but at least you should be aware that keeping 2.6 is in a sense a vote for not moving in the direction of 3.x. Cheers -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] print to python3
On Tue, May 24, 2016 at 9:09 PM, William Stein wrote: > Thanks for your post! The assumption in this whole thread is that > Sage supports either python2 or python3, and not both. Thanks for > questioning this assumption and pointing out that "all the major > scientific python libraries are py2/3 compatible".This reminds me > again of this post [1] which is about sympy moving to be "python3 > only"... > > [1] https://news.ycombinator.com/item?id=11738470 > Yup, just to be clear, those libraries are *currently* py2/3 compatible, but indeed we have the plan you pointed to of gradually dropping py2. I should have been more explicit, the idea is: 1. Period of single-source py2/3 compatibility. This lets users move at their own pace. In the case of Sage, this could be restricted to just the parts of Sage that execute user code, you could move to py3 as a requirement for installation/development, for example, if that made sense. You just don't impose that on user code quite yet. Make it really easy to install either "kernel" for users, and encode that metadata in sage worksheets. 2. At some point, make a well-publicized, last release of this version that maintains the py2/3 option. 3. From then on, users can either start using the new py3 one or continue using py2 but they do lose new features. 4. Maintain, at least for a while, backporting of critical/security fixes to the py2 version, making only point releases. So this is not a "maintain py2 forever" plan, but rather "give users options for a gradual, staggered transition at their own pace, while giving the Sage dev team a path forward to start using py3 more and more". Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] print to python3
On Tue, May 24, 2016 at 1:56 PM, William Stein wrote: > We need a real strategy for migrating users to Python3, and definitely > not some half-way thing that deals only with the print statement. > Just lurking here, but that was precisely the thought that came to my mind. For reference, what we did in IPython (and I really mean the IPython kernel, not the notebook/Jupyter/etc) and that has ultimately worked very well (not that it wasn't a lot of effort in the first place): - Update the IPython kernel to run from a single source in python 2 or 3. - Provide users an easy way to install IPython as a python2 or python3 kernel for Jupyter. This decouples *our* development from the *user's* code. They can choose, when they each see fit, whether to run a python2 or a python3 stack. Since all the major scientific python libraries are py2/3 compatible, the choice is up to them. This means that, when they choose to update to py3, they pay the price as they need to, and they can pay that cost even piecemeal, moving one project over but not another. I suspect that flat out mandating a hard sage-py2 to sage-py3 transition at any given point in time will not work at all, it will cost sage users and will effectively freeze many of them in the sage-py2 version forever. Maintaining a py2/3 single-source codebase takes some extra work (and diligent testing on both platforms) but it's not impossible. I really think this is the only viable path for sage if you want to retain your user base and help them make the transition across the py2/3 divide. Cheers f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Deprecate the use of properties in all public API
On Thu, May 5, 2016 at 9:41 AM, Jason Grout wrote: > FYI, a relevant post just appeared on the ipython dev list: > https://mail.scipy.org/pipermail/ipython-dev/2016-May/017099.html > Indeed! I'm delighted by this, and as mentioned here ( https://mail.scipy.org/pipermail/ipython-dev/2016-May/017101.html), it should obviate the need for the greedy completer in many cases. Feedback from the sage community very much welcome, as always! ps - note that to get the feature, you need to install Jedi, as the dependency is conditional and the feature is only active if `import jedi` succeeds. So pip away at jedi if you'd like to test it. -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] [JOB] Project Jupyter is hiring two postdoctoral fellows @ UC Berkeley
Hi all, We are delighted to announce today that Project Jupyter/IPython has two postdoctoral fellowships open at UC Berkeley, open immediately. Interested candidates can apply here: https://aprecruit.berkeley.edu/apply/JPF00899 We hope to find candidates who will work on a number of challenging questions over the next few years, as described in our grant proposal here: http://blog.jupyter.org/2015/07/07/project-jupyter-computational-narratives-as-the-engine-of-collaborative-data-science/ Interested candidates should carefully read that proposal before applying to familiarize themselves with the full scope of the questions we intend to tackle. We'd like to thank the support of the Helmsley Trust, the Gordon and Betty Moore Foundation and the Alfred P. Sloan Foundation. Cheers, Brian Granger and Fernando Perez. -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Announcing $0M in new funding for the SageMathCloud over the next 3 years
On Wed, Jul 8, 2015 at 10:17 AM, William Stein wrote: > Anyway, for me personally and SageMathCloud development, and also > support of Sage development at UW, this is a major blow. > All I can say is that I'm very bummed to hear this... I always admired your success in securing resources for Sage (with a bit of envy :) when I wasn't able to do so for IPython, and I only wish that today we could have resources for *both*. I tried to learn a lot from watching everything you did with looking for resources for Sage, and FWIW, I also haven't had great luck with the federal agencies. My only success with the NSF has been with stuff that's only tangentially related to ipython/scipy, whereas grants where i went "head first" into the software (even solicitations that were "software infrastructure" didn't fare so well). This is a cautionary note that, even though IPython and ODK are doing OK right now, the next cycle may well look very different for us too... Grant funding is a fickle business, which is why I continue wishing SMC sustained commercial success, so that it can have actual *revenue* to invest in Sage itself for the long haul. The question of how to fund our work in a sustainable fashion for the really long haul, as our teams get larger (and thus more expensive) keeps me up at night... All I can say at this point is that I hope the work we'll do on Jupyter, and indirectly with our colleagues at ODK (we'll have some of the Jupyter folks there too) will continue providing benefits to Sage! Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] sage and jupyterhub for classroom teaching
On Thu, Apr 2, 2015 at 3:11 PM, William Stein wrote: > The feeling is very mutual. My dream would be that SMI = (SageMath, > Inc.) is very successful and can be one of JH's industry partners, and > that SMI can financially (and otherwise) help to support JH > development. > That would be awesome, and in the meantime, we do hope that everything we're doing on JH can be of use to SMC. Cheers f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] sage and jupyterhub for classroom teaching
On Wed, Apr 1, 2015 at 9:54 PM, William Stein wrote: > If somebody from JH decides to explain how every point above is > slightly wrong, that would be nice, since I can't imagine that they > aren't wrong! > Actually, I don't see any major errors in there :) Just to add some detail, the basic design of JH is: out of the box, assume: 1. local Unix auth (PAM) 2. for each authenticated user, you start their notebook as a local subprocess. That makes it very easy to run it in your typical 'university research group' environment, where there's some NFS server under a desk a beefy shared unix box where the group members all SSH in. But both #1 and #2 above are separately customizable. What Jess did was to replace #1 with Github auth, and #2 with a fairly sophisticated Docker setup (she ended up contributing fixes to Docker Swarm just as it was released). With said customizations, the same basic architecture should be usable in some other scenarios, just as Jess has demonstrated. JH doesn't have out of the box any of the many sophisticated features that SMC has, nor is most of that stuff on our roadmap. Lots of what William has done there is needed to provide a robust, 24/7 service with (hopefully :) paying customers, and we're not doing any of that. I do hope that SMC will be very successful, and we do talk to William every time we have a chance to share ideas, brainstorm, etc. Cheers f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: ipython notebook
Yup, we're a little behind... :) Trying to get 3.0 out before the end of the year. The JupyterHub tool is more admin-oriented, so we don't have a release date for it yet: people are using it for now straight out of github, and until we feel that we have an API and model we really like, it will likely continue that way. On Thu, Oct 23, 2014 at 3:09 PM, Volker Braun wrote: > Is the first release out yet? In August you said it would > be October/November... > > > > On Thursday, October 23, 2014 11:02:29 PM UTC+1, Fernando Perez wrote: >> >> >> On Thu, Oct 23, 2014 at 5:53 AM, Volker Braun wrote: >> >>> Currently it is single user only. >> >> >> the multiuser support is a separate project that wraps the single user >> component: >> >> https://github.com/jupyter/jupyterhub >> >> Single-user application and multiuser authentication/management are not >> bundled into one tool as they are in Sage. >> >> Cheers >> >> f >> >> >> -- >> Fernando Perez (@fperez_org; http://fperez.org) >> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) >> fernando.perez-at-berkeley: contact me here for any direct mail >> > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: ipython notebook
On Thu, Oct 23, 2014 at 5:53 AM, Volker Braun wrote: > Currently it is single user only. the multiuser support is a separate project that wraps the single user component: https://github.com/jupyter/jupyterhub Single-user application and multiuser authentication/management are not bundled into one tool as they are in Sage. Cheers f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: speed regression testing
On Sun, Aug 31, 2014 at 3:16 PM, Volker Braun wrote: > You misunderstood, we are not going to distribute Sage linked to MKL. This > is obviously not legal to distribute. But it should be possible for you to > compile Sage with alternate BLAS implementations on your own machine if you > chose to. > Ah, sorry for the confusion. In fact, we *did* want to distribute numpy binaries linked against the MKL, but on close inspection of the license, we realized that wouldn't be possible. That page I linked to on the numpy wiki lists a bunch of information about the (sad) state of building and distributing numerical software on Windows, that may be useful as a reference for Sage as well... Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: speed regression testing
On Fri, Aug 29, 2014 at 3:24 AM, Volker Braun wrote: > I do have a MKL license (Linux + OSX) for the Sage project Who is going to assume the indemnification liability on behalf of Sage if MKL-linked binaries are distributed? And even if someone does, it will require some form of license modification to prevent reverse-engineering, so this would probably have to be a 'special edition, non-GPL' version of Sage. I haven't the foggiest idea if that's even kosher with the GPL, but I suspect not. As per the MKL terms: https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows#blas--lapack-libraries Those terms stopped us dead in our tracks when we looked at shipping numpy binaries linked against MKL. With the MKL, the cost of the license is the least of the issues. Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Crazy/dumb idea about Sage on Windows...
On Fri, Aug 22, 2014 at 4:42 AM, Volker Braun wrote: > That is not so unlike the current VM which runs the sage notebook web > server. You can then connect to it with the host browser, if you want (it > does pop up a browser inside the VM because 1. why not and 2. firewall > issues). Yup, I know that's how it currently works. But with this proposal: - a headless VM is less 'alien' to user. T\(they can use their familiar browser, extensions, etc, and they don't have to see a new desktop. The whole 'destkop in a desktop' can be confusing to new users. - it's also far lighter in resources. Much smaller disk image, memory footprint and runtime overhead, since you only deploy a tiny container instead of a full-blown desktop envrionment. - users see their normal filesystem and tools, and they can install and manage the non-sage parts of the runtime with tools that work well on Windows like Anaconda or Enthought Canopy (or even do a manual install if they so desire, the dependencies are all easily pip-able). As I said, just an idea for you guys to consider, since I know that a good Windows experience is still an elusive goal. Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Crazy/dumb idea about Sage on Windows...
Hi folks, off the cuff, probably totally dumb. Reading some of the threads about Sage, Julia, Windows, etc, got me thinking... If/when there's a Sage kernel for the IPython/Jupyter notebook, I wonder if that could give you guys a way to move forward on Windows, where I know you've fought pretty hard and bitter battles... My idea (assuming the aforementioned kernel): package *just* the Sage kernel inside a VM, and run it purely as a service, but connect to it from an IPython terminal, Qt console or Notebook running from a native Anaconda installation. Because our execution model decouples the kernel from the filesystem, the user gets their 'normal' environment, files, etc, and they don't really need to know anything about the VM to get to their work, their directories, etc. I know IPython provides a very different execution model to the Sage NB (no hidden directories, it lives on the normal filesystem, etc), so 'native' Sage notebooks won't work. But ipynbs will work fine, and this may at least give you guys a better way to reach a Windows audience... And since this VM would be running only the bare kernels, it can be a very small and lightweight one, and it should be a lot easier to deal with ports and firewall issues. There will be zeromq traffic on some sockets, but that's it. Just an idea... Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] On scientific computing, Python and Julia
On Sun, Jul 20, 2014 at 8:43 PM, Stefan Karpinski wrote: > Yes, you can definitely do most of this with template metaprogramming, > although, as you say it's pretty tricky. Some people, when confronted with a problem, think "I know, I'll use template metaprogramming." Now they have a type-parametric problem factory... Sorry, couldn't resist ;) Too many memories of C++ template error messages... Awesome discussion, BTW! Thanks Stefan for the careful explanations, much appreciated. -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Congratulations to IPython
On Sun, Mar 24, 2013 at 2:25 AM, David Roe wrote: > IPython has won the 2012 Free Software foundation award for the Advancement > of Free Software > (http://www.fsf.org/news/2012-free-software-award-winners-announced-2). > Well deserved! Thanks, David! I should add, though, that supposedly the award was not just for IPython, but for the broader scientific Python ecosystem, and I think of Sage as one part of that ecosystem. IPython's value (like all libraries and tools that aren't an end in and of themselves for most of their users) lies in what people can do with it. In as much as Sage has benefited from IPython, then it's also one of the elements behind this award. I know that our interactions with the Sage team, both in terms of ideas and of resources/meetings (William has funded IPython devs to travel to several sprints), has been enormously beneficial to IPython. Cheers, f -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Access to SPARC 64
Hi Ondrej, On Thu, Nov 15, 2012 at 8:42 AM, Dima Pasechnik wrote: > There are such machines on skynet, e.g. mark. > -bash-3.00$ uname -a > SunOS mark 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500 > -bash-3.00$ isainfo -b > 64 skynet may be a good solution, I figured I'd just also mention the GCC compile farm as an option too: http://gcc.gnu.org/wiki/CompileFarm >From their description, numpy qualifies for access and they have a very wide array of hardware/OS combinations. But I've never used it myself, so I don't know if in practice it's a good solution or not. Cheers, f -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] [ANN] John Hunter has been awarded the first Distinguished Service Award by the PSF
Hi folks, you may have already seen this, but in case you haven't, I'm thrilled to share that the Python Software Foundation has just created its newest and highest distinction, the Distinguished Service Award, and has chosen John as its first recipient: http://pyfound.blogspot.com/2012/09/announcing-2012-distinctive-service.html This is a fitting tribute to his many contributions. Cheers, f -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] A sad day for our community. John Hunter: 1968-2012.
Dear friends and colleagues, I am terribly saddened to report that yesterday, August 28 2012 at 10am, John D. Hunter died from complications arising from cancer treatment at the University of Chicago hospital, after a brief but intense battle with this terrible illness. John is survived by his wife Miriam, his three daughters Rahel, Ava and Clara, his sisters Layne and Mary, and his mother Sarah. Note: If you decide not to read any further (I know this is a long message), please go to this page for some important information about how you can thank John for everything he gave in a decade of generous contributions to the Python and scientific communities: http://numfocus.org/johnhunter. Just a few weeks ago, John delivered his keynote address at the SciPy 2012 conference in Austin centered around the evolution of matplotlib: http://www.youtube.com/watch?v=e3lTby5RI54 but tragically, shortly after his return home he was diagnosed with advanced colon cancer. This diagnosis was a terrible discovery to us all, but John took it with his usual combination of calm and resolve, and initiated treatment procedures. Unfortunately, the first round of chemotherapy treatments led to severe complications that sent him to the intensive care unit, and despite the best efforts of the University of Chicago medical center staff, he never fully recovered from these. Yesterday morning, he died peacefully at the hospital with his loved ones at his bedside. John fought with grace and courage, enduring every necessary procedure with a smile on his face and a kind word for all of his caretakers and becoming a loved patient of the many teams that ended up involved with his case. This was no surprise for those of us who knew him, but he clearly left a deep and lasting mark even amongst staff hardened by the rigors of oncology floors and intensive care units. I don't need to explain to this community the impact of John's work, but allow me to briefly recap, in case this is read by some who don't know the whole story. In 2002, John was a postdoc at the University of Chicago hospital working on the analysis of epilepsy seizure data in children. Frustrated with the state of the existing proprietary solutions for this class of problems, he started using Python for his work, back when the scientific Python ecosystem was much, much smaller than it is today and this could have been seen as a crazy risk. Furthermore, he found that there were many half-baked solutions for data visualization in Python at the time, but none that truly met his needs. Undeterred, he went on to create matplotlib (http://matplotlib.org) and thus overcome one of the key obstacles for Python to become the best solution for open source scientific and technical computing. Matplotlib is both an amazing technical achievement and a shining example of open source community building, as John not only created its backbone but also fostered the development of a very strong development team, ensuring that the talent of many others could also contribute to this project. The value and importance of this are now painfully clear: despite having lost John, matplotlib continues to thrive thanks to the leadership of Michael Droetboom, the support of Perry Greenfield at the Hubble Telescope Science Institute, and the daily work of the rest of the team. I want to thank Perry and Michael for putting their resources and talent once more behind matplotlib, securing the future of the project. It is difficult to overstate the value and importance of matplotlib, and therefore of John's contributions (which do not end in matplotlib, by the way; but a biography will have to wait for another day...). Python has become a major force in the technical and scientific computing world, leading the open source offers and challenging expensive proprietary platforms with large teams and millions of dollars of resources behind them. But this would be impossible without a solid data visualization tool that would allow both ad-hoc data exploration and the production of complex, fine-tuned figures for papers, reports or websites. John had the vision to make matplotlib easy to use, but powerful and flexible enough to work in graphical user interfaces and as a server-side library, enabling a myriad use cases beyond his personal needs. This means that now, matplotlib powers everything from plots in dissertations and journal articles to custom data analysis projects and websites. And despite having left his academic career a few years ago for a job in industry, he remained engaged enough that as of today, he is still the top committer to matplotlib; this is the git shortlog of those with more than 1000 commits to the project: 2145 John Hunter 2130 Michael Droettboom 1060 Eric Firing All of this was done by a man who had three children to raise and who still always found the time to help those on the mailing lists, solve difficult technical problems in matplotlib, teach courses
Re: [sage-devel] Re: sage release plan
On Fri, Jun 29, 2012 at 2:37 PM, Jason Grout wrote: > No, that wouldn't work. For one, the BSD license says: > > Redistributions of source code must retain the above copyright notice, this > list of conditions and the following disclaimer. > > So you can't just delete the BSD header and replace it with GPL. But maybe > we're talking past each other. Yup, that's right. > Anyways, we're nitpicking at details here. IPython isn't going to change to > GPL, which is just fine with me. Indeed, we're not. And again, I wasn't trying in any way to push sagenb to change either: I only expressed a 'peanut gallery +1' as commentary to William's post. If the sagenb doesn't want to or can't for whatever reason switch to BSD, that's completely OK too and I'll be the last to bug you about it. BSD works well for the 'scipy ecosystem', that's all. Cheers, f -- 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 release plan
On Fri, Jun 29, 2012 at 11:46 AM, Jan Groenewald wrote: > Would this symmetric flow not also be possible if ipython relicensed to GPL? > Honest question. Certainly, but that's not in the cards. All the 'scipy ecosytem' (python, numpy, scipy, matplotlib, ipython, pandas, statsmodels, scikit-learn, scikits-image, pytables, networkx, cython, etc) is BSD licensed and there's no intention of changing that. Besides at this point even if I wanted (which I don't) to change it I couldn't, as there are by now way too many ipython contributors who made their contributions to the project as BSD. It would be likely impossible to get them to agree to a GPL relicensing. Note that I'm not *pushing* for you guys to change anything, I just gave my '+1' to William's comment, in light of the recent upswing in collaboration we've had with Jason G. Obviously it's perfectly fine if Sagenb remains GPL, and it will always be able to continue using ipython, numpy, etc as it always has. As I said, I just pinged because William brought it up. Cheers, f -- 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 release plan
Minor note from the peanut gallery: On Wed, Jun 27, 2012 at 10:46 AM, William Stein wrote: > We should just relicense the sage notebook as BSD to completely > eliminate this problem speaking from the IPython side, this would be great for us. We're starting to have real collaboration between ipython and sagenb (again, thanks largely to J. Grout's outstanding cross-project bridge building work, e.g. https://github.com/ipython/ipython/pull/2051). But obviously it would be much better from our perspective if code could flow both ways creating a real symmetric, collaborative relationship. Right now our code can happily go into sagenb as needed, but not the other way around (you guys have been great at relicensing specific snippets when asked, but that's not really a viable solution for everyday ongoing work). Cheers, f -- 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] And the 2012 Spies Sage Development Prize Winner is...
On Mon, Jun 18, 2012 at 9:32 PM, William Stein wrote: > ... Jason Grout! Congratulations!!! And I'd like to add, in addition to the many merits listed in the award notice, Jason is remarkably active not only in working on numpy/scipy integration for Sage, but also in bridging the sage and scipy communities: he regularly participates in threads on the numpy, scipy, matplotlib and ipython development lists, and helps the two communities find further points for contact and collaboration. I have no idea how he manages to do it, given his already broad and deep commitment to sage itself, but I'm glad he does! f -- 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: Article of interest: A Multi-Language Computing Environment for Literate Programming and Reproducible Research
On Tue, Jun 5, 2012 at 7:44 PM, Jason Grout wrote: > To be fair, though the notebook allows for code and documentation to be > intermixed, it's not the traditional literate programming tool that allows > you to, on the one hand, produce nice documentation, but on the other hand, > produce a single runnable file. And it's a far cry from something like > noweb, that can reorder your code when it "tangles". > > The ipython notebook is closer to this, since you guys explicitly export to > a python file, and also export (or will export) other formats that nicely > present everything. And to me that's very deliberate. I've never really liked 'real' literate programming in that the very concept of it is completely batch oriented: you write code and text in one place, then you run it via something that produces a program to be then executed. Even though the results look often excellent, my preferences are firmly set on the mathematica/ipython/sage/etc approach that keeps you working *inside* the environment where you *execute* the code. I want to have my objects in memory while I play with them, refining each cell as I go and gradually molding the code into what I need as I both refine the code and understand the problem better based on the results. It's possible that some of the newer literate programming environments from the R people have changed in this regard, I have to admit I haven't followed that world very closely. But the classic sweave approach is most definitely *not* my cup of tea, and not something we're trying to emulate in any way in IPython. We do make it possible to produce importable code automatically from a notebook (and have ideas on how to improve that further), and our latex, rst, html, etc conversion machinery slowly but surely is improving, so I'm not saying that we have something that we consider finished and ready. But I do have a pretty clear vision of the kind of computational environment we're trying to create (and one where the parallel extensions fit very naturally in a way that I don't find in these other models and which I think is increasingly important). cheers, f -- 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] Article of interest: A Multi-Language Computing Environment for Literate Programming and Reproducible Research
Hi John, thanks for the pointer, useful reference to have. It bugs me that Sage not listed on page 6 in the table of existing tools. It covers much of the same ground... (so does the ipython notebook, but that didn't exist when this was written; but Sage most certainly did). Cheers, f -- 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 (tm)
On Sat, Jun 2, 2012 at 9:43 AM, Robert Bradshaw wrote: > It's also much > better to make it official now, when ownership is not being > questioned, than at some later date when it is needed. Take that lesson from us, it's indeed *much* better, I can guarantee you. Cheers, f -- 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 (tm)
Thu, May 31, 2012 at 8:06 AM, William Stein wrote: > As Sage grows, we may have to face more and more crap like [1] and > possibly attacks from others, which might force us to completely > change the name of our project to have nothing to do with "sage", > which would wreak havoc on google searches, etc. To stop this before > it is too late, I talked with a patent/trademark attorney at > University of Washington yesterday. I just wanted to say that you should do this, and soon: a few months ago I ended up involved in a trademark dispute over the name 'ipython' because someone decided to make an iOS app with that name (that had nothing to do with the 'real' ipython). We ended up getting support from the Python Software Foundation who intervened to resolve it, as well as numfocus.org that covered the legal fees involved, and it all turned out OK, but it was a huge hassle, an aggravation and ultimately a waste of time I'd much rather have spent coding. So this is *not* just hypotheticals, and the sooner you get an ironclad trademark registration for Sage, the better. Having that written by good IP lawyers (such as the ones UW has, I'm sure) is important. I know you were already moving forward, I just wanted to provide you with a bit of context in case anyone had doubts this was a real problem. Cheers, f -- 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] [ANN] PyData workshop videos are up online, including panel with Guido
Hi all, just to let you know that the videos from the PyData workshop we held at Google a couple of weeks ago are now online (not all talks are up yet, so watch the page over the next few days if a talk you wanted to see isn't posted yet): http://marakana.com/s/2012_pydata_workshop,1090/index.html The panel discussion with Guido that we talked about on these lists is in there; I hope to write up a short summary about it soon. Many thanks to Simeon Franklin and the rest of the Marakana team for doing all this work (for free)! Cheers, f -- 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] python3
On Sat, Mar 10, 2012 at 7:56 AM, William Stein wrote: > > Interesting examples: > > * Matplotlib doesn't support Python 3.x at all yet. The released version of mpl doesn't, but all the py3 branch has already been merged into git master. I haven't used it extensively, but in light testing with python3, it seemed to work just fine for all simple examples I tried. The plan is to make the next release soon-ish, though I haven't followed closely the latest details of the schedule. Cheers, f -- 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: git and gerrit
On Fri, Mar 2, 2012 at 1:06 AM, Robert Bradshaw wrote: > Though for a single commit, a rebase is cleaner IMHO than a merge, and > squashing commits improves the signal-to-noise ratio of the history > (and it's nice to be able to squash away stuff like typos). That was my original position, but I recently changed my mind after discussions with Min Ragan-Kelley and Aaron Smeurer (sympy lead). The main reason (in addition to Keshav's valid arguments) was to have the merge commit serve as an indicator of the fact that there was review, and who did the review, straight into the log. Seen in that way, the merge commit is signal, not noise. More details behind my reasoning here: http://mail.scipy.org/pipermail/ipython-dev/2012-January/008630.html We've made the change and we're all quite happy with the new approach. Cheers, f -- 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: Group collaboration on a branch of Sage
On Thu, Mar 1, 2012 at 8:18 AM, Keshav Kini wrote: > Also, besides your posts I was also remembering something you said to > William (and everyone else) at Sage Days 29 last year about how you could > vouch for github working well for IPython, if William wanted a testimonial > about it. Oh certainly, and my posts here are sort of that testimonial. Best, f -- 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: Group collaboration on a branch of Sage
On Thu, Mar 1, 2012 at 8:18 AM, Keshav Kini wrote: > I didn't mean to imply you were suggesting we move to github at all. I meant > that you were suggesting we *consider* moving to github, based on your own > experience. Is that still wrong? No, that's certainly correct. Given our positive experiences with it, both in ipython and the other scientific python projects, I think it deserves consideration for sage. I just wanted to make sure it was clear that I'm not trying to push you guys in any particular direction. Not that I would succeed anyway ;) But by all means, if there's anything from our experience so far that can help sage make these decisions, ask away and I'll do my best to provide relevant info. best, f -- 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: Group collaboration on a branch of Sage
On Thu, Mar 1, 2012 at 6:20 AM, Keshav Kini wrote: > IPython is also on github, > and Fernando has strongly recommended we consider moving Sage to github > (and has been doing so for at least 8 months, as far as I can recall). If that's how you understood my posts, I wasn't clear enough then. I've told the sage team about how *our* experience in ipython with git/github has been on the net extremely positive, despite some real drawbacks (chiefly their sub-par bug tracker). Our development pace has greatly accelerated and I'm convinced the fluidity of the github workflow has been a factor there (though certainly not the only one, since not every project that moves to github automatically picks up speed). But I have never said "sage should move to git/github", because I don't actually know the sage development process well enough to meaningfully make such a statement. I know sage uses patches, there's the management of SPKG files, and an elaborate workflow that has evolved over the years. I have no clue if any or all of this would map well or not to git/github. That is a decision that only you guys can make, and it would be foolish for me to propose or try to push you in any particular direction. Besides, I should add that I have no stake whatsoever in whether Sage moves to git, github, bitbucket or anything else: I'm not affiliated with any of those organizations other than by having an account with them and liking github for my projects. If one of them helps Sage get better, I'll be happy; if a self-hosted solution is better for Sage, then so be it. I have no horse in this race, really. Cheers, f -- 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: git and gerrit
On Tue, Feb 21, 2012 at 11:39 AM, Jason Grout wrote: > > Interesting. Where is this assignee field? Is it the assignee field in the > Issues? Does setting that require that the committer be the assignee? It's in the gray bar below the title for the PR. Anyone in the team who owns the target repo can be assignee, it's a drop-list that shows all the committers to the target repo. Cheers, f -- 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: git and gerrit
On Tue, Feb 21, 2012 at 12:32 PM, Robert Bradshaw wrote: > >> No, you can keep pushing to the branch you created the PR from, and >> new commits show up as they are made. You can even rebase and force >> push, and the PR will get rebased too. We do the first all the time, >> and the second also, though less frequently. > > What happens to (inline) comments in this case? I think they get preserved as static snippets in the discussion page, but I'm not 100% sure. I know we have PRs that have gone through this, but I wouldn't know how to find one right now to verify; if you're really curious we could do a quick experiment with a fake PR to test what happens, it would not take long. Cheers, f -- 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: git and gerrit
On Tue, Feb 21, 2012 at 11:03 AM, Christopher Swenson wrote: > My only possible issue with the github workflow: I'm not sure how it > interacts with having multiple people who have control of the "master" > (central) repo. When a pull request comes in, can anyone who has push access > to the repo take control of that pull request? Yes. Typically one or more core committers participate in the discussion, and it's easy to informally choose who does the final merge. But if you want to be more formal about it, there's an assignee field and a project can choose to use it explicitly and require that person to be the one who does the actual final merge. > Also, in my vastly finite experience with github, I've had problems with the > fact that pull requests seem to be immutable: once a request has been > created, it doesn't seem to be easy to add more commits to it, or change the > commits. (This may just be my naïvety.) No, you can keep pushing to the branch you created the PR from, and new commits show up as they are made. You can even rebase and force push, and the PR will get rebased too. We do the first all the time, and the second also, though less frequently. Cheers, f -- 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: git and gerrit
On Tue, Feb 21, 2012 at 7:38 AM, Jason Grout wrote: > I'll have to think more about whether I agree with the "each commit should > stand on its own" philosophy mentioned below. It certainly makes bisection > easier. But sometimes huge patches make me think that each *branch* should > stand on its own, and be merged with no fast-forward. Then it's much easier > to tease apart logically separate, but interrelated, sets of changes. Many thanks for this super useful discussion! From my own experience with github's branch-based review model, I lean strongly towards the view you summarize above. I prefer to let authors make very liberal use of the commit abilities in git and review with the branch as the 'atomic unit' I worry about, giving only secondary consideration to individual commits. Obviously if the commit history is a complete mess we may require that it gets rebased and cleaned up, but in general we tend to be relatively lax with how the individual commits stack up, as long as the entire branch diff is sensible and easy to analyze on its own. >From our own experience in ipython with github and how unbelievably fluid this has made the process both for new contributors and for reviewers, I think I really prefer this over the view that gerrit seems to propose. But it's been very enlightening to read their rationale, and I certainly see it as a coherent perspective one can choose to adopt. Cheers, f -- 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] Discussion with Guido van Rossum and (hopefully) core python-dev on scientific Python and Python3
Hi folks, [ I'm broadcasting this widely for maximum reach, but I'd appreciate it if replies can be kept to the *numpy* list, which is sort of the 'base' list for scientific/numerical work. It will make it much easier to organize a coherent set of notes later on. Apology if you're subscribed to all and get it 10 times. ] As part of the PyData workshop (http://pydataworkshop.eventbrite.com) to be held March 2 and 3 at the Mountain View Google offices, we have scheduled a session for an open discussion with Guido van Rossum and hopefully as many core python-dev members who can make it. We wanted to seize the combined opportunity of the PyData workshop bringing a number of 'scipy people' to Google with the timeline for Python 3.3, the first release after the Python language moratorium, being within sight: http://www.python.org/dev/peps/pep-0398. While a number of scientific Python packages are already available for Python 3 (either in released form or in their master git branches), it's fair to say that there hasn't been a major transition of the scientific community to Python3. Since there is no more development being done on the Python2 series, eventually we will all want to find ways to make this transition, and we think that this is an excellent time to engage the core python development team and consider ideas that would make Python3 generally a more appealing language for scientific work. Guido has made it clear that he doesn't speak for the day-to-day development of Python anymore, so we all should be aware that any ideas that come out of this panel will still need to be discussed with python-dev itself via standard mechanisms before anything is implemented. Nonetheless, the opportunity for a solid face-to-face dialog for brainstorming was too good to pass up. The purpose of this email is then to solicit, from all of our community, ideas for this discussion. In a week or so we'll need to summarize the main points brought up here and make a more concrete agenda out of it; I will also post a summary of the meeting afterwards here. Anything is a valid topic, some points just to get the conversation started: - Extra operators/PEP 225. Here's a summary from the last time we went over this, years ago at Scipy 2008: http://mail.scipy.org/pipermail/numpy-discussion/2008-October/038234.html, and the current status of the document we wrote about it is here: file:///home/fperez/www/site/_build/html/py4science/numpy-pep225/numpy-pep225.html. - Improved syntax/support for rationals or decimal literals? While Python now has both decimals (http://docs.python.org/library/decimal.html) and rationals (http://docs.python.org/library/fractions.html), they're quite clunky to use because they require full constructor calls. Guido has mentioned in previous discussions toying with ideas about support for different kinds of numeric literals... - Using the numpy docstring standard python-wide, and thus having python improve the pathetic state of the stdlib's docstrings? This is an area where our community is light years ahead of the standard library, but we'd all benefit from Python itself improving on this front. I'm toying with the idea of giving a lighting talk at PyConn about this, comparing the great, robust culture and tools of good docstrings across the Scipy ecosystem with the sad, sad state of docstrings in the stdlib. It might spur some movement on that front from the stdlib authors, esp. if the core python-dev team realizes the value and benefit it can bring (at relatively low cost, given how most of the information does exist, it's just in the wrong places). But more importantly for us, if there was truly a universal standard for high-quality docstrings across Python projects, building good documentation/help machinery would be a lot easier, as we'd know what to expect and search for (such as rendering them nicely in the ipython notebook, providing high-quality cross-project help search, etc). - Literal syntax for arrays? Sage has been floating a discussion about a literal matrix syntax (https://groups.google.com/forum/#!topic/sage-devel/mzwepqZBHnA). For something like this to go into python in any meaningful way there would have to be core multidimensional arrays in the language, but perhaps it's time to think about a piece of the numpy array itself into Python? This is one of the more 'out there' ideas, but after all, that's the point of a discussion like this, especially considering we'll have both Travis and Guido in one room. - Other syntactic sugar? Sage has "a..b" <=> range(a, b+1), which I actually think is both nice and useful... There's also the question of allowing "a:b:c" notation outside of [], which has come up a few times in conversation over the last few years. Others? - The packaging quagmire? This continues to be a problem, though python3 does have new improvements to distutils. I'm not really up to speed on the situation, to be frank. If we want to bring this up, s
Re: [sage-devel] Re: xcode and gcc
On Fri, Jan 27, 2012 at 12:55 AM, Jason Grout wrote: > https://github.com/kennethreitz/osx-gcc-installer is one possible place to > look for gcc, at least. Nice, thanks! I didn't know about that, it's excellent and does help a lot. Cheers, f -- 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: xcode and gcc
On Thu, Jan 26, 2012 at 1:33 PM, William Stein wrote: > Also, we could have a dmg available that would install GCC (including > gfortran) somewhere, and could be used to build Sage on OS X. +big_number Even outside the context of Sage, when teaching purely 'scipy stack' to students (many of whom have macs in US academia) it's really frustrating to hit that stupid Xcode hurdle just so I can show them how Cython works (or weave a little while back). Just last wekend I was answering questions precisely on this for our python bootcamp at Berkeley (http://register.pythonbootcamp.info), we ended up disabling all weave/cython stuff because we were going to drown in installation hassles (we had ~150 people). If you guys can put out a gcc/gfortran installer for the Mac that's a simple download, click, install, you'll benefit lots of people even beyond Sage. Back to the peanut gallery... f -- 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: Literal matrix syntax
On Thu, Jan 26, 2012 at 12:19 PM, Jason Grout wrote: > I waffle between Yes, and Yes with convincing. I'm trying it out now to see > how I feel about it. I feel like we shouldn't extend python too much, but > this syntax is very tempting. > BTW, at the upcoming pydata workshop: http://pydataworkshop.eventbrite.com/ I'm organizing a panel discussion with Guido and other core developers precisely to discuss possible improvements to the language that would benefit scientific users. I haven't put any formal announcement yet (will try to do so in the next couple of days), but if any of you will be near the Mountain View googleplex on Friday March 2, keep this in mind. Once I put out a formal announcement we'll set up a signup list for people to attend. I hope that in that panel we'll be able to discuss issues such as this one (I also would like python to expose native division into the rationals à la Sage, so that the main *semantic* difference between sage and python could be removed). Cheers, f -- 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: Questions about the single-cell server
On Wed, Dec 14, 2011 at 5:59 PM, Dan Drake wrote: > That's interesting. I wonder if the kernel bit could be used in SageTeX, > where I have a bunch of Sage commands and want to get their outputs. > Perhaps this could make that process much simpler and more extensible. Sure, in the end an ipython kernel is really nothing more than a Python 'exec' call waiting for you to send it things to run, and sending you answers back over the wire using zeromq. So if you load up that kernel with the necessary sage bits (prefiltering and the library imports), then you can send it blocks of sage code and it will send you back the answers. > Is there anything like this in the IPython docs? I looked around and > didn't find much. But I'll keep looking. I don't think we've taken the time to nicely document how to do this; the best 'explanation' may be to follow Paul Ivanov's vim integration: https://github.com/ivanov/vim-ipython This is included with ipython (we just re-merged it yesterday for updates) but is a good example of a 'non-traditional' client. In this case the client is not a normal console (be it terminal-, web- or qt-based ) but instead an instance of the Vim editor that sends code from the user to the kernel, and uses the kernel to do things like smart code completion (based on real introspection of live objects, not on static code analysis). That might be a good example to follow, don't hesitate to ask on the ipython-dev mailing list if something doesn't work or doesn't make sense. Best, f -- 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: Questions about the single-cell server
On Wed, Dec 14, 2011 at 12:43 PM, Jason Grout wrote: > Feel free to CC this message over to the ipython list if you want to take up > the discussion there. Will do that. Cheers, f -- 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: Questions about the single-cell server
On Wed, Dec 14, 2011 at 11:37 AM, Jason Grout wrote: > That sounds like a great idea. One of the last things we wanted to do > before releasing the big 1.0 version is to write more tests and > documentation about the protocol. Things have been on hold for the last > little while (school has been busy), but with the end of the semester, I > hope that we can finish things up over the holiday break. > > We tried to follow pretty closely the ipython messaging spec (or a subset of > it, anyway, with a few of our own extensions like session_end). The ipython > messaging spec is here: > http://ipython.org/ipython-doc/dev/development/messaging.html > > The hope is that when we switch to ipython 0.12, a lot of the work we are > doing manually now will be automatic for us, and our front ends will still > just work. Ideally, we could have such a test suite be reusable across implementations, so that we can stick it into ipython itself. Having the test suite live inside ipython will ensure that over time, we don't accidentally drift from the spec in ways that could break downstream users. At this point we have a spec in the document you pointed to, but precious little in the way of independent compliance testing, so there's a real danger of the actual implementation diverging from the specification simply by accident. BTW, 0.12 is more or less ready to ship, and it has stabilized a lot of all the new stuff that arrived in 0.11 (along with a ton of new code, obviously). So if you guys start porting sage to 0.12, by all means report on our tracker (https://github.com/ipython/ipython/issues) anything that you see causing a problem. I'm sure you'll find little things here and there we broke that you were using, since Sage uses IPython fairly deeply, but hopefully all should be fixable without too much work. I'm not sure exactly how Sage initializes IPython, but it would be great if in the port to 0.12, you were able to do everything needed for the Sage terminal application as a profile. The profile machinery is much more robust now, and lets you configure just about anything in ipython. If this can be made to work, the command-line version of sage would amount to calling ipython --profile sage The advantage of this is that it would be possible then to launch a 'sage kernel' with ipython kernel --profile sage or to connect to Sage with any of our frontends: ipython console --profile sage ipython qtconsole --profile sage ipython notebook --profile sage Just some ideas for those in the sage-dev team who decide to tackle this one. Let us know on the ipython-dev list how it goes; I try to keep an eye on this list but if I'm swamped I may ignore long stretches completely and can easily miss a message. Cheers, f -- 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: Re: [sage-devel] timeit for mathematicians
On Wed, Dec 14, 2011 at 10:11 AM, Harald Schilly wrote: > Nice plots of it are > called box-plots. This captures everything more accurately than the > min/mean/sd scheme. (The reason why quantiles aren't used that much in > the past is just that sorting is much harder than sum+division.) A nice summary of all things boxplots: http://vita.had.co.nz/papers/boxplots.html Cheers, f -- 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: MathCad-like front end for Sage
I unfortunately don't keep up with sage-dev as much as I'd like to, so forgive me if I'm saying something you all already know... On Mon, Nov 28, 2011 at 4:08 AM, Nicolas M. Thiery wrote: > Has anyone tried and managed to get Spyder to work with Sage? Once sage is ported to work with ipython 0.12 (to be released hopefully within a few weeks, git master is nearly ready), this should be more or less trivial. Pierre (Spyder author) has done a good job of keeping up with the changes in ipython, and I think the current version of spyder already supports using an ipython kernel over zeromq. So once the work of porting sage's prefilter, config and other details to ipython is done, it should be a simple matter of telling spyder to open an ipython with that configuration instead of a plain one. Incidentally, another thing you'll get with the port will be the ability to run sage in 'headless' mode by running an ipython kernel with the sage config. Now you can type 'ipython kernel' and this starts up an ipython that only listens over zeromq sockets. You use it by connecting a qt console or terminal-based console (this one isn't fully merged yet) and can disconnect-reconnect as needed. The idea is to decouple the basic execution of code in the kernel from the details of the frontend using that kernel. This would make it possible to talk to sage-as-a-service from a variety of clients. Cheers, f -- 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: Asymptote (vector graphics language)
On Mon, Oct 10, 2011 at 1:40 AM, Jason Grout wrote: > If Asymptote generated 3d *vector* graphics (unlike Tachyon, and like the > matplotlib 3d engine), I could see it adding something of real value to > Sage. But from what I saw of the examples online, it appeared that the pdf > files of 3d graphics were simply bitmapped graphics wrapped in a pdf file. PyX is a cool project worth having a look at, I've used it in the past very happily: http://pyx.sourceforge.net/examples/3dgraphs/color.html It does certain kinds of things very easily that aren't easy at all in mpl: http://pyx.sourceforge.net/gallery/graphs/index.html Cheers, f -- 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: Fwd: [IPython-dev] [ANN] IPython 0.11 is officially out
On Mon, Aug 1, 2011 at 6:28 PM, Francois Bissey wrote: > > I have now subscribed to IPython-dev. I will start a thread when things > starts happening. I will start by updating sympy in sage to 0.7.1 as they > have taken care of compatibility problems with IPython-0.11 already. > It may be that other components of sage needs updating as well. > A numpy upgrade is the most problematic item that I am aware of at > the moment. Sounds like a good plan, keep us posted. Note that numpy has no ipython dependency, and matplotlib only syncs with ipython for GUI interactive plots (which are turned off in Sage by default). So of the 'scipy stack', sympy is the only one that to my knowledge is directly impacted by the ipython changes, as far as Sage is concerned. Cheers, f -- 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: Re: [sage-devel] Re: Fwd: [IPython-dev] [ANN] IPython 0.11 is officially out
On Sun, Jul 31, 2011 at 11:51 PM, Francois Bissey wrote: > I'll give it a spin as soon as it is available for gentoo and report the > problems in this thread. How does that sound? Sounds great, modulo one key detail: let's have the discussion on the ipython-dev list (http://mail.scipy.org/mailman/listinfo/ipython-dev), not here. These will mostly be ipython issues, not Sage ones, so what we need is the attention of all the ipython developers to solve them. Furthermore, even if it's something where you need guidance on how to update Sage code, the rest of the IPython devs don't lurk on sage-dev, so by having the conversation here you'll bottleneck on my availability. I do my best to keep up with sage-dev, but I often tune out for weeks/months at a time if I'm too swamped. But on the ipython-dev list, the whole team will be available to help beyond what I can do. Keep in mind that at this point, I don't actually *know* the answer to many questions in IPython, since the code has grown far larger than what I originally wrote. So once you start finding out issues, let's start a fresh Sage-titled thread on ipython-dev, and we'll certainly (as a team) will do our best to help out. Hopefully with minimal work on both sides (ipython/sage), the 0.12 ipython release will be an easy one to upgrade Sage into. Cheers, f -- 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: Fwd: [IPython-dev] [ANN] IPython 0.11 is officially out
On Sun, Jul 31, 2011 at 10:59 PM, François wrote: > For those interested Jason Grout has already filled a ticket to upgrade to > ipython-0.10.2 (trac #11460) with a comment that Fernando told him that > it would be better to skip 0.11. I should qualify that comment with a bit of context: there's a TON of changes in 0.11, and the internal customization APIs are all very different. This means a lot of stuff that Sage does won't work out of the box with 0.11. However, we will need some help from the Sage team to find out areas where we may have inadvertently dropped a feature or removed an entry point without putting in a replacement in the new APIs. Since Sage makes more intense use of IPython than most other projects, there are things we'll only find out about once Sage tries to update. All this means that while 0.11 is not likely to be an easy update for Sage, simply waiting will not work either. The best approach would be for someone to give 0.11 a try and let us know what breaks by opening issues in our tracker (https://github.com/ipython/ipython/issues) and asking on our -dev mailing list (http://mail.scipy.org/mailman/listinfo/ipython-dev). That way, hopefully they will get resolved during the 0.12 cycle and then when 0.12 does come out, it will be realistic for Sage to actually upgrade without troubles. Cheers, f -- 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] Fwd: [cython-users] Scientific Python at SIAM CSE 2011 conference
On Wed, Apr 6, 2011 at 10:35 AM, William Stein wrote: > -- Forwarded message -- > From: Fernando Perez > Date: Wed, Apr 6, 2011 at 12:26 AM > Subject: [cython-users] Scientific Python at SIAM CSE 2011 conference > To: IPython Development list , IPython User > list , cython-users > , matplotlib development list > , Discussion of Numerical > Python , SciPy Users List > , sympy , Ondrej Certik > > > > Hi all, > > sorry for the massive cross-post, but since all these projects were > highlighted with talks at this event, I figured there would be > interest... Hans-Petter Langtangen, Randy LeVeque and I organized a Thanks William, I was already feeling a bit like a spammer so I refrained from posting to sage-dev :) Best, f -- 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] Short summary post on Sage Days visit
Hi folks, a quick summary of last week's Sage Days work from my perspective: http://blog.fperez.org/2011/03/ipython-and-scientific-python-go-to.html Thanks again to William for the workshop! Cheers, f -- 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: Fernando Perez's talk today at Sage Days 29
On Sat, Mar 26, 2011 at 8:47 AM, Samuel Lelievre wrote: >> including a historical introduction with a story about how he accidentally >> unplugged the internet for the entire country of Colombia when he was >> a grad student. You can watch the video of the talk here: >> http://www.youtube.com/watch?v=1j_HxD4iLn8 > > NB: The unplugging anecdote is from 0:11:20 to 0:14:12 in the video. Minor correction, I was still finishing undergrad at the time, before I moved to the US for grad school. Disconnecting your country from the internet: real-world evil dictators like Mubarak or Gaddafi can't do it, but benevolent open source ones can :) Cheers, f -- 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] Fernando Perez's talk today at Sage Days 29
Hi all, On Thu, Mar 24, 2011 at 10:16 PM, William Stein wrote: > Hi, > > Today Fernando Perez gave a very inspiring and enthusiastic talk today > at Sage Days 29 on Scientific Computing using Python, including a > historical introduction with a story about how he accidentally > unplugged the internet for the entire country of Colombia when he was > a grad student. You can watch the video of the talk here: > http://www.youtube.com/watch?v=1j_HxD4iLn8 Thanks for putting the video up! The slides are here: http://fperez.org/talks/1103_uwashington.pdf Cheers, f ps - for those interested, these days have been *very* productive for IPython. This page: http://wiki.sagemath.org/days29/bugs has the list of issues we've closed since Monday (50 and counting), and today we had a very good discussion with Jason Grout and others from the Sage team about IPython's messaging protocol. Many thanks to William for the invitation and support! -- 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: BSD licensed bignum library
On Wed, Sep 8, 2010 at 8:11 AM, Jason Grout wrote: > > I suppose another point of relevance is that there is a slight possibility > that it could also be used in Python for the native Python bignums, which > would hopefully make normal python integers must faster. That was the first thing that crossed my mind, and I would love to see that happen eventually. It would be fabulous if python didn't natively just have bignums (which it does) but if they were also of very high quality implementation wise. And as William said, this will be of a lot of interest to the numpy/scipy world, since it would be a viable library to build on top of directly for numpy/scipy. Many thanks to Bill for spearheading this, and here's to wishing him much success. Regards, f -- 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] ipython pipeline
Hi Jason, On Tue, Aug 31, 2010 at 7:13 AM, Jason Grout wrote: > > Fernando, if you're reading this: I'm curious if you have any thoughts on > how the Sage notebook might be impacted by this. The notebook itself, not at all: sagenb doesn't use any ipython code itself. It has features that ipython introduced, like the formatting of the ?/?? output, or the use of the % syntax for special commands --though with different semantics to IPyhton's magics, but all of it is a separate implementation based on Twisted. In the long run, if our approach works very well, and sage wants to move away from twisted (one of the reasons we want to leave twisted is for python3 support), sage could decide to use this ipython as its backend and expose its own app semantics to its notebook. But it will be a while before that needs to be considered. In the short term, the bigger benefits would be to terminal-based users: these new, richer local clients for ipython (two-process terminal, curses-based, Qt-based) are all 'just ipython', and in that sense could be used by Sage too (assuming it shipped the dependencies, like Qt and zeromq). The sage command line is a customized ipython, so sage could equally decide to customize this new ipython and expose a new set of local clients to run sage locally. I hope this helps, f -- 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] State of the Windows port of pexpect?
Hi folks, for IPython I found myself this weekend writing some pexpect-based code, and I recall that in the past, Sage has looked into ways of getting pexpect to run under Windows platforms. Robert Kern pointed me to this: http://sage.math.washington.edu/home/goreckc/sage/wexpect/ but it doesn't look like it's seen much activity as of late. I was wondering: is this code already functional? If not, is it reasonably close, or would there still be a lot of work to be done to complete it? Or did it run into fundamental difficulties that made the project be abandoned? Thanks for any pointers! Cheers, f -- 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: [cython-users] Re: [sage-devel] Cython cpu time
On Wed, Jul 14, 2010 at 11:54 PM, Ondrej Certik wrote: > I hope he is. I haven't seen any patches since 2009-03-13 and it > segfaulted my code, but I fixed it and sent him the patches. (I pulled > his repo using hg-git, and pushed into github.) Cool, thanks. In the meantime I can use yours then. I haven't encountered the segfaults myself, but it's good to know there's a maintained version out there. Cheers, f -- 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: [cython-users] Re: [sage-devel] Cython cpu time
On Wed, Jul 14, 2010 at 10:02 PM, Ondrej Certik wrote: > Thanks for this. Btw, I just revived this cython based line profiler: > > http://github.com/certik/line_profiler > Is Robert K not maintaining the original anymore? Cheers, f -- 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: Implementation of Graphs, c_graphs, and NetworkX
On Tue, Dec 1, 2009 at 8:56 AM, Nathann Cohen wrote: > Hmmm... If we can make Sage's C graphs as fast as NetworkX's , I > assure you it will be very hard for them to compete with LP on our > side and so many features around in Sage... As most of NetworkX's > functions are not very hard to rewrite once the basis is set ( graph > structure, neighbors, etc ) I am more set to try to move away from > this library, especially if they changed to a Sage-uncompatible > license. An important clarification: The BSD license is *not* incompatible with Sage, as Sage ships a massive amount of BSD (and similarly licensed) code already. What William said was that for this particular topic, using the GPL was better aligned with the goals and needs of Sage, not that the NetworkX license was incompatible. Cheers, f -- 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] Implementation of Graphs, c_graphs, and NetworkX
On Tue, Dec 1, 2009 at 4:40 AM, William Stein wrote: > One potential problem is that all the Sage graph theory code is GPL'd, > but Networkx is now BSD licensed (it used to be GPL'd). Given that > graph theory in Sage is an area with a lot of possibly unfriendly > competition with Magma and Mathematica, the GPL license is appropriate > for us for that part of Sage. Aha, that makes perfect sense for Sage then. Thanks for the clarification. > A second potential problem is that all the code we're talking about is > written in Cython, whereas Networkx is a pure Python library (I > think?). Actually I've heard Aric Hagberg (the nx project lead) say that he's very interested in Cythonizing parts of nx for speed reasons, so I doubt this would be a problem; they might actually like to see contributions from people with Cython expertise. But your point on licensing stands. Cheers, f -- 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] Implementation of Graphs, c_graphs, and NetworkX
On Mon, Nov 30, 2009 at 9:01 PM, Robert Bradshaw wrote: > I think the basic idea was that one could write a faster (sparse and > dense) graph "core," and then run all the NetworkX algorithms on top > of it as long as it supported the interface (for manipulating and > querying vertices and edges). If some code was still too slow then it > would be moved down to C (hopefully it would be sufficient to declare > the graphs as c-graphs and compile with Cython to remove all the > Python function call overhead). I don't know how well this works at > the moment. > Is there any particular reason why this code couldn't be contributed upstream to Networkx? I use networkx outside of Sage, and it would be great to have speed improvements made there as well; since Sage already ships nx it would obviously benefit regardless. There may be a good reason for not doing so, I'm just curious. From my perspective, the more Sage work also benefits upstream projects, the more impact it has and more people benefit from it, both those who use Sage directly and those who may use those projects outside of Sage. Obviously in some cases this isn't viable (dependencies on core Sage code are an obvious one), hence my question. Cheers, f -- 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-notebook] automatically defining variables names
On Wed, Nov 18, 2009 at 1:34 AM, William Stein wrote: > Awesome. I've made a new ticket for doing a command-line version for Sage: > > http://trac.sagemath.org/sage_trac/ticket/7486 > Great! And please send it our way once ready. If sage improvements to ipython go to ipython, all users (including sage) benefit. Otherwise only sage benefits; the more you upstream improvements, the more we all gain. I'm sure this is the type of extension that others (sympy, etc) could also use; as long as the default name generator can be controlled. Sage would emit its own variables, sympy would use sympy.var(), someone in another context could emit whatever makes sense in their environment, etc. We'd be happy to include this as an optional ipython tool if you make it available to us! Cheers, f -- 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: [sage-notebook] automatically defining variables names
On Tue, Nov 17, 2009 at 7:51 PM, William Stein wrote:
> Can somebody referee this? It's mainly code in the *notebook* --
> it doesn't seem possible to do something like the above on the command
> line without some deep internal change to Ipython.
>
Actually no, not that hard: ipython executes all user code inside a
dict created at initialization time. One could replace this (today a
plain python dict) with another dict that would implement the
requested behavior. This would spring variables into existence when a
KeyError was about to occur.
The command-line doesn't have the notion of a cell (yet, that will
hopefully change soon) but it could be toggled with a function call.
It's basically a matter of instantiating the initial ipython with a
custom user_ns dict that does the above, that should be all. And
providing a magic (or even plain) function in the global namespace to
toggle this behavior on/off at runtime.
The attached file (run it as 'ipauto.py') shows how it could work, I
didn't implement the toggling and it's a quick hack, but the basic
idea is there. Here it is in action:
In [1]: %autocall 0
Automatic calling is: OFF
In [2]: x+y
Injecting x
Injecting y
Out[2]: x + y
In [3]: type(x)
Out[3]:
In [4]: x+3
Out[4]: 3 + x
In [5]: x**2+x*x
Out[5]: 2*x**2
In [6]: x+z**3
Injecting z
Out[6]: x + z**3
A couple of notes:
- It's key to disable autocalling for this to work, otherwise too many
false positives are triggered. If this idea proves to have wings, it
will be one more argument in favor of disabling autocalling (it just
has too many uncontrollable side effects).
- Unfortunately IPython as shipped needs a tiny patch for this to
work, due to a really silly omission. The patch is a trivial 2-liner,
in case anyone wants to take this further for Sage:
(ipython-0.10)maqroll[0.10]> bzr diff
=== modified file 'IPython/Shell.py'
--- IPython/Shell.py2009-04-14 20:12:02 +
+++ IPython/Shell.py2009-11-18 09:03:01 +
@@ -1230,7 +1230,7 @@
# This is the one which should be called by external code.
-def start(user_ns = None):
+def start(user_ns = None, user_global_ns = None):
"""Return a running shell instance, dealing with threading options.
This is a factory function which will instantiate the proper IPython shell
@@ -1238,7 +1238,7 @@
different GUI toolkits require different thread handling details."""
shell = _select_shell(sys.argv)
-return shell(user_ns = user_ns)
+return shell(user_ns = user_ns, user_global_ns = user_global_ns)
# Some aliases for backwards compatibility
IPythonShell = IPShell
Cheers,
f
--
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#!/usr/bin/env python
# -*- coding: utf-8 -*-
import __builtin__
from sympy import var
class AutoNS(dict):
def __getitem__(self, key):
if key not in self and key not in self['__IP'].user_global_ns \
and key not in __builtin__.__dict__:
# inject
print 'Injecting',key
self[key] = var(key)
return dict.__getitem__(self, key)
# main
import IPython.Shell
IPython.Shell.start(AutoNS(),{}).mainloop()
[sage-devel] [ANN] For SF Bay Area residents: a discussion with Guido at the Berkeley Py4Science seminar
Hi folks, if you reside in the San Francisco Bay Area, you may be interested in a meeting we'll be having tomorrow November 4 (2-4 pm), as part of our regular py4science meeting series. Guido van Rossum, the creator of the Python language, will visit for a session where we will first do a very rapid overview of a number of scientific projects that use Python (in a lightning talk format) and then we will have an open discussion with Guido with hopefully interesting questions going in both directions. The meeting is open to all, bring your questions! More details on this seminar series (including location) can be found here: https://cirl.berkeley.edu/view/Py4Science Cheers, f ps - William is actually in Berkeley, but unfortunately this collides dead-on with a talk he's giving (same building, 2 floors up :). I will however cover sage in my lightning intro of projects, unless anyone from this list wants to do it. In that case, just send me 3 slides max (you'll have less than 5 minutes to talk) and I'll be happy to defer. --~--~-~--~~~---~--~~ 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: Graphical Physics Program Suggestions
On Wed, Sep 23, 2009 at 4:41 AM, Prabhu Ramachandran wrote: > Thanks Fernando. The speed issue is still true but I wouldn't blame > traits since that isn't the source of the bottleneck. I think there are > a little too many events and too many renders. I have not had the time > to profile it carefully. > Thanks for the clarifications, Prabhu. I remembered the performance drop, but wasn't sure what all of the reasons were under the hood and I was worried I could misrepresent the issue. It would really be great to have vpython-like performance with the clean tvtk api! Here's to hoping it's possible :) Cheers, f --~--~-~--~~~---~--~~ 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: Graphical Physics Program Suggestions
On Tue, Sep 22, 2009 at 12:41 PM, Jason Grout wrote: > Since we also already have momentum for incorporating mayavi, we should > also point out the mayavi tvtk "visual" module, whose api is modeled > after vpython: > > https://svn.enthought.com/enthought/wiki/TVTKIntroduction#visual > > I've used vpython too, and I thought it was really nice and simple. Prabhu may comment with more information, but in the meantime, it's worth keeping in mind that 'tvisual' has significantly lower performance than visual, and in this case I'm not sure it can be fixed. The issue is that the traits event handling machinery proves to be too much overhead when you're trying to render a 3d scene at interactive framerates, and the geometry is already being computed by a python loop. Since tvtk is based on traits, all the traits machinery is still active and in this case may be a bit too much. If memory serves me right, Prabhu wasn't super optimistic about being able to match vpython performance with tvisual, but I could (and would love to) be misremembering, or perhaps it's just a matter of putting manpower into it and not a fundamental limitation. I just mention it so you are aware that out of the box, tvisual's performance is just not enough to be usable like vpython is (and I only tested it on fairly simple examples). In case you'd like to run a simple comparison (and perhaps things have improved), I'm attaching a simple example of parabolic motion written both for vpython (old version) and tvtk/visual. Caveat: I haven't run this code in years, so I'm not sure it runs with today's vpython or tvtk. Cheers, f --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- #!/usr/bin/env python """Visual Python demo: shooting a falling object. Note that this script can NOT be run inside ipython via the 'run' command. You MUST run it from the command line as a standalone program. Start by doing chmod +x shoot.py (or whatever you called it), and then you can run it via ./shoot.py """ import time import sys # Visual is built on top of the 'old' Numeric, so do NOT use numpy here. We # do a wholesale import for coding convenience, this is highly discouraged in # larger codebases (but usually OK in very small demo scripts and interactive # use). from Numeric import * import visual as V # Geometric parameters (all in MKS units) theta = pi/4 # initial angle of gun D = 20 # width ... H = 20 # height of floor g = -9.8 # gravity gun_len = 2 # size of gun arrow_len = 4 # and of arrow v0_default = 15 # default for initial velocity if not given # Numerical simulation parameters dt = 0.01 # Update for all velocities under constant acceleration (gravity) dv = V.vector(0,g*dt,0) # Tolerance for deciding whether a collision happened impact_distance = 0.5 # Initialize arguments try: v0 = float(sys.argv[1]) except: v0 = v0_default print 'Using default v0 =',v0,'m/s.' # Build 3d world # Define the line of sight sight = V.vector(cos(theta),sin(theta),0) # The floor is just a thin box floor = V.box(pos=(D/2.,0,0), length=D, height=0.5, width=D, color=V.color.blue) # Use a cone for our 'arrow' arrow = V.cone(pos=(0,0,0), radius=0.9, axis=sight,color=V.color.red) arrow.velocity = v0*sight # The target is a sphere target = V.sphere(pos=(D,H,0), radius=1, color=V.color.yellow) target.velocity = V.vector(0,0,0) # The 'dart gun' is just a cylinder. gun = V.cylinder(pos=(0,0,0), axis=gun_len*sight, radius=1, color = V.color.green) # Run simulation print 'Starting simulation...' # Put a little delay to give all the OpenGL stuff time to initialize nicely. time.sleep(1) while (arrow.y >= 0 and target.y >=0) and \ V.mag(arrow.pos-target.pos) > impact_distance: V.rate(75) for obj in (arrow,target): obj.pos += obj.velocity*dt obj.velocity += dv # Report to user. if V.mag(arrow.pos-target.pos) <= impact_distance: print 'Hit!' else: print 'Miss...' #!/usr/bin/env python """Visual Python demo: shooting a falling object. Note that this script can NOT be run inside ipython via the 'run' command. You MUST run it from the command line as a standalone program. Start by doing chmod +x shoot.py (or whatever you called it), and then you can run it via ./shoot.py """ import time import sys # Visual is built on top of the 'old' Numeric, so do NOT use numpy here. We # do a wholesale import for coding convenience, this is highly discouraged in # larger codebases (but usually OK in very small demo scripts and interactive # use). import numpy as N import math from enthought.tvtk.tools import visual as V def mag(v): "Return the magnitude of a vector"
[sage-devel] Re: Graphical Physics Program Suggestions
On Tue, Sep 22, 2009 at 11:14 AM, kstueve wrote: > An example of the desired functionality is to either with a few lines > of code from within a Sage worksheet, or by clicking buttons in a > graphical user interface (GUI) create a physics problem with > components such as ramps, blocks, balls, pulleys, and springs, and > processes such as motion (translational or rotational), collisions > (elastic, inelastic, completely inelastic), and forces (friction, > gravity, normal forces, driving forces, etc). > You might want to have a look at vpython: http://vpython.org/ It originated at Carnegie Mellon as a program to teach undergraduate physics such that with very little code (and critically, no 3d programming or OpenGL knowledge), one could create a physics problem with > components such as ramps, blocks, balls, pulleys, and springs, and > processes such as motion (translational or rotational), collisions > (elastic, inelastic, completely inelastic), and forces (friction, > gravity, normal forces, driving forces, etc). :) Even if it doesn't fit precisely your needs, it's probably good inspiration and has been around for ~ 9 years. I've used it (the old version) for small demos and it's really nice. Cheers, f --~--~-~--~~~---~--~~ 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: sage notebook work planning
On Tue, Sep 8, 2009 at 8:11 PM, Brian Granger wrote: > > >> At the same time, I think it would be big mistake to give up easy >> WYSIWYG editing of text cells. Is it easy to convert between HTML and >> ReST (both directions)? If so, I think it would be easy to make a text >> cell toggleable between TinyMCE and a textbox that would let you put in >> ReST. >> > > Yes, I agree. For developer types, ReST is wonderful and quick. But for > many potential Sage users > (like all of my students) ReST would be a huge step back from the current > WYSIWYG editing. Certainly! What I'd love to have is reST as a native storage format (so it can be easily edited outside the GUI with emacs) along with a choice of visual/native editing in the notebook interface. It's just that in switching from visual to native you'd go to reST as the 'raw' format instead of pure html, and the html would be only rendered for visual display. This would also let us produce a pdf of any notebook with the full sphinx machinery: every worksheet could have an optional cell/tab/something to provide the equivalent of conf.py for sphinx docs. Just thinking out loud... Cheers, f --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage notebook work planning
On Tue, Sep 8, 2009 at 6:45 PM, William Stein wrote: > > Hi, > > Mike Hansen and I just spent a while carefully going through: > > http://wiki.sagemath.org/SageUsability > > and updated it with more ideas... I wonder if it would be totally crazy to consider using reST as the native notebook format, or at least have it be optionally so. I know that one can already execute 'live' sphinx docs in html, which is super cool. But given that reST has support for input and output code blocks (which it can even doctest), I'd really like to basically edit in the notebook itself reST sources, with text cells being plain reST, input cells being code blocks and output being 'text' code blocks, as suggested here: http://groups.google.com/group/sphinx-dev/browse_thread/thread/ecbcea0ab4d1ca78/86e3da68e1576f7a I don't know enough about all the sphinx machinery yet to see if there are any fatal flaws in this idea, and given the amount of existing worksheets out there obviously such a change couldn't be done lightly. But I'm so happy with using sphinx more and more, that being able to simultaneously edit reST and execute code seems really appealing to me. Does this sound possible/reasonable/useful? Cheers, f --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] Question about packaging external fortran parser with Cython for fwrap
On Thu, Aug 13, 2009 at 5:05 PM, William Stein wrote: > I'm just curious. Why does the PSF reject BSD-licensed code, but > accept Apache-licensed code, given that the Apache license is vastly > more restrictive than BSD? I can understand this, but find it > surprising. > I'm also scratching my head a little on that one, and would love to hear the reasons behind it... Cheers, f --~--~-~--~~~---~--~~ 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 URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Tutorial topics for SciPy'09 Conference
On Wed, Jul 1, 2009 at 11:50 AM, Fernando Perez wrote: > I sort of doubt that most people would make their decisions on what > tools to learn based on licenses, or at least I hope that's the case. To be precise: amongst open source tools. I do use licenses as a criterion: if choosing between a proprietary and an open source tool I lean towards the open one whenever feasible. But otherwise I'm happy to use, and contribute to when I can, anything that's open source in any license. But that's just me :) Cheers, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Tutorial topics for SciPy'09 Conference
Howdy, On Wed, Jul 1, 2009 at 3:57 AM, William Stein wrote: > I have to add that not only is Sage very low on the above list, Sage > got the *most* "no" votes from the 30 people who actually voted (tying > only with Networkx), according to the table here: > > http://fdoperez.blogspot.com/2009/06/scipy-advanced-tutorials-results.html > > I don't know if I should interpret this as: > > (1) Sage doesn't at all provide what is needed by "the scipy community", or > > (2) The scipy community has a strong opinion that in fact sage is > worse than useless. I have to say that *personally* I was both surprised and disappointed at the low ranking Sage got, since I was hoping to have a Sage tutorial again this year. On every talk I give on scientific computing with Python I always make a point of highlighting Sage, I use it myself and I think it's a key asset of a larger ecosystem of open source tools for scientific computing based on Python. But all I'm doing here is reporting the numbers as they came: the only change I made to the raw Doodle data was to remove the voters' names and transpose the table for readability (Doodle returns each topic as a column, which is annoying to read). > It might also be relevant that Sage, Hermes, and Networkx (in the > bottom 4) are all GPL'd, but the top 7 packages by interest in the > list above are all non-GPL (BSD or MIT licensed). It may just be > that whoever voted are mostly people who believe they can't use GPL'd > code. > > Anyway, I find Fernando's justification for the ranking "the ranking > roughly follows the generality of the tools" to be an unsatisfactory > explanation or summary of the data. Rather, perhaps the ranking > roughly follows the restrictiveness of the *license*. That was just a hand-wavy argument, since ultimately I can't know why people voted the way they did. I should note that Networkx is LGPL, not GPL; see https://networkx.lanl.gov/trac/browser/networkx/trunk/doc/GNU_LGPL.txt and https://networkx.lanl.gov/trac/browser/networkx/trunk/networkx/release.py, which specifically contains 1 """Release data for NetworkX.""" 2 3 #Copyright (C) 2004-2008 by 4 #Aric Hagberg 5 #Dan Schult 6 #Pieter Swart 7 #Distributed under the terms of the GNU Lesser General Public License 8 #http://www.gnu.org/copyleft/lesser.html So the bottommost project (which as I mentioned, I also love and wanted to get a tutorial on) is not GPL. I should have definitely qualified my 'generality' comment by pointing that Sage was the outlier in this (weak) pattern: while finite elements, time series and graph theory are specialized topics, sage is a super-broad-spectrum tool, so it definitely doesn't fit that trend. That point was clear to me and did surprise me very much, I just failed to mention it last night (I wrote that blog post rather in a hurry, tired, and was mostly annoyed at blogspot's mangling of the table html). I sort of doubt that most people would make their decisions on what tools to learn based on licenses, or at least I hope that's the case. But perhaps I'm wrong on that and just naive... In any case, all I can do is report back the results as they came. In this case, I'm just the messenger :) Cheers, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Tutorial topics for SciPy'09 Conference
Hi, On Mon, Jun 1, 2009 at 10:20 PM, Fernando Perez wrote: > The time for the Scipy'09 conference is rapidly approaching, and we > would like to both announce the plan for tutorials and solicit > feedback from everyone on topics of interest. rather than rehash much here, where it's not easy to paste a table, I've posted a note with the poll results here: http://fdoperez.blogspot.com/2009/06/scipy-advanced-tutorials-results.html The short and plain-text-friendly version is the final topic ranking: 1 Advanced topics in matplotlib use 2 Advanced numpy 3 Designing scientific interfaces with Traits 4 Mayavi/TVTK 5 Cython 6 Symbolic computing with sympy 7 Statistics with Scipy 8 Using GPUs with PyCUDA 9 Testing strategies for scientific codes 10 Parallel computing in Python and mpi4py 11 Sparse Linear Algebra with Scipy 12 Structured and record arrays in numpy 13 Design patterns for efficient iterator-based scientific codes 14 Sage 15 The TimeSeries scikit 16 Hermes: high order Finite Element Methods 17 Graph theory with NetworkX We're currently contacting speakers, and we'll let you know once a final list is made with confirmed speakers. Cheers, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Tutorial topics for SciPy'09 Conference
On Mon, Jun 15, 2009 at 6:24 AM, Jason Grout wrote: > > Fernando Perez wrote: >> Hi all, >> >> In order to proceed with contacting speakers, we'd now like to get >> some feedback from you. This Doodle poll should take no more than a > > > Does "you" mean "people attending scipy09", or does it mean "sage > developers, whether or not you are attending scipy09"? Any feedback is welcome, though it seems to make more sense if you're coming to the conference, since the poll is about picking topics for the tutorials sessions. But ideas, feedback, suggestions are in general welcome either via the poll or via list or private email. Since Sage is listed as a candidate topic, votes on a Sage tutorial with comments on specific ideas that someone would be willing to present would be very welcome. In the end, the actual choices of topics will be determined by what we can get speakers to present, so that kind of information is obviously very relevant. Cheers, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Tutorial topics for SciPy'09 Conference
Hi all, In order to proceed with contacting speakers, we'd now like to get some feedback from you. This Doodle poll should take no more than a couple of minutes to fill out (no password or registration required): http://doodle.com/hb5bea6fivm3b5bk So please let us know which topics you are most interested in, and we'll do our best to accommodate everyone. Keep in mind that speaker availability and balancing out the topics means that the actual tutorials offered probably won't be exactly the list of top 8 voted topics, but the feedback will certainly help us steer the decision process. Thanks for your time, Dave Peterson and Fernando Perez On Mon, Jun 1, 2009 at 10:22 PM, Fernando Perez wrote: > Hi all, > > The time for the Scipy'09 conference is rapidly approaching, and we > would like to both announce the plan for tutorials and solicit > feedback from everyone on topics of interest. > > Broadly speaking, the plan is something along the lines of what we > had last year: one continuous 2-day tutorial aimed at introductory > users, starting from the very basics, and in parallel a set of > 'advanced' tutorials, consisting of a series of 2-hour sessions on > specific topics. > > We will request that the presenters for the advanced tutorials keep > the 'tutorial' word very much in mind, so that the sessions really > contain hands-on learning work and not simply a 2-hour long slide > presentation. We will thus require that all the tutorials will be > based on tools that the attendees can install at least 2 weeks in > advance on all platforms (no "I released it last night" software). > > With that in mind, we'd like feedback from all of you on possible > topics for the advanced tutorials. We have space for 8 slots total, > and here are in no particular order some possible topics. At this > point there are no guarantees yet that we can get presentations for > these, but we'd like to establish a first list of preferred topics to > try and secure the presentations as soon as possible. > > This is simply a list of candiate topics that various people have > informally suggested so far: > > - Mayavi/TVTK > - Advanced topics in matplotlib > - Statistics with Scipy > - The TimeSeries scikit > - Designing scientific interfaces with Traits > - Advanced numpy > - Sparse Linear Algebra with Scipy > - Structured and record arrays in numpy > - Cython > - Sage - general tutorial > - Sage - specific topics, suggestions welcome > - Using GPUs with PyCUDA > - Testing strategies for scientific codes > - Parallel processing and mpi4py > - Graph theory with Networkx > - Design patterns for efficient iterator-based scientific codes. > - Symbolic computing with sympy > > We'd like to hear from any ideas on other possible topics of interest, > and we'll then run a doodle poll to gather quantitative feedback with > the final list of candidates. > > Many thanks, > > f > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Tutorial topics for SciPy'09 Conference
On Mon, Jun 1, 2009 at 10:22 PM, Fernando Perez wrote: > Hi all, > > The time for the Scipy'09 conference is rapidly approaching, and we > would like to both announce the plan for tutorials and solicit > feedback from everyone on topics of interest. I hope the above isn't considered too off-topic here: I'm asking for possible Sage tutorials and obviously this group would be the most likely to provide presenters :) Feel free to provide feedback to me off-list to keep the list traffic on topic to sage-dev. Cheers, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Tutorial topics for SciPy'09 Conference
Hi all, The time for the Scipy'09 conference is rapidly approaching, and we would like to both announce the plan for tutorials and solicit feedback from everyone on topics of interest. Broadly speaking, the plan is something along the lines of what we had last year: one continuous 2-day tutorial aimed at introductory users, starting from the very basics, and in parallel a set of 'advanced' tutorials, consisting of a series of 2-hour sessions on specific topics. We will request that the presenters for the advanced tutorials keep the 'tutorial' word very much in mind, so that the sessions really contain hands-on learning work and not simply a 2-hour long slide presentation. We will thus require that all the tutorials will be based on tools that the attendees can install at least 2 weeks in advance on all platforms (no "I released it last night" software). With that in mind, we'd like feedback from all of you on possible topics for the advanced tutorials. We have space for 8 slots total, and here are in no particular order some possible topics. At this point there are no guarantees yet that we can get presentations for these, but we'd like to establish a first list of preferred topics to try and secure the presentations as soon as possible. This is simply a list of candiate topics that various people have informally suggested so far: - Mayavi/TVTK - Advanced topics in matplotlib - Statistics with Scipy - The TimeSeries scikit - Designing scientific interfaces with Traits - Advanced numpy - Sparse Linear Algebra with Scipy - Structured and record arrays in numpy - Cython - Sage - general tutorial - Sage - specific topics, suggestions welcome - Using GPUs with PyCUDA - Testing strategies for scientific codes - Parallel processing and mpi4py - Graph theory with Networkx - Design patterns for efficient iterator-based scientific codes. - Symbolic computing with sympy We'd like to hear from any ideas on other possible topics of interest, and we'll then run a doodle poll to gather quantitative feedback with the final list of candidates. Many thanks, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Has IPython been useful to you? Please let me know...
[ Some of you may have already seen this on the numpy/scipy/mpl lists. I know it's a bit redundant because obviously if you use sage at the command line, you use IPython, which is why I didn't originally post here. But after suggestions from members of this list I changed my mind. If you feel that you'd like to contribute something on this front, I'll be very grateful. Original message follows. ] Hi all, [ apologies for the semi-spam, I'll keep this brief and expect all replies off-list ] IPython is a project that many of you on this list are likely to use in your daily work, either directly or indirectly (if you've embedded it or used it as a component of some other system). I would simply like to ask you, if IPython has been significantly useful for a project you use, lead, develop, etc., to let me know. For legal/professional reasons, I need to gather information about who has found IPython to be of value. I started IPython as a toy 'afternoon hack' in late 2001, and today it continues to grow, as the nicely summarized Ohloh stats show: https://www.ohloh.net/p/ipython (obviously, this is now the result of the work of many, not just myself, as is true of any healthy open source project as it grows). But I have never systematically tracked its impact, and now I need to do so. So, if you have used IPython and it has made a significant contribution to your project, work, research, company, whatever, I'd be very grateful if you let me know. A short paragraph on what this benefit has been is all I ask. Once I gather any information I get, I would contact directly some of the responders to ask for your authorization before quoting you. I should stress that any information you give me will only go in a documentation packet in support of my legal/residency process here in the USA (think of it as an oversized, obnoxiously detailed CV that goes beyond just publications and regular academic information). To keep traffic off this list, please send your replies directly to me, either at this address or my regular work one: fernando.pe...@berkeley.edu In advance, many thanks to anyone willing to reply. I've never asked for anything in return for working on IPython and the ecosystem of scientific Python tools, but this is actually very important, so any information you can provide me will be very useful. Best regards, Fernando Perez. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Feedback on PEP 225 sent to python-dev
Hi folks, I sent the collected feedback on this issue to python-dev: http://mail.python.org/pipermail/python-dev/2008-November/083493.html If you are interested, at this point please follow up any further discussion directly on python-dev. I'll do my best to answer any questions there, but I'd greatly appreciate if those who had an opinion on the matter could keep an eye on the python-dev discussion (if there is one) and pitch in as well. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: PEP for new inline operators for Python
On Tue, Nov 4, 2008 at 6:07 PM, Jason Grout <[EMAIL PROTECTED]> wrote: > Sorry to reply to myself, but I also believe that Fernando is subscribed > to this list, so he might see your comments here as well. Yes, I am, and I'll be happy to update the doc before sending it to python-dev with any feedback from this group, as well as including a link to this thread if it develops. Note that I'm just acting as a scribe here: I'm collecting comments to send to python-dev, the decision is up to them and I'm *not* offering to implement the pep itself. But I think the feedback of the scientific/mathematical/numerical users of python may be valuable on this particular decision, and the core python dev team does listen. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ReST/Sphinx Documentation
Hi Mike,
On Tue, Sep 16, 2008 at 12:37 PM, Mike Hansen <[EMAIL PROTECTED]> wrote:
>
> Hi Fernando,
> I used Pandoc http://johnmacfarlane.net/pandoc/ which worked quite
> well so long as you don't have a lot of custom stuff in your LaTeX.
> For example, the main things I had to do was get to manually replace
> things like "\SAGE" in the tex file with "Sage". Also, it tends to
> prefer constructions like "\code{1+2}" versus "{\code 1+2}".
That looks very useful, thanks for the tip!
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: ReST/Sphinx Documentation
n Mon, Sep 15, 2008 at 8:57 PM, Mike Hansen <[EMAIL PROTECTED]> wrote: > > Hello all, > > I've converted the tutorial, constructions guide, installation guide, > and developers' guide over to Sphinx. It should be up to date with > the current versions of the tex documents. You can find PDF copies of > the files at http://sage.math.washington.edu/home/mhansen/doc-sphinx/ > . Quick question: what did you use to make the latex->rest conversion (at least the first pass before manual cleanup)? I need to convert some tex I have lying around; I have a little script someone gave me but I figured I'd ask before starting... Thanks, 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Documentation Quality Initiative
Howdy, On Tue, Aug 26, 2008 at 11:07 AM, Harald Schilly <[EMAIL PROTECTED]> wrote: > > Hi, I want to propose a process to increase the quality of the Sage > documentation. This is the by far most annoying thing about Sage > according to the last survey. I think the userbase is already big and > willing enough to contribute more documentation. To do this in a more > coordinated way, there should be some sort of process and guidelines. It would be great if you could find a way to reuse/improve the tool recently developed for scipy's 'documentation marathon': - Live site: http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/ - Project sources: https://code.launchpad.net/~pauli-virtanen/scipy/pydocweb This tool produced a great amount of improved docs this summer for numpy. There's a bit too much workflow process for my personal taste, but perhaps in practice it's the right balance, and it certainly worked for them. What that tool is missing is integration with other docs (sphinx/rest). Right now I think it only does docstrings, and I'd *love* to have that same workflow for rest doc sources, so that the public can contribute to all the docs in a wiki, that is automatically wired to generate diffs for review. For Sage it could create tickets for your Trac, for numpy it would be numpy/scipy Trac tickets also, for ipython it could be a special bzr branch on launchpad, etc. A generic tool of this kind to manage both the 'narrative' docs of a project and its docstring-based API would be tremendously useful, and the numpy one is a pretty good start already (and publicly available). 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 12:25 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > But did it ever happen to you Fernando that someone would plainly > abuse ipython/numpy/scipy? Clearly ipython is way more popular than > sympy, so if it doesn't happen for numpy/scipy/ipython, I don't think > we have to fear. (btw. fear of what actually?) Well, I've heard at times that plenty of places are using ipython internally in commercial settings, and I'm happy with that. I don't think anyone is going to try to go out and 'sell ipython' since it's so easy to get for free :) Overall for ipython the BSD license approach has worked well, as it's easy for me to take code from matplotlib, numpy or python itself and viceversa without worrying about licensing, and we get users from rather unexpected places (especially in industry). But each license does have its place. For example, I *strongly* support the GPL as the right choice for things like the Linux kernel, so I'm not a fanatic on any front either. My take on this is that I tend to 'go with the flow': if I contribute/extend an existing project I just follow its original license, and for my own things I tend to oscillate between LGPL and BSD depending on the specifics of the case. And I might one day find that I want to use the GPL for a new project, because I do see use cases for it as well. Cheers, f ps - I know this is getting off topic. I'm going to bed and will be happy to discuss this further, but off list to avoid derailing the discussion on symbolics with too much licensing chat. --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 12:09 AM, William Stein <[EMAIL PROTECTED]> wrote: >> I don't know if for this particular project it's a >> realistic/valid/interesting solution or not, but how about using LGPL >> as a middle solution? > > This is not an option because Pynac derives from Ginac and Ginac > is GPL'd: http://www.ginac.de/ So for this project I have absolutely > no choice in the matter. Ah, I see. Thanks for the clarification. BTW, numpy/scipy/mpl/ipython pretty much have to stay away from GPL code because it would force them to relicense completely (something impossible to do in practice even if someone wanted to, given the long history and large developer pool). But there's a fair amount of use of LGPL code in all those projects and related. for example Mayavi and all the Enthought GUI stuff is based on WXPython, which is itself LGPL. Since that code is used as a library and not to copy/paste, the LGPL is not really an issue at all in such cases. In any case, I'm really happy to see better symbolics coming. This will be a huge step forward, and I really hope that you guys all figure out a technical way for sympy to continue, perhaps with an optional pynac backend (I'd have no problem using it myself in research, like I use tons of GPL code elsewhere, I just don't copy any of it in ipython/numpy). 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 10:58 AM, William Stein <[EMAIL PROTECTED]> wrote: >> As to GPL vs BSD, I am sad that some people will not contribute to a >> BSD project and some other people will not use a GPL project. But my >> intuition says that the license is not the main reason. If sympy was >> as fast as ginac (as I hope it will be in not so distant future), I am >> sure it'd be ok, even if it's BSD. BTW, I told Burcin and William that >> if the license was the only reason, I am willing to consider switching >> to GPL (i.e. try to persuade all 44+ contributors), if that would mean >> more people would be developing sympy. Currently it seems to be the >> opposite, i.e. when we switched from GPL to BSD, people and developers >> seemed to like it, but I may well be mistaken. But as I said, I think >> the main problem of sympy is not the license, but speed. > > The GPL/BSD split in the mathematical Python community is > unfortunate and a is very real problem. At scipy'08 it was > the source of tension for some people... I don't know if for this particular project it's a realistic/valid/interesting solution or not, but how about using LGPL as a middle solution? I happen to actually really like the LGPL: I find that it protects my code from flat out abuse, while not imposing my conditions beyond my own code boundaries. But for many cases I find that LGPL strikes an excellent balance and fully protects the original code from closed modifications (though not from use as an unmodified library), which is what I consider most important. In fact, I'd originally licensed ipython as LGPL, and switched to BSD only to make it easier to share code back and forth with numpy/scipy/matplotlib. In this case I'm happy having switched to BSD, but I still like the LGPL a lot. Just a suggestion to consider, though obviously ultimately the decision rests with the code authors. Cheers, f ps - I find the pynac idea extremely cool: using python itself as the rich native support for a C/C++ library in replacement of another heavyweight system (CLN in this case) is a great show of the utility and quality of the language. FWIW I'm +1 on it going in, though I'm not really a sage developer myself. --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage.app possibility
On Fri, Aug 22, 2008 at 10:50 PM, William Stein <[EMAIL PROTECTED]> wrote: > There is a French guy -- Gaël Varoquaux -- who I had dinner with > tonight and who co-organized Scipy 2008, who yesterday demoed > a gui interface for IPython that he's writing. I've cc'd him on this > email, in case he wants to make any remarks. His current GUI > is also "one thread". A good chunk of that code is in ipython's trunk (and will be in 0.9 we're just about to release in a few days): - branch bzr lp:ipython or - http://ipython.scipy.org/dist/testing/ (latest beta) I think there are pieces still just in his laptop though, so unless you just want to look at the core architecture, you may want to wait a bit for him to finish and push this upstream. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: axiom
On Wed, Aug 20, 2008 at 9:37 PM, mhampton <[EMAIL PROTECTED]> wrote: > > I used to really enjoy writing programs in mathematica, but maybe I'm > a strange person. I only stopped in order to force myself to get > fluent with Sage. I think it just depends on your background, what > you are used to, and what you want to do. For symbolic calculations > and programming I still miss mathematica quite often. > > -M. Hampton > > On Aug 20, 12:59 am, "Fernando Perez" <[EMAIL PROTECTED]> wrote: >> On Tue, Aug 19, 2008 at 1:05 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: >> > but >> > programming in Mathematica is not fun. >> >> And that would be the understatement of the week. I don't think you're strange, I was just joking a bit. Caveat: it's been years that I've *programmed* in Mathematica in a serious way (recently I've mostly used it as a fancy calculator for quickly computing integrals I'm too lazy to do by hand). But having said that, what I really found Mathematica programming to be was a very mixed experience: certain things that should be easy were unjustifiably tricky to achieve, even after consulting with local hard-core gurus. But the elegance with which you can manipulate expressions *structurally* is truly something to behold. This comes courtesy of the lisp-like facilities you have for accessing any entity, working on it as an expression tree you can manipulate with very powerful transformation rules. And there are classes of problems where that approach allows you to get pretty much exactly the solution you're after with a minimum amount of fuss, where as in more conventional languages it would be a lot of work. So there, I hope this is a slightly more reasoned reply to a topic worthy of an honest answer ;) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: axiom
On Tue, Aug 19, 2008 at 1:05 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > but > programming in Mathematica is not fun. And that would be the understatement of the week. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: remove or hide a method?
Hi William, On Thu, Jul 17, 2008 at 1:32 PM, William Stein <[EMAIL PROTECTED]> wrote: >> sage: class Foo(object): >> : def trait_names(self): >> : return ['a','b','c','d'] >> : >> sage: a = Foo() >> sage: a. >> a.aa.ba.ca.da.trait_names >> >> As a user, I don't know whether or not I would prefer a "customized" >> tab completion. > > trait_names doesn't currently allow one to cover up existing names > from appearing in the tab completion list. However, I'm certain > Fernando Perez could make it so IPython could call some function > like trait_names that would allow one to cover up certain > attributes. Fernando -- what do you think? The trait_names thing noticed above is a coincidence: it's just an artifact of the fact that ipython happens to hide a bunch of extra attributes with which the Traits library pollutes all objects that inherit from it. Someone stumbled upon it and thought it was some kind of tab-completion API :) But IPython *does* have custom tab completers. This file contains examples and pointers for how to write your own: http://bazaar.launchpad.net/~ipython/ipython/trunk/annotate/1041?file_id=ipy_completers.py-20080216095032-xb0is4a97lmosv2z-148 so it should be possible for the end user to customize completion to his heart's content. If the existing API doesn't work for some specific case, let us know and we'll treat it as a bug. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to run Sage in a system wide Python
On Tue, Jul 8, 2008 at 10:21 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > On Wed, Jul 9, 2008 at 2:29 AM, François Bissey <[EMAIL PROTECTED]> wrote: >> >> On Wed, 09 Jul 2008, Ondrej Certik wrote: >>> The only remaining annoying thing is this one LD_LIBRARY_PATH thing. >>> I'll probably put it to my .bashrc, as there doesn't seem to be any >>> way around it. >>> >> It's probably better to make a small launcher script setting the variable >> correctly. I have seen .*shrc littered with stuff (users in physical >> chemistry), in the end it is difficult to know if some settings contradict >> others. >> I now actively encourage them to write a small launcher script instead. > > I see. Well, one can just use "sage" as the launcher script. The > problem in my case was to get rid of the launcher script, so that I > can use tools > like py.test or nosetests. doesn't import os os.environ['LD_LIBRARY_PATH'] = "/home/ondra/ext/sage/local/lib" (or a suitable variation thereof) in your $PYTHONSTARTUP work? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Python/Sage minisymposium at SIAM Annual meeting July 9/10 2008
Hi all, this is just a reminder, in case you'll be attending the SIAM 2008 annual meeting next week in San Diego, that there will be a 3-part minisymposium focusing on the uses of Python and Sage in scientific computing: http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7369 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7370 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7447 We hope to see many of you there! Regards, Fernando and Randy --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 10:35 AM, William Stein <[EMAIL PROTECTED]> wrote: > > On Tue, Jun 24, 2008 at 10:30 AM, Fernando Perez <[EMAIL PROTECTED]> wrote: >> >> On Tue, Jun 24, 2008 at 10:09 AM, William Stein <[EMAIL PROTECTED]> wrote: >>> >> >>> Anyway, since every single person voted +1 and nobody voted -1 or >>> had issues, I declare this package officially accepted. >> >> My only suggestion would be to use the version that will be used for >> inclusion into python itself: >> >> http://www.python.org/dev/peps/pep-0371/ >> >> (it will be called multiprocessing, for one). That way everyone will >> use the future-proof API and you'll be able to simply drop it from >> Sage once it's included in the underlying Python. I'm not sure how >> much the API has changed for the merge, but I know they were >> discussing a few small name fixes. > > I don't understand your email, since as far as I can tell the version > that will be > included in Python itself doesn't exist yet. The PEP just describes > the version > for Python in the abstract. I couldn't find a link to any actual finished > code > that completely implements that version. This is a start: http://archives.free.net.ph/message/20080610.191155.321829bc.fi.html ( the relevant links are there) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 10:09 AM, William Stein <[EMAIL PROTECTED]> wrote: > > Anyway, since every single person voted +1 and nobody voted -1 or > had issues, I declare this package officially accepted. My only suggestion would be to use the version that will be used for inclusion into python itself: http://www.python.org/dev/peps/pep-0371/ (it will be called multiprocessing, for one). That way everyone will use the future-proof API and you'll be able to simply drop it from Sage once it's included in the underlying Python. I'm not sure how much the API has changed for the merge, but I know they were discussing a few small name fixes. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Citing Sage and Used Systems
Howdy,
On Tue, May 27, 2008 at 5:42 PM, mhampton <[EMAIL PROTECTED]> wrote:
>
> I've made a trac ticket, #3317, to help organize some sort of
> solution(s) to this problem.
Great!
>> Parsing this could be the start of a useful summary of functionality
>> used for a given computation: at least knowing what components were
>> used for the most time consuming parts and the most frequently called
>> functions (not necessarily the same thing, so both are important)
>> would be a decent starting point.
I should clarify what I mean by 'parsing'. The result of the profile
run is an object with a fair amount of info, and that's the object one
would analyze to summarize this information. Here's just a brief
summary for reference. Consider running some trivial code that prints
this:
In [11]: run scopes.py
foo in bar: 1
foo_perm in bar: 1
foo in bar: 2
foo_perm in bar: 1
You then run it with -p, and -r to request the profile object to be
returned (stdout gets a bit messed up by the profiler, but never
mind):
In [12]: run -pr scopes.py
foo in bar: 1
foo_perm in bar: 1
foo in bar: 2
foo_perm in bar: 1
6 function calls in 0.000 CPU seconds
Ordered by: internal time
ncalls tottime percall cumtime percall filename:lineno(function)
10.0000.0000.0000.000 {execfile}
20.0000.0000.0000.000 scopes.py:5(bar)
10.0000.0000.0000.000 scopes.py:3()
10.0000.0000.0000.000 :1()
10.0000.0000.0000.000 {method 'disable' of
'_lsprof.Profiler' objects}
Out[12]:
Now, just capture that profile info object and play with it:
In [13]: prof = _
In [14]: prof.
prof.addprof.load_stats prof.sort_arg_dict
prof.all_calleesprof.max_name_len
prof.sort_arg_dict_default
prof.calc_callees prof.prim_calls prof.sort_stats
prof.dump_stats prof.print_call_heading prof.sort_type
prof.eval_print_amount prof.print_call_lineprof.stats
prof.fcn_list prof.print_callees prof.stream
prof.files prof.print_callers prof.strip_dirs
prof.get_print_list prof.print_line prof.top_level
prof.get_sort_arg_defs prof.print_statsprof.total_calls
prof.get_top_level_statsprof.print_titleprof.total_tt
prof.init prof.revers
The pstats module
http://docs.python.org/lib/module-profile.html
has a bunch of utilities to manipulate these objects as well.
HTH,
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Citing Sage and Used Systems
On Tue, May 27, 2008 at 4:18 PM, Mike Hansen <[EMAIL PROTECTED]> wrote: > As someone who is "upstream", did you have any specific ideas / > examples in mind? This is certainly not an easy problem if one wants a '100%' solution, in the sense that tracking down every single line of code in any given computation isn't easy. But here's a quick idea that can give an '80%' solution for all in-process sage/python/extension code (it won't work for code done by external processes like maxima, I'm afraid). If you run in the ipython console a program via '%run -p' it will be executed under the control of the profiler, and the result will tell you what functions were called, how many times, etc. Similarly %prun lets you execute single statements with profiler control. The profiler results object can be returned and analyzed further, if I recall correctly there is some information in there about where functions come from. Parsing this could be the start of a useful summary of functionality used for a given computation: at least knowing what components were used for the most time consuming parts and the most frequently called functions (not necessarily the same thing, so both are important) would be a decent starting point. The way ipython does it is a fairly naive and thin wrapper on the existing python profiling code, I'm sure one can easily to better with minimal work. I just toss it in as an idea for an approach that could cover part of the problem. There's a second aspect to this whole question, which I think is simply maintaining good practices of upstreaming patches from Sage into their respective components when it makes sense. There's an angle of Sage which is a bit 'linux distro-like', and in that regard the usual ideas about upstreaming vs. carrying local modifications apply. Upstreaming is more work and more time consuming, but ultimately benefits everyone (cf the recent Debian security debacle with SSL which would have been avoided if the offending patch had been upstreamed, where it would have been stopped cold). I don't know how frequently Sage devs contribute patches back to say (I'm just mentioning the ones I'm more familiar with, the same applies to anything else) numpy, scipy, matplotlib and related. For example: I recently needed to use graph theory stuff, so I went and installed networkx. I also noticed that Sage had some extra graph functionality, but I needed to use the code outside of Sage. In the end it didn't matter to me, because plain networkx did what I wanted. But I was left wondering exactly how much 'extra' did Sage have on top of networkx, why it hadn't been upstreamed, if the Sage graph functionality should be considered a fork of networkx, etc. This is a concrete example that I happened to run into recently: I have no idea how the networkx devs feel about it or if Sage has submitted patches, so I'm not accusing anyone of anything, I just mention it from the user's point of view (me in this case). As an outside user who sees both projects, I would have imagined that Sage would have contributed the graph functionality back upstream. Perhaps when there's a reason for not doing so, briefly mentioning it in the Sage docs would help clarify to everyone what the relationship between both projects is. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Citing Sage and Used Systems
On Tue, May 27, 2008 at 4:18 PM, mhampton <[EMAIL PROTECTED]> wrote: > > My intention was to sound hopeful rather than lazy; my apologies if my > tone was not clear. I completely agree that it is important to > provide full credit, and that is the whole reason I am spending time > writing on this thread, and why I brought up the citation command in > R. For my own papers I plan on citing every package that I use, and I > would like it to be easier to determine what those are. No offense taken on my part, I just wanted to bring it up quickly so it would be clear, also for others and readers of archives of the list, where the project stands. This can be a sensitive topic for people and your assurances/clarifications here do have value, I think. So thanks for taking the time to provide them. 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://www.sagemath.org -~--~~~~--~~--~--~---
