On Oct 18, 6:16 am, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
Hi Robert,
> No cleanup function is ever generated, but atexit sounds perfect.
Good that you seem to agree with my analysis. I ran across it be sheer
accident while looking at some linker issue that roed asked me about.
> I'm the
On 10/17/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> How about replace_right instead of change_right.
>
> How about
>
> eqn.expand() # does it to both sides
> eqn.expand('right') # does it to the right
> eqn.expand('left') # does it to the right
>
> Basically, every function valid on a symbo
No cleanup function is ever generated, but atexit sounds perfect. I'm
the obvious person to implement this, I'll see if I can find the time
to do so soon.
- Robert
On Oct 17, 2007, at 9:04 PM, mabshoff wrote:
>
> Hello,
>
> for every module Cython generates "runtime support code" that is p
Hello,
for every module Cython generates "runtime support code" that is place
at the end of the converted file. Each one of those has an
__Pyx_Import function that gets called from
PyMODINIT_FUNC init$MODULENAME(void)
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list) {
PyOb
On 10/17/07, mabshoff > recently we have started using [tested by ..]
in trac. This seems to
> have lead to some misunderstanding, see
> http://www.sagetrac.org/sage_trac/ticket/910
> [but I have fixed that now, see check out the log toward the end]
>
> The idea behind [tested by ...] is not that
Hello,
recently we have started using [tested by ..] in trac. This seems to
have lead to some misunderstanding, see
http://www.sagetrac.org/sage_trac/ticket/910
[but I have fixed that now, see check out the log toward the end]
The idea behind [tested by ...] is not that the original author of a
On Oct 17, 2007, at 6:54 PM, David Harvey wrote:
> On Oct 17, 2007, at 9:50 PM, William Stein wrote:
>
>>
>> On 10/17/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
>>>
Bobby and I don't really like
sage: a.rhs.expand()
since it's a hackish abuse of notation and it is confusing to
On Oct 17, 2007, at 9:50 PM, William Stein wrote:
>
> On 10/17/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
>>
>>> Bobby and I don't really like
>>>sage: a.rhs.expand()
>>> since it's a hackish abuse of notation and it is confusing to read.
>>> It's clever though (which is not good).
>>
>> I
On 10/17/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
>
> > Bobby and I don't really like
> >sage: a.rhs.expand()
> > since it's a hackish abuse of notation and it is confusing to read.
> > It's clever though (which is not good).
>
> I agree with that sentiment. On the other hand, I think
>
>
On 10/17/07, Carl Witty <[EMAIL PROTECTED]> wrote:
> TRAC is down (6:07 PM on Wednesday).
>
Hey, I just wrote a script so trac will restart itself immediately
when it crashes
or is otherwise terminated, i.e., now trac is immortal:
#!/usr/bin/env python
import os
os.system("killemall sage_trac")
> Bobby and I don't really like
>sage: a.rhs.expand()
> since it's a hackish abuse of notation and it is confusing to read.
> It's clever though (which is not good).
I agree with that sentiment. On the other hand, I think
sage: c = b.change_right(b.right().expand())
is a bit cumbersome.
William wrote:
> So you like the suggestion to do
> b.change_right(...)
> and
> b.change_left(...)
> each of which returns a new equation?
Lets see:
c = b.change_right(b.right().expand())
This looks like it will work :-)
Thanks,
Ted
--~--~-~--~~~---~--~
On 10/17/07, Ted Kosan <[EMAIL PROTECTED]> wrote:
> So if simple attribute access is okay to do in Python, why are _right
> and _left private?
Equations are immutable, so you should *not* be changing the internal
state of equations. Actually _left and _right aren't private, they are just
"you
William wrote:
> SymbolicEquations are immutable, i.e., if you want to do something
> to change an equation you should get back a new equation object.
> The _left and _right are "private"-ish, because you are *not* supposed to
> change them. For example, when you do:
>
>b._right = b._right.e
How about having instance variables lhs and rhs which are thin
wrappers around _left and _right which return new SymbolicEquations.
That way you can do things like this:
sage: a = (16*x - 13)/6 == (3*x + 5)/2 - (4 - x)/3
sage: a *= 6
sage: a.rhs.expand()
16*x - 13 == 11*x + 7
I would also want t
On 10/17/07, Ted Kosan <[EMAIL PROTECTED]> wrote:
> It also shows how I am wanting to use expand() with a SymbolicEquation
> object. This approach seems to work fairly well except for the fact
> that SymbolicEquation's _left and _right instance variables are
> private. If these variables were p
Willam wrote:
> I like all of your suggestions above. Could you please give an example
> fake Sage session in which you illustrate use of each of the commands
> you wish Sage had? Implementing the functionality should then be
> easy for me, Bobby, or Mike Hansen (or you). But it would be good
On 10/17/07, John Voight <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> We did a fresh install of RHEL 5 and tried to install sage-2.8.6 (and .
> 7), and we got the following error message:
>
> The SAGE install tree may have moved.
> Regenerating Python.pyo and .pyc files that hardcode the install
Hello all,
We did a fresh install of RHEL 5 and tried to install sage-2.8.6 (and .
7), and we got the following error message:
The SAGE install tree may have moved.
Regenerating Python.pyo and .pyc files that hardcode the install PATH
(please wait less than a minute)...
Please do not interrupt t
Hello,
this Saturday, October 20th 2007, starting at 10am pacific standard
time will be Bug Day 4. It will go on officially for about 10 hours,
but it is pretty much open ended ;). Everybody is welcome to join in
#sage-devel and discuss, report and hopefully fix lots of bugs
If you are interes
> I guess this leads to another question then...is there any desire to
> removing the tight coupling? As I'm sure many programmers have been
> taught, tight coupling isn't a good practice...sorry if that sounds
> pompous or arrogant, it isn't meant to be.
I don't think the coupling is that tight
I guess this leads to another question then...is there any desire to
removing the tight coupling? As I'm sure many programmers have been
taught, tight coupling isn't a good practice...sorry if that sounds
pompous or arrogant, it isn't meant to be.
--~--~-~--~~~---~--~
On Oct 17, 7:45 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 10/17/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
>
> > I just upgraded to Ubuntu 7.10, and I have some issues building the NTL
> > wrapper.
>
> Try moving your sage-main repository and trying again with a clean one, then
> pull
On 10/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> The short answer is, because that's what either William, Alex Clemesha, or I
> did when the notebook had about a hundred lines of javascript associated with
> it. And nobody has bothered to change it since. I've never considered it
The short answer is, because that's what either William, Alex Clemesha, or I
did when the notebook had about a hundred lines of javascript associated with
it. And nobody has bothered to change it since. I've never considered it to
be a problem, and it makes sense in css.py since substitutions
On 10/17/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
> I just upgraded to Ubuntu 7.10, and I have some issues building the NTL
> wrapper.
Try moving your sage-main repository and trying again with a clean one, then
pull in the changes in your personal repository. I had the same problem, and
this
On 10/17/07, Bobby Moretti <[EMAIL PROTECTED]> wrote:
>
> Is there any reason that a .js file could not be placed in the same
> directory as the server code, as part of the main source repository?
>
In the Knoboo source code, images, js files, html files, css files,
python files, etc are intermix
Is there any reason that a .js file could not be placed in the same
directory as the server code, as part of the main source repository?
-Bobby
On 10/17/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> Yes, it is under a different repository. The advantage of placing it
> under the main one, h
I just upgraded to Ubuntu 7.10, and I have some issues building the NTL wrapper.
g++ -o src/ntl_wrap.os -c -fPIC -I/opt/sage/local/include
-I/opt/sage/local/include/python2.5 -I/opt/sage/local/include/NTL
-Iinclude src/ntl_wrap.cpp
src/ntl_wrap.cpp: In function 'NTL::ZZ_pX ZZ_pE_to_ZZ_pX(ZZ_pE)':
Yes, it is under a different repository. The advantage of placing it
under the main one, however, is that much of it seems tightly coupled
to the python source in that same repository, so one could commit
javascript and python server changes in sync.
- Robert
On Oct 17, 2007, at 9:48 AM, T
> Perhaps this could be written to use the new rdef function code, to
> make it easier for the user to provide a cdef function to the solver.
>
That would be great. As a short term alternative, I think I will
write my own simple 4th-order Runge-Kutta solver in cython, but it
would be nice to be
Isn't extcode also under revision control. The plain txt js file would
be located in extcode right?
On 10/17/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> I actually had this question too. Was it just to place it under the
> main sage revision control?
>
> - Robert
>
> On Oct 17, 2007, at 6:
I actually had this question too. Was it just to place it under the
main sage revision control?
- Robert
On Oct 17, 2007, at 6:46 AM, Matt F wrote:
>
> Hi -
>
> I'm new to Sage and I was just wondering why the javascript for the
> notebook was all placed in a string rather than just a javascr
Hi -
I'm new to Sage and I was just wondering why the javascript for the
notebook was all placed in a string rather than just a javascript file
or straight embedding into the web pages.
Thanks for any response.
--~--~-~--~~~---~--~~
To post to this group, send e
> > > > > I understand. It would indeed be god to have some sort of "preparse
> > > > > then import" command. Any suggestions for how it would work (i.e.,
> > > > > from the user's point of view)? Making
> > > > > import foo
> > > > > work if foo.sage is there isn't really an option, sinc
On 10/17/07, Pierre <[EMAIL PROTECTED]> wrote:
> or the load command could exactly replace import, so that
>
> load foo
>
> would load foo.sage in the namespace foo after preparsing, while the
> current behavior of load would be achieved by
>
> from foo load *
>
> And "load foo as bar" would work
On 10/17/07, Pierre <[EMAIL PROTECTED]> wrote:
>
> a 'sage-import' command would also make a lot of sense.
>
Something like that definitely makes sense.
What about
load foo.sage
to load as usual, and
sage_import foo.sage
to do the same as load but put everything in the foo namespace?
I
On 10/16/07, TrixB4Kidz <[EMAIL PROTECTED]> wrote:
> > I would suggest not to actually use unixy infrastructure to create the
> > users. But that certainly involves a decent amount of coding to do
> > your own user creation/permission management and so on. Trying to
> > secure unix user accounts s
On 10/16/07, mabshoff <[EMAIL PROTECTED]> wrote:
> On Oct 17, 1:09 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> > On 10/16/07, Timothy Clemans <[EMAIL PROTECTED]> wrote:
> > You're right; that's exactly what I want to do. I want to make it so the
> > working pool sage* users can't use the net
39 matches
Mail list logo
