of
maintenance work. 65 people contributed to this release.
Congrats!
Only a tiny little thing: the docs still point to 0.12.0:
http://docs.scipy.org/doc/scipy/reference/
Should be fixed now.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
on this behavior (I hope not).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
:
return NotImplemented
Of course, it's written in C so it's a bit more painful to write this.
I think this will have little performance impact, since the check would
be only a NULL check in the inplace op methods + subsequent handling. I
can take a look at some point at this...
--
Pauli
).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
this is no
longer the case?
I guess you are trying to link with MKL? In that case, I would rather
propose restoring the previous MKL wrappers (with trivial extensions
for the missing w* symbols).
- --
Pauli Virtanen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux
24.08.2013 21:25, Warren Weckesser kirjoitti:
[clip]
Now the question is: why does `np.dot` mask the overflow warning?
That probably depends on whatever BLAS is used. I wouldn't be
surprised if it's BLAS that swallows the floating point invalid flags.
--
Pauli Virtanen
that they could cause any breakage.
Getting it in now would have the advantage that we could also manage
to squeeze in the corresponding user-side part inside scipy.sparse for
Scipy 0.13.0.
- --
Pauli Virtanen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux
schedule to get this in 0.13.0, as Ralf is planning to branch that on
next Tuesday.
The Numpy interactions may reveal some surprises, so I'd prefer this
to cook for a while in the dev version.
The best route is probably to postpone until 1.9 and 0.14.0, I think.
- --
Pauli Virtanen
-BEGIN PGP
= get_python_lib(prefix=dst_dir, plat_specific=True)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
installed), etc.
Or:
python runtests.py
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
working on (e.g. 1.7.1 rather
than 1.8dev).
No, runtests builds the code and sets PYTHONPATH accordingly.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
? Is there a 'numpy' directory below the reported directory after
running runtests.py?
(ii)
Start a fresh Python interpreter and run
import sys
print sys.modules.get('numpy')
(Note: no import numpy above). Does it print `None` or something else?
--
Pauli Virtanen
Hi,
How about splitting doc/sphinxext out from the main Numpy repository to
a separate `numpydoc` repo under Numpy project?
It's a separate Python package, after all. Moreover, this would make it
easier to use it as a git submodule (e.g. in Scipy). Moreover, its
release cycle is not in any
24.07.2013 18:33, Pauli Virtanen kirjoitti:
How about splitting doc/sphinxext out from the main Numpy repository to
a separate `numpydoc` repo under Numpy project?
Done:
https://github.com/numpy/numpydoc
https://github.com/numpy/numpy/pull/3547
https://github.com/scipy/scipy/pull/2657
in a way
that leaves leeway for changing the implementation to a view later on.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
is needed.
It is much more rarely used than `ravel()` and `flatten()`, as can be
verified by grepping e.g. the matplotlib source code.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo
which would be confusing.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
the `__array__`
attribute of the flatiter object. If it's faster than .ravel(), that is
surprising.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
20.07.2013 01:38, Nathaniel Smith kirjoitti:
The biggest ~recent change in master's linalg was the switch to gufunc
back ends - you might want to check for that event in your commit log.
That was in mid-April, which doesn't match with the location of the
uptick in the graph.
Pauli
it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
in the
source code has been changed.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
13.07.2013 20:46, Nathaniel Smith kirjoitti:
[clip]
Why not just write
def H(a):
return a.conj().T
In long expressions, this puts H to the wrong side.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
this:
https://github.com/pv/numpy/tree/fortran-abicheck
Interested parties on OSX should check whether they manage to build this
version of Numpy with Accelerate when this is enabled, and whether
Scipy's ARPACK tests still fail when building against this version of Numpy.
--
Pauli Virtanen
Dave Hirschfeld dave.hirschfeld at gmail.com writes:
The example below demonstrates the fact that the datetime64
constructor ignores the dtype argument if passed in. Is this
conscious design decision or a bug/oversight?
Bug. There's probably no dtype argument, but the constructor
just ignores
the appropriate t-value if we
give number of samples ?
The scipy-user mailing list is more appropriate for this question.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
also break 3rd party code.
As far as I see, the options are:
1. Add -ff2c (or whatever is the correct flag for Accelerate)
to the Fortran flags on OSX.
2. Drop support for Veclib/Accelerate.
I think Accelerate was also incompatible with multiprocessing,
which would weigh for option 2.
--
Pauli
LDFLAGS=-ldotwrp -lblas
works? This makes things a bit more complicated to the builder, an
issue that can be solved with documentation, and keeping that up to
date is easier than hardcoding stuff into numpy.distutils.
--
Pauli Virtanen
___
NumPy
12.06.2013 00:29, Ralf Gommers kirjoitti:
[clip]
AFAIK custom compiler flags can be injected via FOPT/FFLAGS/LDFLAGS,
so doing something like
export FOPT=-ff2c
[clip]
Sounds like a good idea. Would still make sense to move Accelerate down
in the list of preferred libs, so
08.06.2013 02:48, Nathaniel Smith kirjoitti:
[clip]
...yeah weird. My gut reaction is that it's a bug. Addition on bools
should either be an error, undefined but doable via an implicit upcast
to int (analogous to calling np.sin on an int array triggering an upcast
to float), or xor (i.e.,
consistent on these platforms.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
of taste.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
called ptp() already in Numeric, i.e., for the last 10+ years. This is
the first proposal to change it that I know of, so I think keeping the
API the same weighs against changing it due to aesthetic reasons.
--
Pauli Virtanen
___
NumPy-Discussion
if the integer is too big to
fit into int64 (or maybe into int32 on 32-bit systems). The behavior is
the same as in Numpy 1.2.0, so it has perhaps been like this forever.
So most likely, the code in Scipy was correct only for 32-bit systems.
--
Pauli Virtanen
/linux.html#generic-instructions
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
pages? They seem to be hurting the
site's performance quite a lot --- for instance,
http://scipy.org/Cookbook doesn't load currently.
A good assumption is probably that new pages created in the past couple
of weeks are all spam...
--
Pauli Virtanen
05.05.2013 15:42, Robert Kern kirjoitti:
[clip: spam]
Manually. I have a whitelist of known-good pages that helps narrow it
down. I'll take care of it in a few hours.
Thanks a lot!
Cheers,
Pauli
___
NumPy-Discussion mailing list
for that. I don't think there is any
other solution to the spam with the Moin wiki at present.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
:
http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
in a
different order than previously. Both results are IMHO correct, so I'm
not sure there is anything to fix here. Third-party code relying on a
certain outcome of rounding error is likely incorrect anyway.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
seem to remember that also the quantities package had some
issues with operations involving ndarrays, to which being able to
override this could be a solution.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
it a shot and see how it works.
protocol=2 so it doesn't needlessly ascii-quote the data.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
],
[3, 1]] ])
np.linalg.det(a)
array([-2., -3., -8.])
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
. On the other hand,
I don't see obvious missing names -- the policy has been to give
commit access for people with sustained code contributions, see also
git shortlog -a -c -s --since=now-2year | sort -n
--
Pauli Virtanen
___
NumPy-Discussion mailing
.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
datetime type. A naive datetime is sort of datetime64[D] plus
HH:MM:SS, but not quite.
***
I think your point about using current timezone in interpreting user
input being dangerous is probably correct --- perhaps UTC all the way
would be a safer (and simpler) choice?
--
Pauli Virtanen
messing with the C API. The backwards
compatibility issue is also just a documentation issue, so nothing drastic.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
explanations are that either the routine called is
different in the two cases, or, the benchmark if somehow faulty.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
and distribution infra is in place for Scipy,
putting it in scipy.linalg makes it more easily available for a larger
number of people than some random 3-rd party module.
We already ship low-level f2py bindings, so I don't see a reason for not
shipping Cython ones too.
--
Pauli Virtanen
. providing
the whole of Scipy :)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
of worms.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
numpydoc raises errors..
Could this be fixed or am I doing something wrong?
Numpydoc hasn't been ported to Python 3 so far. This probably
wouldn't a very large amount of work --- patches are accepted!
--
Pauli Virtanen
___
NumPy-Discussion mailing
Jaakko Luttinen jaakko.luttinen at aalto.fi writes:
The files in numpy/doc/sphinxext/ and numpydoc/ (from PyPI) are a bit
different. Which ones should be modified?
The stuff in sphinxext/ is the development version of the package on
PyPi, so the changes should be made in sphinxext/
--
Pauli
/master/scipy/special/specfun/specfun.f#L1091
It does not have asymptotic expansions for dealing with parts of
the complex plane where the computation via the recurrence does not
work.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
are not
complete, and do not cover the whole complex plane (or the real axis).
Other functions (the more common ones), however, have very good
implementations.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
)
This should solve the problem.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
://mail.scipy.org/mailman/listinfo/scipy-user
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
having compiled code, you can relatively easily wrap the
LAPACK routine you need using f2py.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
potential users towards Github.
Cheers,
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
(..) or np.ndarray(...). It contains whatever that happens to be
at that location. It just happens that typical memory content when
viewed in floating point often looks like that.
[*] Except that the OS zeroes new memory pages given to the process.
Processes however reuse the pages they are given.
--
Pauli
Bob Dowling rjd4+numpy at cam.ac.uk writes:
[clip]
I'm guessing that numpy.where() is evaluating the complete arccos and
arccosh arrays and therefore getting invalid arguments.
Now, I can turn off the warnings with numpy.seterr(invalid='ignore') but
that's not what I would regard as good
identical results from MATLAB (R2011b), Octave, Numpy, and
Scipy. Can you give an example matrix which behaves differently?
Note that Numpy and Scipy return exactly what LAPACK's *GEQRF routines
give, and Octave seems also to do this.
--
Pauli Virtanen
with it is somehow strange.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
)).
Not documented in the Python wrapper, though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
format files inside
them, so you should be able to build them up by stuffing files saved
by np.save() into a zipfile.ZipFile.
However, a better option could be to use a another data format such
as hdf5.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
type(data)
numpy.ndarray
Maybe you have NaNs in the array? (i.e. np.isnan(data) is True)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Larry Paltrow larry.paltrow at gmail.com writes:
[clip]
np.all(~np.isnan(data))
False
Seems to be all non-nan
No, it means you have NaNs in your data.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
with missing select
module when compiling Python.
Apparently the machine you are using is not a standard Redhat installation,
but something on it is strange.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
:
http://continuum.io/downloads.html
http://www.enthought.com/products/epd.php
as suggested earlier in this thread.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
clusters.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
/attachment/ticket/36/numpy-6-norm-change-
default.diff
Seems like the chances of learning the reason why this change was done
are pretty slim.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
Charles R Harris charlesr.harris at gmail.com writes:
On Sun, Oct 14, 2012 at 11:53 AM, Pauli Virtanen pav at iki.fi wrote:
Hi,
I'd like to link both C++ and Fortran code into a single
Python extension, using numpy.distutils (for scipy.special).
But it seems the distutils-based tools
Hi,
I'd like to link both C++ and Fortran code into a single
Python extension, using numpy.distutils (for scipy.special).
But it seems the distutils-based tools actually cannot do this?
Does someone know if there's a way to work around this?
--
Pauli Virtanen
27.09.2012 15:46, David Cournapeau kirjoitti:
[clip]
Ok, so scipy.org was down again because of trac. Unfortunately, the
machine on which scipy.org lives is the same as trac, and is a bit
messy.
Trac runs on new.scipy.org, which AFAIK *is* a different machine from
scipy.org.
Pauli
27.09.2012 21:45, Pauli Virtanen kirjoitti:
27.09.2012 15:46, David Cournapeau kirjoitti:
[clip]
Ok, so scipy.org was down again because of trac. Unfortunately, the
machine on which scipy.org lives is the same as trac, and is a bit
messy.
Trac runs on new.scipy.org, which AFAIK
that. Do I need to reinstall numpy from scratch everytimes
or is there a better way to do that?
Reinstallation is needed, but this is reasonably simple to automate,
check git bisect run. For instance like so:
https://github.com/pv/scipy-build-makefile/blob/master/bisectrun.py
--
Pauli Virtanen
to correct this, it needs a real restart of the
process.)
Longer term solution is to move out of mod_python (mod_wsgi likely, going to CGI
will create other performance problems), or to transition the stuff there to a
more beefy server.
--
Pauli Virtanen
on the point of clumsy administration.
This however leaves the other services still on the machine, although
after dropping Trac, the juice probably is enough for them.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
, complex64, complex128, float64, ...
et al. are types that represent scalar numbers, not arrays. That you get
an array out from `float64(some_array)` rather than a ValueError is
un-Pythonic. Happens to work, but probably for the wrong reasons.
--
Pauli Virtanen
Benjamin Root ben.root at ou.edu writes:
[clip]
a[sl] and a[3:5, 5:14] is equivalent to
sl = (slice(3, 5), slice(5, 14))
a[sl]
[clip]
which is also equivalent to
sl = np.s_[3:5, 5:14]
___
NumPy-Discussion mailing list
misleading ---
since 2008, many of the documentation edits went in the online way, and
these only show up in a single large commit, usually before releases.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
01.06.2012 20:45, Jeremy Lecoeur kirjoitti:
I have been using the sparse matrix tools for a while to do all sort of
things and, using the same code that was working just fine, I now
encounter a problem when trying . I do have very large sparse matrices
and when i multiplying them the number
fall into
a region where the floating point numbers are dense.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
://github.com/pv/scipy-build-makefile
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
]
The backtrace looks like it does not use ACML. Does
from numpy.core._dotblas import dot
work?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
/src/multiarray/multiarraymodule.c:847
This is also not using ACML. You'll need to adjust things until the line
from numpy.core._dotblas import dot
works. CBLAS is indeed needed.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
11.05.2012 17:54, Frédéric Bastien kirjoitti:
In Theano we use a view, but that is not relevant as it is the
compiler that tell what is inplace. So this is invisible to the user.
What about a parameter to diagonal() that default to return a view not
writable as you said. The user can then
05.05.2012 22:53, Ralf Gommers kirjoitti:
[clip]
would be great to get it done by end of June.To Charles' list
and Ralf's suggestions, I would add setting up a server that can
relay pull requests to the mailing list.
Don't know if you saw this, but it looks like Pauli is
26.04.2012 03:11, Travis Oliphant kirjoitti:
[clip]
It would be nice if every pull request created a message to this list.
Is that even possible?
Unidirectional forwarding is possible, for instance using Github's API,
https://github.com/pv/github-pull-request-fwd
Github itself doesn't
01.05.2012 08:52, Travis Oliphant kirjoitti:
[clip]
3. No attachments for issues (screenshots, supporting documents, etc.).
Having API access to data won't help you here.
Using gists and references to gists can overcome this. Also using an
attachment service like http://uploading.com/ or
01.05.2012 11:14, David Froger kirjoitti:
Excerpts from Travis Oliphant's message of mar. mai 01 01:39:26 +0200 2012:
If you have particular reasons why we should choose a particular CI service,
please speak up and let your voice be heard. There is still time to
make
a difference in what
01.05.2012 21:34, Ralf Gommers kirjoitti:
[clip]
The main problem with Github (besides the issues/PRs thing and no
attachments, which I can live with) is that to make it work we'll have
to religiously label everything. And because users aren't allowed to
attach labels, it will require a larger
01.05.2012 21:34, Ralf Gommers kirjoitti:
[clip]
At this point it's probably good to look again at the problems we want
to solve:
1. responsive user interface (must absolutely have)
Now that it comes too late: with some luck, I've possibly hit on what
was ailing the Tracs (max_diff_bytes
Hi,
18.04.2012 19:57, Alan G Isaac kirjoitti:
http://docs.scipy.org/doc/numpy/reference/routines.matlib.html#module-numpy.matlib
promises a list of functions that does not appear (at the moment, anyway).
This doesn't seem to be due to a technical reason, but rather than
because nobody has
12.04.2012 18:43, Ralf Gommers kirjoitti:
[clip]
My current list of preferences is:
1. Redmine (if admin overhead is not unreasonable)
2. Trac with performance issues solved
3. Github
4. YouTrack
5. Trac with current performance
Redmine seems pretty nice, apparently has all the features
10.04.2012 06:52, Travis Oliphant kirjoitti:
[clip]
4) I'm still not sure about whether the IGNORED
concept is necessary or not. I really like the separation
that was emphasized between implementation (masks versus
bit-patterns) and operations (propagating versus non-propagating).
Pauli
06.04.2012 00:57, Whitcomb, Mr. Tim kirjoitti:
[clip]
Did something go wrong with a build?
Seems so. As a workaround, you can read the documentation of the
released versions.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
Hi,
02.04.2012 22:47, Travis Oliphant kirjoitti:
The plan is use a different issue tracker.
We are trying out YouTrack right now and hope to
export the Trac database into YouTrack.
Certainly, I'm aware :)
However, was the plan to also migrate the Scipy Trac? I understood the
answer to
Hi,
I moved projects.scipy.org Tracs to run on mod_python (instead of CGI),
in order to try to combat the present performance issues. Let's see if
this helps with the database is locked problem.
Please drop me a message if something stops working.
Pauli
14.03.2012 14:28, Pierre GM kirjoitti:
[clip]
Alas, the RuntimeError doesn't look like it's passed back to the interpreter,
which still crashes. (Adding a Py_Exit(-1) at the end of pyraise_runtime at
least let the interpreter do some extra cleaning after the fortran code
stopped,
but
101 - 200 of 995 matches
Mail list logo
