ANN: pydf 12
pydf displays the amount of used and available space on your filesystems, just like df, but in colours. The output format is completely customizable. pydf was written and works on Linux, but should work also on other modern UNIX systems. URL: http://kassiopeia.juls.savba.sk/~garabik/software/pydf/ License: public domain Changes since the last version: * better python3 support * if a mountpoint path contains control characters or invalid utf-8 sequences, they are quoted in hexadecimal -- --- | Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ | | __..--^^^--..__garabik @ kassiopeia.juls.savba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread! -- https://mail.python.org/mailman/listinfo/python-list
Re: Glade/Python - positioning main window at startup
On Tuesday, 30 December 2014 17:56:56 UTC, Cousin Stanley wrote: > > > > Problem: Can anyone help me find settings (either in Glade or elsewhere) > > which will start the application window with the application window center > > aligned with the desktop center ? > > You might try the following entry > in your .glade file > > center > > -- > Stanley C. Kitching > Human Being > Phoenix, Arizona Neither "center" nor "center-on-parent" have the desired effect. Both are offered in a Glade drop-down list, so manual edits of the XML are not needed. Mary -- https://mail.python.org/mailman/listinfo/python-list
numpy.fromiter in pypy
Hi,
I would like to use numpy implementation for Pypy (what else would one do on
December 31 :-).
In particular, I would like to use numpy.fromiter, which is available according
to this overview:
http://buildbot.pypy.org/numpy-status/latest.html. However, contrary to what
this website says,
this function is not yet available. Conclusion: the website is wrong. Or am I
missing something?
albertjan@debian:~$ sudo pypy $(which pip) install -U
git+https://bitbucket.org/pypy/numpy.git
albertjan@debian:~$ sudo pypy -c 'import numpy' # sudo: as per the
installation instructions
albertjan@debian:~$ pypy
Python 2.7.8 (f5dcc2477b97386c11e4b67f08a2d00fbd2fce5d, Sep 19 2014, 10:37:41)
[PyPy 2.4.0 with GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import sys
import numpy as np
np.__version__, sys.version
('1.9.0', '2.7.8 (f5dcc2477b97386c11e4b67f08a2d00fbd2fce5d, Sep 19 2014,
10:37:41)\n[PyPy 2.4.0 with GCC 4.8.2]')
np.fromiter
np.fromiter((i for i in range(10)), np.float)
Traceback (most recent call last):
File "", line 1, in
File "/opt/pypy-2.4/site-packages/numpy/core/multiarray.py", line 55, in tmp
raise NotImplementedError("%s not implemented yet" % func)
NotImplementedError: fromiter not implemented yet
Thanks in advance and happy 2015.
Regards,
Albert-Jan
~~
All right, but apart from the sanitation, the medicine, education, wine, public
order, irrigation, roads, a
fresh water system, and public health, what have the Romans ever done for us?
~~
--
https://mail.python.org/mailman/listinfo/python-list
Multiprocessing process termination
In order to allow multiple processes to access a database (currently SQLite) I want to run the process in a separate thread. Because it will be accessed from multiple processes I intent to use Queues for shifting messages back and forth. But none of the individuals processes will know when all of the others are through. It there a way to properly close the database, or does it need to be done from the parent process? What I want to do is detect that a request to shutdown the Process has been received, and then execute a close procedure that cleans things up and shutdown. Terminate is the obvious procedure to use, but that comes with a warning not to use it if there is an queue attached (and without defining attached). OTOH, since the queue will never be read after the process has been shutdown, perhaps rendering it unusable is the proper thing. Could someone comment on this step of the design? The basic idea is: class handledb(Process): def __init__(self, q, otherstuff): self.q = q def run(self, msg): while (true): if self.q.empty(): sleep(someamountoftime) else: while (not self.q.empty()): read and parse message if message says to shutdown: self.shutdown() def shutdown(self): close things down ?? terminate ??<<-- should this be done while q is live? -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing process termination
Why not use a multiuser database server instead of trying to make one? You do not have the resources to a better job on your own. You know where to find Firebird SQL, MariaDB, MySQL, PostegreSQL, IBM DB2, Oracle, etc. Personally I prefer Firebird because like SQLite the database is stored in a file. Another nice way to get the database in a file is to run it in an Oracle VirtualBox VM. SQLite also allows multiple connections, by the way, but it does not scale very well. Regards, Sturla Charles Hixson wrote: > In order to allow multiple processes to access a database (currently > SQLite) I want to run the process in a separate thread. Because it will > be accessed from multiple processes I intent to use Queues for shifting > messages back and forth. But none of the individuals processes will > know when all of the others are through. It there a way to properly > close the database, or does it need to be done from the parent process? > > What I want to do is detect that a request to shutdown the Process has > been received, and then execute a close procedure that cleans things up > and shutdown. Terminate is the obvious procedure to use, but that comes > with a warning not to use it if there is an queue attached (and without > defining attached). > OTOH, since the queue will never be read after the process has been > shutdown, perhaps rendering it unusable is the proper thing. > > Could someone comment on this step of the design? > > The basic idea is: > > class handledb(Process): > def __init__(self, q, otherstuff): > self.q = q > >def run(self, msg): > while (true): > if self.q.empty(): > sleep(someamountoftime) > else: > while (not self.q.empty()): > read and parse message > if message says to shutdown: self.shutdown() > >def shutdown(self): > close things down > ?? terminate ??<<-- should this be done > while q is live? -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing process termination
On 2014-12-31 19:33, Charles Hixson wrote: In order to allow multiple processes to access a database (currently SQLite) I want to run the process in a separate thread. Because it will be accessed from multiple processes I intent to use Queues for shifting messages back and forth. But none of the individuals processes will know when all of the others are through. It there a way to properly close the database, or does it need to be done from the parent process? What I want to do is detect that a request to shutdown the Process has been received, and then execute a close procedure that cleans things up and shutdown. Terminate is the obvious procedure to use, but that comes with a warning not to use it if there is an queue attached (and without defining attached). OTOH, since the queue will never be read after the process has been shutdown, perhaps rendering it unusable is the proper thing. Could someone comment on this step of the design? The basic idea is: class handledb(Process): def __init__(self, q, otherstuff): self.q = q def run(self, msg): while (true): if self.q.empty(): sleep(someamountoftime) else: while (not self.q.empty()): read and parse message if message says to shutdown: self.shutdown() def shutdown(self): close things down ?? terminate ??<<-- should this be done while q is live? The parent process could tell the db process to shutdown (by putting a message in the queue) when the child processes have terminated. Alternatively, the parent process could tell the db process how many child processes there are and then shutdown when it has received that many notifications from child processes that they have finished. BTW, it's better to let the queue read block until a message arrives than to keep polling and sleeping if it's empty. -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing process termination
On 12/31/2014 01:18 PM, MRAB wrote: On 2014-12-31 19:33, Charles Hixson wrote: In order to allow multiple processes to access a database (currently SQLite) I want to run the process in a separate thread. Because it will be accessed from multiple processes I intent to use Queues for shifting messages back and forth. But none of the individuals processes will know when all of the others are through. It there a way to properly close the database, or does it need to be done from the parent process? What I want to do is detect that a request to shutdown the Process has been received, and then execute a close procedure that cleans things up and shutdown. Terminate is the obvious procedure to use, but that comes with a warning not to use it if there is an queue attached (and without defining attached). OTOH, since the queue will never be read after the process has been shutdown, perhaps rendering it unusable is the proper thing. Could someone comment on this step of the design? The basic idea is: class handledb(Process): def __init__(self, q, otherstuff): self.q = q def run(self, msg): while (true): if self.q.empty(): sleep(someamountoftime) else: while (not self.q.empty()): read and parse message if message says to shutdown: self.shutdown() def shutdown(self): close things down ?? terminate ??<<-- should this be done while q is live? The parent process could tell the db process to shutdown (by putting a message in the queue) when the child processes have terminated. Alternatively, the parent process could tell the db process how many child processes there are and then shutdown when it has received that many notifications from child processes that they have finished. BTW, it's better to let the queue read block until a message arrives than to keep polling and sleeping if it's empty. Thanks. This design already depends on the parent process telling the db process when to shut down, but this depends on the queue (which is, I think, attached to the process) and so I am uncertain about calling terminate, as the docs say this can be expected to corrupt the queue. I'm hoping that this isn't a problem if the db process is the only reader of the queue, and this shouldn't happen until after all other writers to the queue have finished. But the documentation has made me uneasy on this point. A blocking read is better? OK, that's an easy change, and seems quite reasonable. But its the termination that I was worried about. (This is only one use out of several similar cases, and I'd like to use the same pattern throughout, so I'd really rather get it right the first time. Particularly as MP programs won't necessarily throw the error predictably.) -- https://mail.python.org/mailman/listinfo/python-list
[ANN] EasyGUI_Qt version 0.9
EasyGUI_Qt version 0.9 has been released. This is the first announcement about EasyGUI_Qt on this list. Like the original EasyGUI (which used Tkinter), EasyGUI_Qt seeks to provide simple GUI widgets that can be called in a procedural program. EasyGUI_Qt is NOT event-driven: all GUI interactions are invoked by simple function calls. The archetype is get_string(message) which pops a box whose purpose is exactly the same as Python's input(prompt), that is, present the user with a question/prompt, have the user enter an answer, and return the provided answer as a string. Thus easygui_qt.get_string() can be used as a drop-in replacement for input(). Similarly, instead of using a print() function to display a message, show_message() is used which pops a message window. EasyGUI_Qt requires PyQt4 and is really targeted for Python 3.3+ - although it can work (possibly with some unicode problems ...) using Python 2.7. More information can be found at http://easygui-qt.readthedocs.org/en/latest/index.html Feedback is most welcome, including reporting bugs to https://github.com/aroberge/easygui_qt/issues Happy 2015 everyone, André Roberge -- https://mail.python.org/mailman/listinfo/python-list
