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 network in any
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 seems
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/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 as well. (I
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, since Python
directly
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
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 javascript
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:46 AM,
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
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,
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
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 intermixed.
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
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
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 to
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 in the
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 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
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
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
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 PATH
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
to
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
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.expand()
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
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.
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)
cmd
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
sage: c =
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 agree with that
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 read.
It's clever
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
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 the
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) {
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 place
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 symbolic
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
36 matches
Mail list logo
