On 5 Aug, 19:16, "Diez B. Roggisch" wrote:
> void foo(void *data, size_t length)
>
> The wrapper is supposed to be called with a python (byte)string instance,
> which might contain more than one '\0'-character.
>
> So how do I access the raw data of a string?
cdef extern void foo(void *data, int
On 5 Aug, 21:23, sturlamolden wrote:
> foo(data, length)
Oops, that would be
foo( data, length)
--
http://mail.python.org/mailman/listinfo/python-list
On 5 Aug, 15:40, Jesse Noller wrote:
> Sturla;
>
> That bug was fixed unless I'm missing something.
It is still in SVN. Change every call to os._exit to sys.exit
please. :)
http://svn.python.org/view/python/branches/release26-maint/Lib/multiprocessing/forking.py?revision=66717&view=markup
http
On 5 Aug, 21:36, sturlamolden wrote:
> http://svn.python.org/view/python/branches/release26-maint/Lib/multip...
>
> http://svn.python.org/view/python/branches/release31-maint/Lib/multip...
http://svn.python.org/view/python/trunk/Lib/multiprocessing/forking.py?revision=65864&am
On 5 Aug, 22:07, Piet van Oostrum wrote:
> Calling os.exit in a child process may be dangerous. It can cause
> unflushed buffers to be flushed twice: once in the parent and once in
> the child.
I assume you mean sys.exit. If this is the case, multiprocessing needs
a mechanism to chose between os
On 5 Aug, 22:28, Jesse Noller wrote:
> http://bugs.python.org/issue6653
>
> In the future please use the bug tracker to file and track bugs with,
> so things are not as lossy.
Ok, sorry :)
Also see Piet's comment here. He has a valid case against sys.exit in
some cases. Thus it appears that bot
On 5 Aug, 23:22, "Diez B. Roggisch" wrote:
> And that gives me the *full* bytestring, not only until the first zero?
> I can't try that right now (not at work anymore), but if it's that easy,
> that would be great.
It should, and if it does not it is a bug in Cython. The len()
function should wo
Version 3.1 of wxFormBuilder can generate wxPython code. I have
previously used wxFormBuilder to generate XRC files for my wxPython
projects. Though still in beta, this might be even better. :-)
http://wxformbuilder.org/
--
http://mail.python.org/mailman/listinfo/python-list
On 16 Aug, 11:45, "bartc" wrote:
> A for-loop, for iterating over a simple sequence, should be one of the
> fastest things in the language.
Anyone experienced with interpreted high-level languages knows this is
not true. Not because iterating a sequence is expensive, but because
the interpreter
On 16 Aug, 14:57, Dennis Lee Bieber wrote:
> Well, the alternative would be to have two keywords for looping: one
> for your "simple" incrementing integer loop, and another for a loop that
> operates over the elements of some collection type.
A compiler could easily recognise a statement
On 16 Aug, 20:32, Nobody wrote:
> Is there a reason to prefer code over XRC?
There is less boilerplate code required. E.g. event handlers are bound
in the GUI builder. You can access GUI objects as attributes of your
Python class. You don't need to request them from an xml. But apart
from that,
On 16 Aug, 22:59, "l...@d@n" wrote:
> Which is the best GUI interface builder with drag and drop
> capabilities.
> I am using Ubuntu GNU/Linux.
> Please help me.
> Thank you.
wxFormBuilder
--
http://mail.python.org/mailman/listinfo/python-list
On 16 Aug, 22:59, "l...@d@n" wrote:
> Which is the best GUI interface builder with drag and drop
> capabilities.
> I am using Ubuntu GNU/Linux.
PyGTK --> GLADE
xwPython --> wxFormBuilder
PyQt --> QtDesigner
--
http://mail.python.org/mailman/listinfo/python-list
On 16 Aug, 19:12, Carl Banks wrote:
> If you don't care about the dynamic stuff why don't you just use
> Cython? Or quit complaining and just use xrange.
I think you are the only one complaining here.
--
http://mail.python.org/mailman/listinfo/python-list
On 17 Aug, 17:19, Che M wrote:
> Boa (Boa Constructor) is really nice for wxPython GUI
> work, but it has some bugs when using Linux that might
> be dealbreakers for the user. At least I have had
> problems on Ubuntu 8.10 64 bit (but none or very few
>
I prefer wxFormBuilder over Boa.
--
http:
On 18 Aug, 11:19, Robert Dailey wrote:
> I'm looking for a way to parallelize my python script without using
> typical threading primitives. For example, C++ has pthreads and TBB to
> break things into "tasks".
In C++, parallelization without "typical threading primitives" usually
means one of t
On 18 Aug, 13:45, Robert Dailey wrote:
> Really, all I'm trying to do is the most trivial type of
> parallelization. Take two functions, execute them in parallel. This
> type of parallelization is called "embarrassingly parallel", and is
> the simplest form. There are no dependencies between the
On 19 Aug, 05:16, sturlamolden wrote:
> You should know about the GIL. It prevents multiple threads form using
> the Python interpreter simultaneously. For parallel computing, this is
> a blessing and a curse. Only C extensions can release the GIL; this
> includes I/0 routines
On 19 Aug, 05:27, Dave Angel wrote:
> With the current GIL implementation, for two CPU-bound tasks, you either
> do them sequentially, or make a separate process.
I'd also like to add that most compute-bound code should be delegated
to specialized C libraries, many of which are prewritten. For e
On 19 Aug, 05:34, Hendrik van Rooyen wrote:
> The GIL does apply - I was talking nonsense again. Misread the OP's
> intention.
It depends on what the OP's functions "doStuff1" and "doStuff2"
actually do. If they release the GIL (e.g. make I/O calls) it does not
apply. The GIL only serialize acc
On 18 Aug, 11:41, Stefan Behnel wrote:
> I think the canonical answer is to use the threading module or (preferably)
> the multiprocessing module, which is new in Py2.6.
>
> http://docs.python.org/library/threading.htmlhttp://docs.python.org/library/multiprocessing.html
>
> Both share a (mostly)
On 19 Aug, 05:27, Dave Angel wrote:
> But if you do it that way, it's slower than sequential. And if you have
> a multi-core processor, or two processors, or ... then it gets much
> slower yet, and slows down other tasks as well.
>
> With the current GIL implementation, for two CPU-bound tasks
On 19 Aug, 01:48, Pierre wrote:
> Well, the equivalence of setdiff in matlab...
That would be numpy.setdiff1d.
--
http://mail.python.org/mailman/listinfo/python-list
On 19 Aug, 20:22, laser wrote:
> In the future, will Python provide programe enviroment like Maple
> does?
You might be looking for SAGE.
http://www.sagemath.org/
--
http://mail.python.org/mailman/listinfo/python-list
On 23 Aug, 12:35, n...@cam.ac.uk wrote:
> I am interested in surveying people who want to interoperate between
> Fortran and Python to find out what they would like to be able to do
> more conveniently, especially with regard to types not supported for C
> interoperability by the current Fortran s
On 23 Aug, 20:42, n...@cam.ac.uk wrote:
> That is precisely what I am investigating. TR 29113 falls a LONG
> way before it gets to any of the OOP data - indeed, you can't even
> pass OOP derived types as pure data (without even the functionality)
> in its model. Nor most of what else Python woul
On 24 Aug, 00:02, Dennis Lee Bieber wrote:
> That's a C language problem -- since a string in C is just an array
> of character. The last FORTRAN dialect (and implementation) I used
> passed strings
On 24 Aug, 00:02, Dennis Lee Bieber wrote:
> values -- FORTRAN strings were typically s
On 24 Aug, 01:59, sturlamolden wrote:
> subroutine foobar(cstr) bind(c, name='foobar')
> use, intrinsic :: iso_c_binding
> type(c_ptr) :: cstr
> character(*), pointer :: fstr
> call c_f_pointer(cptr, fptr)
>
Which means that you can write a wrappe
On 24 Aug, 02:26, nos...@see.signature (Richard Maine) wrote:
> You missed the word "OOP", which seemed like the whole point. Not that
> the particular word is used in the Fortran standard, but it isn't hard
> to guess that he means a derived type that uses some of the OOP
> features. Inheritance,
On 24 Aug, 01:59, sturlamolden wrote:
> subroutine foobar(cstr) bind(c, name='foobar')
> use, intrinsic :: iso_c_binding
> type(c_ptr) :: cstr
> character(*), pointer :: fstr
> call c_f_pointer(cptr, fptr)
Actually, this does not work, as it is illegal
On 24 Aug, 02:57, nos...@see.signature (Richard Maine) wrote:
> Yes, it is no surprise that the C interop stuff fails to address this,
> since it isn't in C. Something different/extra would be needed, which is
> exactly what Nick said. I'm going to jump out of the middle of this now.
> The only re
On 23 Aug, 21:59, Emile van Sebille wrote:
> Speed of what? Development? User interaction? Responsiveness to queries?
My personal view on the 'Is Python faster than Java' question:
- Coding? Yes, if you program 'pythonic'.
- String handling? Often.
- I/O and networking? Often.
- Iteration?
On 24 Aug, 10:24, n...@cam.ac.uk wrote:
> In article <5134d9f1-0e23-4e05-a817-bf0cc9e85...@w6g2000yqw.googlegroups.com>,
>
> sturlamolden wrote:
> >On 24 Aug, 02:26, nos...@see.signature (Richard Maine) wrote:
>
> >> You missed the word "OOP", which see
On 18 Aug, 22:10, Derek Martin wrote:
> I have some simple threaded code... If I run this
> with an arg of 1 (start one thread), it pegs one cpu, as I would
> expect. If I run it with an arg of 2 (start 2 threads), it uses both
> CPUs, but utilization of both is less than 50%. Can anyone expla
On 24 Aug, 13:21, Piet van Oostrum wrote:
> But os.fork() is not available on Windows. And I guess refcounts et al.
> will soon destroy the sharing.
Well, there is os.fork in Cygwin and SUA (SUA is the Unix subsytem in
Windows Vista Professional). Cygwin's fork is a bit sluggish.
Multiprocessin
On 24 Aug, 14:08, Gilles Ganault wrote:
> I'm especially concerned about the lack of controls, the lack of
> updates (lots of controls in wxWidgets are 1.0 deadware), and problems
> linked to how to update users' PC remotely when I build a new version
> using eg. Py2exe.
There is pywin32 if you
On 24 Aug, 14:08, Gilles Ganault wrote:
> and problems
> linked to how to update users' PC remotely when I build a new version
> using eg. Py2exe.
Remote update is a problem regardless of language. It typically
involves the following steps:
1. Download the update from a server using a backgroun
On 24 Aug, 18:20, n...@cam.ac.uk wrote:
>This obviosuly proves you wrong:
>
> Er, no, it doesn't. I suggest that you read what I said more
> carefully - and the Fortran standard. As I said, you can kludge
> them up, and that is precisely one such kludge -
You said we have to kludge them up as ar
On 24 Aug, 20:55, n...@cam.ac.uk wrote:
> Precisely. And the kludge does NOT work under all circumstances,
> which is why I said that it doesn't work very well.
Do you have an example?
> Consider, for example:
>
> SUBROUTINE Fred (X) BIND(C)
> CHARACTER*(*) :: X
> END SUBROUTINE Fr
On 24 Aug, 21:24, n...@cam.ac.uk wrote:
> You might also like to consider the converse problem: how to write
> a Fortran function that takes a C string of arbitrary length and
> uses it.
That's what the code I showed you does.
--
http://mail.python.org/mailman/listinfo/python-list
On 25 Aug, 01:26, Piet van Oostrum wrote:
> That's because it doesn't use copy-on-write. Thereby losing most of its
> advantages. I don't know SUA, but I have vaguely heard about it.
SUA is a version of UNIX hidden inside Windows Vista and Windows 7
(except in Home and Home Premium), but very fe
On 25 Aug, 03:51, Peter Decker wrote:
> I've used in fairly regularly for about 2 years now. I haven't had to
> write that ugly wxPython code for so long that every time I see
> examples on their mail list I wanna barf.
I prefer wxFormBuilder. GUIs should be designed visually whenever
possible.
On 25 Aug, 05:56, Peter Decker wrote:
> I use the Dabo Class Designer to visually design my forms. So what's
> you're point? :)
Nothing, except lobbying for wxFormBuilder for anyone who still
doesn't know of it. :)
--
http://mail.python.org/mailman/listinfo/python-list
On 25 Aug, 13:33, Piet van Oostrum wrote:
> I have heard about that also, but is there a Python implementation that
> uses this? (Just curious, I am not using Windows.)
On Windows we have three different versions of Python 2.6:
* Python 2.6 for Win32/64 (from python.org) does not have os.fork.
On 25 Aug, 17:37, Matjaz Bezovnik wrote:
> Scott, thank you very much for the snippet.
>
> It is exactly what I looked for; simple to read and obvious as to what
> it does even a month later to a non-pythonist!
Since you were talking about matrices, observe that numpy has a matrix
subclass of n
On 25 Aug, 20:30, Gilles Ganault wrote:
> Combined with the comment above about issues with printing, it looks
> like Python for GUI apps isn't a very good idea :-/
With pywin32, printing is the same as for any other Windows app (you
get MFC for Python).
--
http://mail.python.org/mailman/listi
On 25 Aug, 13:24, Wolfgang Keller wrote:
> The area of _desktop_ database application development indeed looks like a
> vast and very hostile desert in the Python landscape.
Yes, you don't have drag-and-drop database tools like MS Access or
FoxPro. You actually have to use a database API (such
On 25 Aug, 21:45, Terry Reedy wrote:
> Will be good news if realized.
Good news for everyone except Riverbank.
--
http://mail.python.org/mailman/listinfo/python-list
On 26 Aug, 22:47, David C Ullrich wrote:
> > Nothing, except lobbying for wxFormBuilder for anyone who still doesn't
> > know of it. :)
>
> That's great. But do you know of anything I can use as a
> visual form design tool in wxPython?
Right... I don't know if you are trying to be funny, but as
On 28 Aug, 02:34, Deep_Feelings wrote:
> python got relatively fewer numbers of developers than other high
> level languages like .NET , java .. etc why ?
Because we are better, so fewer are needed.
--
http://mail.python.org/mailman/listinfo/python-list
On 4 Sep, 06:20, John Nagle wrote:
> > In the current CPython implementation, every object has a reference
> > count, even immutable ones. This must be a writable field - and here you
> > have your race condition, even for immutable objects.
>
> That's an implementation problem with CPython.
On 3 Sep, 20:03, John Nagle wrote:
> Python doesn't have immutable objects as a general concept, but
> it may be headed in that direction. There was some fooling around
> with an "immmutability API" associated with NumPy back in 2007, but
> that was removed. As more immutable types are add
On 5 Sep, 05:12, Steven D'Aprano wrote:
> Is the difference because of mutability versus immutability, or because
> of C code in Numpy versus Matlab code? Are you comparing bananas and
> pears?
It consisted of something like this
import numpy
def D4_Transform(x, s1=None, d1=None, d2=None):
On 4 Sep, 14:50, Michele Simionato
wrote:
> # requires byteplay by Noam Raphael
> # seehttp://byteplay.googlecode.com/svn/trunk/byteplay.py
> from byteplay import Code, LOAD_GLOBAL, STORE_FAST, LOAD_FAST
Incrediby cool :-)
--
http://mail.python.org/mailman/listinfo/python-list
On 5 Sep, 07:04, Steven D'Aprano wrote:
> Your code does a lot of unnecessary work if you're just trying to
> demonstrate immutability is faster or slower than mutability.
No ... I was trying to compute D4 wavelet transforms. I wanted to see
how NumPy compared with Matlab.
> How does Matlab sp
On 5 Sep, 07:04, Steven D'Aprano wrote:
> How does Matlab speed compare to Python in general?
Speed-wise Matlab is slower, but it is not the interpreter limiting
the speed here.
--
http://mail.python.org/mailman/listinfo/python-list
On 5 Sep, 08:47, Steven D'Aprano wrote:
> How do you know?
After more than 10 years experience with scientific programming I just
do. When it comes to numerics I have a gut feeling for what is fast
and what is slow.
It's not difficult actually. You just have to imagine how often the
interpreter
On 7 Sep, 07:17, grbgooglefan wrote:
> What is best way to embed python in multi-threaded C++ application?
Did you remeber to acquire the GIL? The GIL is global to the process
(hence the name).
void foobar(void)
{
PyGILState_STATE state = PyGILState_Ensure();
/* Safe to use Python C A
On 7 Sep, 07:17, grbgooglefan wrote:
> Can we not use python interpreters even private to each multiple
> thread?
You can use multiple interpreters, but they share GIL. For example,
Python extension modules are DLLs and will be loaded only once for
each process - the OS makes sure of that. Since
On 7 Sep, 07:59, ganesh wrote:
> No, I did not use GIL.
> -- For using GIL, do we need to initialize GIL at startup and destroy/
> finalize it at end?
> -- Are there any configuration & build related flags that I need to
> use to make this work?
>
> Please guide. Thanks.
I just showed you how...
On 7 Sep, 13:53, ganesh wrote:
> I need to use these to get the proper concurrency in my multi-threaded
> application without any synchronization mechanisms.
Why will multiple interpreters give you better concurrency? You can
have more than one thread in the same interpreter.
Here is the API ex
On 7 Sep, 13:17, Ulrich Eckhardt wrote:
> Quoting from above: "The GIL is global to the process". So no, it is NOT
> private to each thread which means "python" isn't either.
>
> At least that is my understanding of the issue.
Strictly speaking, the GIL is global to the Python DLL, not the
proce
On 7 Sep, 14:50, MRAB wrote:
> CPython's GIL means that multithreading on multiple processors/cores has
> limitations. Each interpreter has its own GIL, so processor-intensive
> applications work better using the multiprocessing module than with the
> threading module.
We incur a 200x speed-pena
On 8 Sep, 04:22, ganesh wrote:
> My application is a TCP server having multiple client connectons. C++
> PTHREADS are for each connected socket and the message received on the
> socket is evaluated by python functions.
> If I use only one process level python interpreter, then every thread
> has
On 8 Sep, 08:46, I V wrote:
> Do you have to use threads? If you use a process per connection, rather
> than a thread, each process will have its own GIL.
If ganesh is using Linux or Unix (which pthreads indicate), fork() is
just as efficient as threads.
On Windows one would need to keep a farm
On 8 Sep, 09:14, ganesh wrote:
> No, i cannot change from threads to processes for handling
> connections. This will change the complete design of our application
> which is not feasilbe for python evaluation of the strings.
So the problem is actually bad design?
--
http://mail.python.org/mailm
On 8 Sep, 13:36, Pierre wrote:
> anyone knows what is the python equivalent of the matlab's hanning
> function.
>
> Note that in matlab hann and hanning are different.
If you don't know how to compute a von Hann window, you are not
competent to do any scientific programming. Seriously!
I assume
On 8 Sep, 15:08, pdpi wrote:
> Come, come. I think it's a good rule that, where available, a vendor-
> supplied implementation is the preferable choice until proven
> otherwise.
Even for the simplest of equations?
--
http://mail.python.org/mailman/listinfo/python-list
On 9 Sep, 00:24, Steven D'Aprano
wrote:
> A decent vendor-supplied implementation will include error checking that
> you otherwise would need to implement yourself, so yes.
Not for code like this:
>>> import numpy as np
>>> n = np.arange(101)
>>> w = 0.5*(1.0-np.cos(2*np.pi*n/(100.)))
--
On 9 Sep, 03:45, hi_roger wrote:
> hello, i want to ask a question about numpy.
>
> i know how to select a submatrix using the slice object in numpy. But
> how can i select a submatrix
> A[i1,i2,i3;j1,j2,j3] (elements in A on line i1,i2,i3 and column
> j1,j2,j3 , and i1,i2,i3,j1,j2,j3 are all arb
On 9 Sep, 03:45, hi_roger wrote:
> i know how to select a submatrix using the slice object in numpy. But
> how can i select a submatrix
> A[i1,i2,i3;j1,j2,j3] (elements in A on line i1,i2,i3 and column
> j1,j2,j3 , and i1,i2,i3,j1,j2,j3 are all arbitrary numbers )
You just pass an array of ints
On 9 Sep, 16:57, pdpi wrote:
> Raising this to 1 million, rather than 100, nodes in the window, the
> timing difference between your version and NumPy's is tiny (but numpy
> still edges you out, but just barely), but they trounce my naive
> version, being around 7 or 8 times faster the list compr
On 10 Sep, 10:50, Hans Georg Schaathun wrote:
> Can anyone recommend a PRNG which supported multiple instances
> with independent states, and that also can return numpy.array (or
> something similar) efficiently?
numpy.random.RandomState
;-)
S.M.
--
http://mail.python.org/mailman/listinfo/pyt
On 9 Sep, 22:28, Zac Burns wrote:
> Theories:
> Python is resizing the large dictionary
> Python is garbage collecting
Python uses reference counting, not a generational GC like Java. A
Python object is destroyed when the refcount drops to 0. The GC only
collects cyclic references. If you
On 12 Sep, 15:54, Timothy Madden wrote:
> I find that hard to believe, but I will look into it.
Carl Banks is correct.
There is a mutex called "the global interpreter lock" that takes care
of this. You can have multiple threads running, but access to the
Python interpreter is serialized.
--
On 14 Sep, 00:05, Carl Banks wrote:
> Dice3DS works fine with PyOpenGL 3.x.
PyOpenGL is a bad idea anyway, due to the overhead of Python function
calls and ctypes. Doing 3D in "pure" Python at least requires NumPy
arrays as vertex arrays and/or extensive use of display lists. But
there are bette
701 - 776 of 776 matches
Mail list logo
