Thanks for your reply.
On 08.08.22 13:20, Stefan Ram wrote:
Yes, but this is difficult. If you ask this question here,
you might not be ready for this.
Indeed.
I haven't learned it yet myself, but nevertheless tried to
write a small example program quickly, which might still
On Mon, 8 Aug 2022 12:47:26 +0200, Andreas Croci
declaimed the following:
>tI would like to write a program, that reads from the network a fixed
>amount of bytes and appends them to a list. This should happen once a
>second.
>
Ignoring leap seconds, there are 86400 seconds in a day --
On 2022-08-07 21:38, Paul Bryan wrote:
Have you tried turning it off and back on again?
Thank you, Roy.
--
D'Arcy J.M. Cain
Vybe Networks Inc.
A unit of Excelsior Solutions Corporation - Propelling Business Forward
http://www.VybeNetworks.com/
IM:da...@vybenetworks.com VoIP:
Thank you for your reply.
On 08.08.22 14:55, Julio Di Egidio wrote:
Concurrent programming is quite difficult, plus you better think
in terms of queues than shared data...
Do you mean queues in the sense of deque (the data structure)? I ask
because I can see the advantage there when I try
On 8/8/2022 12:59 PM, Pablo Galindo Salgado wrote:
Python 3.11.0 is almost ready. This release, 3.11.0rc1, is the
penultimate release preview. You can get it here:
## This is the first release candidate of Python 3.11
https://www.python.org/downloads/release/python-3110rc1/
On 8/8/2022 4:47 AM, Andreas Croci wrote:
tI would like to write a program, that reads from the network a fixed
amount of bytes and appends them to a list. This should happen once a
second.
Another part of the program should take the list, as it has been
filled so far, every 6 hours or so,
On 8/8/2022 12:59 PM, Pablo Galindo Salgado wrote:
Python 3.11.0 is almost ready. This release, 3.11.0rc1, is the
penultimate release preview. You can get it here:
## This is the first release candidate of Python 3.11
https://www.python.org/downloads/release/python-3110rc1/
Python 3.11.0 is almost ready. This release, 3.11.0rc1, is the penultimate
release preview. You can get it here:
## This is the first release candidate of Python 3.11
https://www.python.org/downloads/release/python-3110rc1/
This release, **3.11.0rc1**, is the penultimate release preview.
>> But, an easier and often
>> better option for concurrent data access is use a (relational)
>> database, then the appropriate transaction isolation levels
>> when reading and/or writing.
>>
>
> That would obviusly save some coding (but would introduce the need to
> code the interaction with the
tI would like to write a program, that reads from the network a fixed
amount of bytes and appends them to a list. This should happen once a
second.
Another part of the program should take the list, as it has been filled
so far, every 6 hours or so, and do some computations on the data (a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
dn wrote:
> On 06/08/2022 11.41, avi.e.gr...@gmail.com wrote:
>> I wonder if someone is pulling our leg as they are sending from an
>> invalid email address of "GB " which is
>> a bit sick.
>
> There are a number of folk who use evidently false
On 08/08/2022 12:59, Dan Purgert wrote:
dn wrote:
On 06/08/2022 11.41, avi.e.gr...@gmail.com wrote:
I wonder if someone is pulling our leg as they are sending from an
invalid email address of "GB " which is
a bit sick.
There are a number of folk who use evidently false email addresses - the
On 2022-08-08 12:20, Stefan Ram wrote:
Andreas Croci writes:
Basically the question boils down to wether it is possible to have parts
of a program (could be functions) that keep doing their job while other
parts do something else on the same data, and what is the best way to do
this.
On 2022-08-08 13:53:20 +0200, Andreas Croci wrote:
> I'm in principle ok with locks, if it must be. What I fear is that the lock
> could last long and prevent the function that writes into the list from
> doing so every second. With an FFT on a list that contains a few bytes taken
> every second
On 09Aug2022 00:22, Oscar Benjamin wrote:
>On Mon, 8 Aug 2022 at 19:01, Andreas Croci wrote:
>> Basically the question boils down to wether it is possible to have
>> parts
>> of a program (could be functions) that keep doing their job while other
>> parts do something else on the same data, and
> On 8 Aug 2022, at 20:24, MRAB wrote:
>
> On 2022-08-08 12:20, Stefan Ram wrote:
>> Andreas Croci writes:
>>> Basically the question boils down to wether it is possible to have parts of
>>> a program (could be functions) that keep doing their job while other parts
>>> do something else on
On 08Aug2022 11:20, Stefan Ram wrote:
>Andreas Croci writes:
>>Basically the question boils down to wether it is possible to have parts
>>of a program (could be functions) that keep doing their job while other
>>parts do something else on the same data, and what is the best way to do
>>this.
>
>
Stefan,
You are correct that the goal of a lock is to do something rather quickly
and atomically, so your design should not do something complex or long
before releasing the lock.
In your example, you have a producer adding data as regularly as every
second and another that wakes up rarely and
On Mon, 8 Aug 2022 at 19:01, Andreas Croci wrote:
>
> tI would like to write a program, that reads from the network a fixed
> amount of bytes and appends them to a list. This should happen once a
> second.
>
> Another part of the program should take the list, as it has been filled
> so far, every
Announcing wxPython 4.2.0
=
PyPI: https://pypi.python.org/pypi/wxPython/4.2.0
Extras: https://extras.wxPython.org/wxPython4/extras/
Pip:``pip install wxPython==4.2.0``
* Yes, it's been a VERY long time since the last release. I'm not
dead, just on an extended
Queues are better than lists for concurrency. If you get the right kind,
they have implicit locking, making your code simpler and more robust at the
same time.
CPython threading is mediocre for software systems that have one or more
CPU-bound threads, and your FFT might be CPU-bound.
Rather
21 matches
Mail list logo
