The example works for me, i.e., does not crash.
It does leak memory: the entries of adj, the C++ object m, and the returned
clverts. You need to use free(), normal delete, and array delete to
deallocate them respectively. The array delete operator is not available in
Cython, but you can probabl
Alright here is the latest error after running the -b version of build,
doesn't mention any dll's but is it the same issue?
Compiling sage/ext/interpreters/wrapper_el.pyx because it changed.
Cythonizing sage/algebras/letterplace/free_algebra_element_letterplace.pyx
Traceback (most recent call la
Volker,
On Friday, 21 March 2014 19:48:52 UTC+1, Volker Braun wrote:
>
> You must not mix new/delete and malloc/free, that is, the deallocation
> must match the allocation. It sounds really wonky for a C++ library to
> require a malloc'ed buffer as input and returning something array new'ed,
You must not mix new/delete and malloc/free, that is, the deallocation must
match the allocation. It sounds really wonky for a C++ library to require a
malloc'ed buffer as input and returning something array new'ed, though. Are
you sure that this is what your problem is?
The "array new" operato
Volker,
The library in question does need me to pass a C array. I am currently
overcoming the problem by using malloc but fter the library call I get a
corrupt pointer back, that I cannot free. Hence I am trying to see how
would it work with new/delete.
Best,
Jernej
On Friday, 21 March 2014
You aren't even trying to construct a C++ objects. Unless your C++ library
expects C arrays as inputs, I would recommend that you forget about them.
Use STL vectors as containers. See src/sage/tests/stl_vector.pyx for an
example.
On Friday, March 21, 2014 7:41:08 AM UTC-4, Jernej Azarija w
Hi all,
we have been tuning MPIR, but have not been able to access the following
architectures:
* atom
* AMD bobcat (http://en.wikipedia.org/wiki/Bobcat_(microarchitecture)
If you can give us access to one of these, could you let us know on the
mpir-devel Google group.
Note MPIR will run very s
I've spent some time looking through the fast_callable.pyx file and here is
what I think the issue is.
The expression builder keeps track of the 'constants' it has come across so
far in a dictionary. When it gets to a new power (or constant) it first
checks if it is in the dictionary and uses t
On Friday, March 21, 2014 5:45:04 PM UTC+6, Dima Pasechnik wrote:
> On 2014-03-21, Дима Щербаков wrote:
>
> > I'm trying to compile Sage on my notebook (i7 4700MQ, 8gb RAM, Nvidia
> > GTX765M if relevant) OS is Debian Jessie 64 bit (current testing).
>
> > REPRODUCIBLE: ALWAYS
>
> > SEVERITY:
Simon gave me some hints how to integrate the new class into the category
framework, so the ticket now *needs review* hint hint:
http://trac.sagemath.org/ticket/15976
On Wednesday 19 Mar 2014 17:38:42 Martin Albrecht wrote:
> Next update:
>
> I decided that the 2012 Sage GSoC project [^1] wasn'
On 2014-03-21, Дима Щербаков wrote:
> I'm trying to compile Sage on my notebook (i7 4700MQ, 8gb RAM, Nvidia GTX765M
> if relevant) OS is Debian Jessie 64 bit (current testing).
> REPRODUCIBLE: ALWAYS
> SEVERITY: IMPORTANT
>
> every time I'm trying to "make" it ends with (sorry, I don't know how t
Hello,
I would like to write a Cython wrapper for a C++ library. Since the library
in question requires me to pass C++ objects, I am trying to figure out how
to do it in Cython. I am having some trouble using the construct new.
The minimal example of the problem being resembled by the followin
I'm trying to compile Sage on my notebook (i7 4700MQ, 8gb RAM, Nvidia GTX765M
if relevant) OS is Debian Jessie 64 bit (current testing).
REPRODUCIBLE: ALWAYS
SEVERITY: IMPORTANT
every time I'm trying to "make" it ends with (sorry, I don't know how to make
spoiler):
**
I suggest that you upgrade to the develop branch using the following, when
a new develop version is released:
# Assuming you are in SAGE_ROOT
$ git checkout develop
$ ./sage -upgrade develop
These two lines are at the core of a zsh function in my ~/.zshrc. The full
function can be found here:
Am 2014-03-18 18:28, schrieb Clemens Heuberger:
> I'd really hate if a computation that I believe to be exact using RIF
> gets inadvertently inexact by overlooking an automatic coercion
> RR->RIF.
>
> On the other hand, I would not have an automatic coercion from RIF to
> RR (to which element of R
15 matches
Mail list logo
