On 2013-02-25 22:55, Stefan wrote:
> Hi all,
>
> A few others and me have been working for some time now to get matroids
> into Sage. We are getting close to the stage where we can submit the
> code to Trac for review. Testing today revealed one failing doctest
> elsewhere in Sage after we add our
Hi all,
A few others and me have been working for some time now to get matroids
into Sage. We are getting close to the stage where we can submit the code
to Trac for review. Testing today revealed one failing doctest elsewhere in
Sage after we add our code. The reason is that, in our code, we d
On Mon, Feb 25, 2013 at 3:52 AM, Jason Grout
wrote:
> On 2/23/13 6:32 PM, Benjamin Jones wrote:
>
>> I've been working (somewhat slowly) on an implementation of
>> Bronstein's pmint (Poor Man's Integrator) in Sage. I'd heard a while
>> back that someone's student had done an implementation of it i
Hi Volker and other polyhedron fans,
Just wanted to bring attention on the following small tickets that
need review:
- #14175 Fix warning in color option for 2D polyhedron
- #14176 Use standard Python operators for intersection of polyhedrons and
membership testing
- #14181 Add outline=F
Hi Volker,
On 2013-02-25, Volker Braun wrote:
> Deprecation is for user-visible functionality. No need to deprecate hash
> implementation details, otherwise it'll be total and immediate development
> standstill.
Great! That makes it easier...
Cheers,
Simon
--
You received this message becau
On 2013-02-24, Benjamin Jones wrote:
> I've been working (somewhat slowly) on an implementation of
> Bronstein's pmint (Poor Man's Integrator) in Sage. I'd heard a while
> back that someone's student had done an implementation of it in Sage,
> but I don't know if it was released. Does anyone have
Deprecation is for user-visible functionality. No need to deprecate hash
implementation details, otherwise it'll be total and immediate development
standstill.
On Monday, February 25, 2013 6:30:19 AM UTC-8, Simon King wrote:
>
> At #11900, we have introduced a cdef class
> sage.categories.cat
Hi,
in fact, I have been considering the usage of
"$SAGE_LOCAL/toolchain/toolchain-env", but it is not in the "right place"
in "sage-env" (the "PATH" is set but the "LD_LIBRARY_PATH", "CPATH",
"MULTI_ARCH" are not; even if one sets some variables, like "PYTHONPATH",
they will be overwritten; if
Hi!
At #11900, we have introduced a cdef class
sage.categories.category_singleton.FastHashable_class, which to my
knowledge has only been used to provide a fast hash to the class
CategorySingleton.
However, the default hash for instances of UniqueRepresentation
introduced in #14054 would be *fast
leif wrote:
Alternatively, you could create scripts in $SAGE_LOCAL/bin/, which set
up what you need and then run Sage, but you'd have to start/run these
with './sage -c '.
Ooops, './sage --sh ' of course.
(Since $SAGE_LOCAL/bin shouldn't be in your PATH, because the scripts
there are supposed
JMH wrote:
Hi,
well, in general I could imagine that my "extra" package gets installed
into the "standard" Sage subdirectories (so that there would be no need
to set "PATH", "LD_LIBRARY_PATH", "PYTHONPATH", ...).
However, this is not really the desired situation.
In fact I need to make sure that
Hey,
On Monday, February 25, 2013 12:40:40 PM UTC+1, jason wrote:
>
> I typically use emacs or the online notebook. I've used Eclipse before
> as well.
>
Me too. I normally prototype in the notebook and move to a file and work in
emacs when the size of the code gets big enough.
In case it is
JMH wrote:
Hi,
On Sunday, February 24, 2013 11:37:47 PM UTC+1, leif wrote:
The latter should be (and IIRC used to be) the correct behaviour.
I'm not sure what you call the "correct behaviour". I can only say that
after I modified the standard "sage-env" script and created a new
"binary ta
Hi,
well, in general I could imagine that my "extra" package gets installed
into the "standard" Sage subdirectories (so that there would be no need to
set "PATH", "LD_LIBRARY_PATH", "PYTHONPATH", ...).
However, this is not really the desired situation.
In fact I need to make sure that I can have
On 2/23/13 6:32 PM, Benjamin Jones wrote:
I've been working (somewhat slowly) on an implementation of
Bronstein's pmint (Poor Man's Integrator) in Sage. I'd heard a while
back that someone's student had done an implementation of it in Sage,
but I don't know if it was released. Does anyone have m
Hi,
On Sunday, February 24, 2013 11:37:47 PM UTC+1, leif wrote:
>
> The latter should be (and IIRC used to be) the correct behaviour.
>
I'm not sure what you call the "correct behaviour". I can only say that
after I modified the standard "sage-env" script and created a new "binary
tarball" ...
On 2/25/13 5:31 AM, Andreas Ruscheinski wrote:
Hello,
can anybody give me some advices for an good development enviroment for
python/sage ? I dont really want to use vim ^^
I typically use emacs or the online notebook. I've used Eclipse before
as well.
Thanks,
Jason
--
You received this
Hello,
can anybody give me some advices for an good development enviroment for
python/sage ? I dont really want to use vim ^^
--
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 a
Hi,
below you can find the releveant part from the "pil-1.1.6.p4.log" file.
As you can see, nothing really bad happened. Just the Tcl/Tk part was not
built.
Best regards,
Jacek.
--
(...)
building '_imagingtk' extension
creating bu
On 2013-02-24 20:57, JMH wrote:
> Also, if you do not think that I should modify the standard "sage-env"
> script, how can I "register" my library in a different way?
> Before I source my "setup" shell script (bash), I need all Sage related
> variables to be set, so the end of the standard "sage-en
20 matches
Mail list logo