On 2012-12-20 01:50, P Purkayastha wrote:
> #12798 is another ticket which gave trouble on solaris and was working
> just fine otherwise. I just gave up on that ticket. Perhaps you can try
> and see if it works with OpenIndiana. If it works on OpenIndiana, this
> would make it the second ticket whi
On 12/20/2012 04:19 PM, Jeroen Demeyer wrote:
On 2012-12-20 01:50, P Purkayastha wrote:
#12798 is another ticket which gave trouble on solaris and was working
just fine otherwise. I just gave up on that ticket. Perhaps you can try
and see if it works with OpenIndiana. If it works on OpenIndiana,
Hell everybody !!!
Martin Albrecht just created a patch to include sage.sat in our reference
manual, and wrote some documentation inside of the .rst file, while I only
ever saw it used as a table of contents.
Here's the file :
http://trac.sagemath.org/sage_trac/attachment/ticket/13851/tra
T_T
"Are tests run" T_T
Sorryy !!
Nathann
--
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...@google
On 19 December 2012 23:16, Charles Bouillaguet
wrote:
> On Dec 19, 2012, at 12:44 PM, John Cremona wrote:
>
>
> ---
> Charles Bouillaguet
> http://www.lifl.fr/~bouillaguet/
>
>
>
>> I suggest adding to the documentation of A.coordinates() that it works
>> also if the given element is in the ambien
Yes, those tests are run.
--
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
> Yes, those tests are run.
Cool ! Thanks ! :-)
Nathann
--
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...@googl
Hi all,
I (amongst with others) have written a library that solves boolean
equations in some way. I wanted to include it as an experimental spkg. I
thus wrote a cython interface to Sage. To be usable from inside Sage,
both the library itself and the cython interface are necessary. What is
the
Hi Charles,
On Thu, 20 Dec 2012 12:37:33 +0100
Charles Bouillaguet wrote:
> I (amongst with others) have written a library that solves boolean
> equations in some way. I wanted to include it as an experimental
> spkg. I thus wrote a cython interface to Sage. To be usable from
> inside Sage, bot
On 12/20/2012 01:02 PM, Burcin Erocal wrote:
What should I do ? Unconditionally include the cython interface to
the sage library, and mark all doctests as optional ?
Can you compile the Cython interface without the header files installed
by your package?
No
I assume the Cython interface nee
> Wouldn't it be easier to include the Cython interface in the package?
> AFAIK, Cython's build system improved significantly and there is no
> reason to use Sage's build system for a Cython module.
Hi Burcin,
my understanding is that Charles was more specifically asking about including
his expe
On 20 December 2012 08:41, P Purkayastha wrote:
> On 12/20/2012 04:19 PM, Jeroen Demeyer wrote:
>>
>> On 2012-12-20 01:50, P Purkayastha wrote:
>>>
>>> #12798 is another ticket which gave trouble on solaris and was working
>>> just fine otherwise. I just gave up on that ticket. Perhaps you can try
It is common practice to encode missing/invalid data points as NaN, see for
example the NaN toolbox for Matlab/Octave
(http://pub.ist.ac.at/~schloegl/matlab/NaN/). Having arbitrary base grids
would be nice, of course, but certainly comes at a significant performance
cost. Ideally there would be
Le 20/12/2012 13:35, Volker Braun a écrit :
It is common practice to encode missing/invalid data points as NaN, see
for example the NaN toolbox for Matlab/Octave
(http://pub.ist.ac.at/~schloegl/matlab/NaN/). Having arbitrary base
grids would be nice, of course, but certainly comes at a significan
On Thu, 20 Dec 2012 13:15:38 +0100
Charles Bouillaguet wrote:
> On 12/20/2012 01:02 PM, Burcin Erocal wrote:
> >> What should I do ? Unconditionally include the cython interface to
> >> the sage library, and mark all doctests as optional ?
> >
> > Can you compile the Cython interface without the
> I am not suggesting to patch the Sage library when installing your
> package. You can put the interface in a separate Cython module which is
> built by the usual Python/Cython setup.py magic and installed in the
> system python module directory. Then people will be able to import your
> module fr
On 2012-12-20 13:35, Volker Braun wrote:
> It is common practice to encode missing/invalid data points as NaN
In the input data perhaps, but once you're actually drawing polygons
it's a waste of cycles.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" gro
On 2012-12-20 14:10, Charles Bouillaguet wrote:
> Again, what should I do :) ?
The question is really: what to do with *documentation* of
optional/experimental packages, should it be amongst the Sage
documentation? If YES, then indeed all doctests need to be marked optional.
--
You received this
Hi Martin,
On Thu, 20 Dec 2012 13:15:51 +0100
Martin Albrecht wrote:
> > Wouldn't it be easier to include the Cython interface in the
> > package? AFAIK, Cython's build system improved significantly and
> > there is no reason to use Sage's build system for a Cython module.
>
> my understanding
On Thu, 20 Dec 2012 14:10:55 +0100
Charles Bouillaguet wrote:
> > I am not suggesting to patch the Sage library when installing your
> > package. You can put the interface in a separate Cython module
> > which is built by the usual Python/Cython setup.py magic and
> > installed in the system pyth
On 20 December 2012 12:35, Volker Braun wrote:
> It is common practice to encode missing/invalid data points as NaN, see for
> example the NaN toolbox for Matlab/Octave
> (http://pub.ist.ac.at/~schloegl/matlab/NaN/).
That is a toolbox written to handle NaN to do this in a defined way
for MATLAB a
On 12/20/2012 08:26 PM, David Kirkby wrote:
On 20 December 2012 08:41, P Purkayastha wrote:
I have explained in the last post in the ticket why NaNs or Infs are
required. I don't know of any other way to represent "invalid" points on a
*square* grid.
I think you have just provided an excellen
Hi All,
On 2012-12-20, Burcin Erocal wrote:
> On Thu, 20 Dec 2012 14:10:55 +0100
> Some examples of Python/Cython packages that depend on Sage:
>
> http://sage.math.washington.edu/home/SimonKing/Cohomology/
As author of this package, I can confirm that it works easily to create
Cython modules in
Just some on-topic humor to lighten the mood (thanks to Harald Schilly on
G+):
[vbraun@volker-desktop ~]$ js
js> print({}) // empty object
[object Object]
js> {} + {}
NaN
True since its definitely not a number!
On Thursday, December 20, 2012 12:35:05 PM UTC, Volker Braun wrote:
>
> It is c
Le 20/12/2012 15:42, Volker Braun a écrit :
Just some on-topic humor to lighten the mood (thanks to Harald Schilly
on G+):
[vbraun@volker-desktop ~]$ js
js> print({}) // empty object
[object Object]
js> {} + {}
NaN
True since its definitely not a number!
Eh, if you want to lighten the mood
On Thursday, December 20, 2012 3:20:26 PM UTC, Snark wrote:
> If a platform has someone working on it and manages to make sage both
> compile and work reasonably well (hem... the sage port still has a few
> quirks), then there's little reason to ditch it.
Again, I'm not saying to drop support
On 2012-12-20 16:30, Volker Braun wrote:
> You need to manually install
> a good chunk of the gnu tools to make it look mostly like Gnu/Linux,
> then you can compile Sage.
At least, the situation has only improved recently. Thanks to the GCC
spkg, you can use the Sun compiler for example.
--
You
On Thursday, December 20, 2012 3:40:48 PM UTC, Jeroen Demeyer wrote:
> At least, the situation has only improved recently. Thanks to the GCC
> spkg, you can use the Sun compiler for example.
You still can't use the gcc that OpenIndiana ships by default (dies in
libz).
Besides, the fact that S
On Saturday, October 6, 2012 11:56:06 PM UTC+2, Jeroen Demeyer wrote:
>
> Since we just got another report of #11391, I would like to propose
> again to add GNU m4 as standard package. The only possible argument
> against it would be that it makes the Sage source about 1MB larger...
>
> On 20
Le 20/12/2012 17:27, Jean-Pierre Flori a écrit :
Ideally, from my point of view, I would prefer to have a completely
modular Sage and just do "apt-get install sage" but I fear it won't
happen soon.
We're already a few working on it and things are progressing slowly.
You're welcome to join in t
On Thursday, December 20, 2012 5:52:33 PM UTC+1, Snark wrote:
>
> Le 20/12/2012 17:27, Jean-Pierre Flori a �crit :
> > Ideally, from my point of view, I would prefer to have a completely
> > modular Sage and just do "apt-get install sage" but I fear it won't
> > happen soon.
>
> We're alrea
> A gdb backtrace?
buildbot@hawk:~/sage-5.6.beta0$ ./sage -t --long --gdb
"devel/sage/sage/modules/module.pyx"
sage -t --long --gdb "devel/sage/sage/modules/module.pyx"
Type r at the (gdb) prompt to run the doctests.
On Thursday, December 20, 2012 5:52:33 PM UTC+1, Snark wrote:
>
> Le 20/12/2012 17:27, Jean-Pierre Flori a �crit :
> > Ideally, from my point of view, I would prefer to have a completely
> > modular Sage and just do "apt-get install sage" but I fear it won't
> > happen soon.
>
> We're alrea
On 20 December 2012 15:52, Volker Braun wrote:
> You still can't use the gcc that OpenIndiana ships by default (dies in
> libz).
>
> Besides, the fact that Sage can drop all the necessary tools to make
> OpenSolaris it look like x86 GNU on slightly wonky kernel is just another
> point in case tha
Again, I'm not saying to drop support for OpenSolaris or Solaris in
general, but remove it from the list of platforms that must pass all tests
before a release can be made. Really thats only feasible if more than one
person is actively using the platform. (Copy&Paste since nobody reads what
I w
On Thursday, December 20, 2012 12:49:37 PM UTC-5, Volker Braun wrote:
>
> Again, I'm not saying to drop support for OpenSolaris or Solaris in
> general, but remove it from the list of platforms that must pass all tests
> before a release can be made. Really thats only feasible if more than one
Le 20/12/2012 18:46, David Kirkby a écrit :
On 20 December 2012 15:52, Volker Braun wrote:
If the code in Sage conformed to the C and C++ standards, it would
build with a standard C compiler. But C/C++ compilers from Sun/Oracle,
IBM or HP will not compile large portions of Sage, as a lot of the
On Thursday, December 20, 2012 7:31:11 PM UTC+1, Snark wrote:
>
> Le 20/12/2012 18:46, David Kirkby a �crit :
> > On 20 December 2012 15:52, Volker Braun>
> wrote:
> > If the code in Sage conformed to the C and C++ standards, it would
> > build with a standard C compiler. But C/C++ compile
On 3 November 2012 19:58, Nils Bruin wrote:
> Presently, Sage has a significant memory leak issue: Uniqueness of
> parents is currently guaranteed by keeping them in memory
> permanently.
I've compiled Sage on Solaris with Sun libraries which replace
malloc/free with versions which check for memo
mmarco,
Things got pretty crazy and I haven't had a chance to take a look yet, but
I should be able to give it a try in the next day or two. Thank you again
for your help.
On Thursday, December 13, 2012 6:35:52 AM UTC-5, mmarco wrote:
>
> jaebond, did you try the image i linked? did it work fo
On 2012-12-20, Julien Puydt wrote:
> Le 20/12/2012 18:46, David Kirkby a écrit :
>> On 20 December 2012 15:52, Volker Braun wrote:
>> If the code in Sage conformed to the C and C++ standards, it would
>> build with a standard C compiler. But C/C++ compilers from Sun/Oracle,
>> IBM or HP will not
Hi David,
On 2012-12-20, David Kirkby wrote:
> I've compiled Sage on Solaris with Sun libraries which replace
> malloc/free with versions which check for memory leaks. Sage has
> leaked memory before the
>
> sage:
>
> prompt has appeared. But from what I gather, one of the culprits does
> it own
Just a follow up. Did you create a ticket on this? If so, can you mention
the ticket number here?
On Thursday, November 1, 2012 12:42:58 AM UTC+8, Eymen A wrote:
>
>
>
> On Monday, October 29, 2012 10:25:39 PM UTC+1, Volker Braun wrote:
>>
>> Great! Can you make a trac account for yourself and a
On Thu, Dec 20, 2012 at 9:46 AM, David Kirkby wrote:
> On 20 December 2012 15:52, Volker Braun wrote:
>
>> You still can't use the gcc that OpenIndiana ships by default (dies in
>> libz).
>>
>> Besides, the fact that Sage can drop all the necessary tools to make
>> OpenSolaris it look like x86 GN
On 2012-12-21 07:09, Simon King wrote:
> Can you try to install the singular spkg from #13731, after doing
> export SINGULAR_XALLOC=yes
> followed by sage -b, please?
Then singular fails to install:
### Singular spkg-install: build_singular ###
make PIPE= install-nolns in omalloc
make[1]: Enter
On 2012-12-21, Jeroen Demeyer wrote:
> On 2012-12-21 07:09, Simon King wrote:
>> Can you try to install the singular spkg from #13731, after doing
>> export SINGULAR_XALLOC=yes
>> followed by sage -b, please?
>
> Then singular fails to install:
>
> ### Singular spkg-install: build_singular ###
>
Hi,
building sage on a box using SAGE_ATLAS_LIB then running sage -bdist to
get something to run on another box doesn't work: you'll have to install
atlas on the target system too.
Is it documented somewhere, and if not, where should I document it?
Snark on #sagemath
--
You received this me
47 matches
Mail list logo
