On Mon, 2008-03-03 at 16:33 +0100, Hans Meine wrote:
> Wouldn't this be fixed by using the "is" operator?
Yes and no.
Yes "is" is better and more correct, and we have (long since :)) changed
our code to use the 'is' operator.
No because Duncan's class should not have freaked out when instances o
Am Sonntag, 17. Februar 2008 16:18:04 schrieb Jason Tackaberry:
> So the result your function is returning is being compared with
> kaa.NotFinished, hence the call to __cmp__.
Wouldn't this be fixed by using the "is" operator?
Ciao, / /
/--/
/ / ANS
---
Dirk Meyer wrote:
> Duncan Webb wrote:
>> Using the last released kaa.base-0.3.0, the record server's Popen works
>> correctly. All I had to change was to rename the coroutine decorators,
>> Anyway the yield_execution calls don't work kaa-base-0.3.0 and Python
>> 2.4, send errors.
>>
>> The shut
Duncan Webb wrote:
> Using the last released kaa.base-0.3.0, the record server's Popen works
> correctly. All I had to change was to rename the coroutine decorators,
> Anyway the yield_execution calls don't work kaa-base-0.3.0 and Python
> 2.4, send errors.
>
> The shut down and ctrl-c don't wor
Dirk Meyer wrote:
> Duncan Webb wrote:
>
>> Dirk Meyer wrote:
>>
>>> Duncan Webb wrote:
>>>
>>>
| Does Freevo register an external unix signal handler? It should not do
| that. Please try to find out using some debug code what happens in
| kaa.notifier.main loop and
Duncan Webb wrote:
> Dirk Meyer wrote:
>> Duncan Webb wrote:
>>
>>> | Does Freevo register an external unix signal handler? It should not do
>>> | that. Please try to find out using some debug code what happens in
>>> | kaa.notifier.main loop and stop.
>>>
>>>
>>> It does register an Unix signal
Dirk Meyer wrote:
> Duncan Webb wrote:
>
>> | Does Freevo register an external unix signal handler? It should not do
>> | that. Please try to find out using some debug code what happens in
>> | kaa.notifier.main loop and stop.
>>
>>
>> It does register an Unix signal handler, when I comment thes
Duncan Webb wrote:
> | Does Freevo register an external unix signal handler? It should not do
> | that. Please try to find out using some debug code what happens in
> | kaa.notifier.main loop and stop.
>
>
> It does register an Unix signal handler, when I comment these out and
> press Ctrl-C I see:
Duncan Webb wrote:
> Dirk Meyer wrote:
> | Duncan Webb wrote:
> |> Dirk Meyer wrote:
> |> | Duncan Webb wrote:
> |> |> Duncan Webb wrote:
> |> |>> Jason Tackaberry said the following, on 20/02/2008 00:13:
> |> |>>> On Tue, 2008-02-19 at 20:30 +0100, Duncan Webb wrote:
> |> | The first is defini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dirk Meyer wrote:
| Duncan Webb wrote:
|> Dirk Meyer wrote:
|> | Duncan Webb wrote:
|> |> Duncan Webb wrote:
|> |>> Jason Tackaberry said the following, on 20/02/2008 00:13:
|> |>>> On Tue, 2008-02-19 at 20:30 +0100, Duncan Webb wrote:
|> | The fir
Duncan Webb wrote:
> Dirk Meyer wrote:
> | Duncan Webb wrote:
> |> Duncan Webb wrote:
> |>> Jason Tackaberry said the following, on 20/02/2008 00:13:
> |>>> On Tue, 2008-02-19 at 20:30 +0100, Duncan Webb wrote:
> | The first is definitely related to kaa and it is that a Ctrl-C is not
> | ki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dirk Meyer wrote:
| Duncan Webb wrote:
|> Duncan Webb wrote:
|>> Jason Tackaberry said the following, on 20/02/2008 00:13:
|>>> On Tue, 2008-02-19 at 20:30 +0100, Duncan Webb wrote:
| The first is definitely related to kaa and it is that a Ctrl-C i
Duncan Webb wrote:
> Duncan Webb wrote:
>> Jason Tackaberry said the following, on 20/02/2008 00:13:
>>> On Tue, 2008-02-19 at 20:30 +0100, Duncan Webb wrote:
The first is definitely related to kaa and it is that a Ctrl-C is not
killing freevo, the process is still running and requires a
Duncan Webb wrote:
> Jason Tackaberry said the following, on 20/02/2008 00:13:
>> On Tue, 2008-02-19 at 20:30 +0100, Duncan Webb wrote:
>>> The first is definitely related to kaa and it is that a Ctrl-C is not
>>> killing freevo, the process is still running and requires a kill -9 to
>>> really kil
Jason Tackaberry said the following, on 20/02/2008 00:13:
> On Tue, 2008-02-19 at 20:30 +0100, Duncan Webb wrote:
>> The first is definitely related to kaa and it is that a Ctrl-C is not
>> killing freevo, the process is still running and requires a kill -9 to
>> really kill it. With the 1.7 series
On Tue, 2008-02-19 at 20:30 +0100, Duncan Webb wrote:
> The first is definitely related to kaa and it is that a Ctrl-C is not
> killing freevo, the process is still running and requires a kill -9 to
> really kill it. With the 1.7 series it exits cleanly but in the 1.8
> series it does not seem to b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dirk Meyer wrote:
| Hi,
|
| Jason and I broke the kaa.notifier API again. We renamed some stuff
| and changed some parameter. Sorry about that, but the new API looks
| much better now and I don't think we will break anything in the near
| future. As a
Jason Tackaberry wrote:
> On Sun, 2008-02-17 at 21:37 +0100, Duncan Webb wrote:
>> Sorry being think again, I don't get it.
>>
>> If a rpc method in the server is being called from a client why should I
>> need to fix another method that is not obviously being used either by
>> the server and def
Duncan Webb wrote:
> Jason Tackaberry wrote:
>> On Sun, 2008-02-17 at 18:07 +0100, Duncan Webb wrote:
>>> So this means that I should keep yielding until inprogress.finish is not
>>> True?
>>
>> No, it means you should fix that __cmp__ method :)
>
> Sorry being think again, I don't get it.
Do an
On Sun, 2008-02-17 at 21:37 +0100, Duncan Webb wrote:
> Sorry being think again, I don't get it.
>
> If a rpc method in the server is being called from a client why should I
> need to fix another method that is not obviously being used either by
> the server and definitely not by the client?
I
Jason Tackaberry wrote:
> On Sun, 2008-02-17 at 18:07 +0100, Duncan Webb wrote:
>> So this means that I should keep yielding until inprogress.finish is not
>> True?
>
> No, it means you should fix that __cmp__ method :)
Sorry being think again, I don't get it.
If a rpc method in the server is be
On Sun, 2008-02-17 at 18:07 +0100, Duncan Webb wrote:
> So this means that I should keep yielding until inprogress.finish is not
> True?
No, it means you should fix that __cmp__ method :)
When you yield an InProgress object in a coroutine, when the coroutine
is reentered, the InProgress you yield
Jason Tackaberry wrote:
> On Sun, 2008-02-17 at 12:35 +0100, Duncan Webb wrote:
>> kaa.notifier.async.AsyncException: Exception raised asynchronously;
>> traceback follows:
>>File "../base/build/lib.linux-i686-2.4/kaa/notifier/coroutine.py",
>> line 203, in _step
>>File "/usr/lib/python2.
On Sun, 2008-02-17 at 12:35 +0100, Duncan Webb wrote:
> kaa.notifier.async.AsyncException: Exception raised asynchronously;
> traceback follows:
>File "../base/build/lib.linux-i686-2.4/kaa/notifier/coroutine.py",
> line 203, in _step
>File "/usr/lib/python2.4/site-packages/freevo/tv/epg_t
Jason Tackaberry wrote:
> On Sat, 2008-02-16 at 13:50 -0500, Jason Tackaberry wrote:
>> Might be a python 2.4 thing again. I'll setup a python 2.4 install and
>> try to troubleshoot.
>
> NOW try it. :)
The coroutine seems to be doing strange things...
freevo execute record_client.py findNextPro
On Sat, 2008-02-16 at 13:50 -0500, Jason Tackaberry wrote:
> Might be a python 2.4 thing again. I'll setup a python 2.4 install and
> try to troubleshoot.
NOW try it. :)
-
This SF.net email is sponsored by: Microsoft
Defy
On Sat, 2008-02-16 at 19:17 +0100, Duncan Webb wrote:
>File "/usr/lib/python2.4/site-packages/kaa/notifier/async.py", line
> 395, in wait
> return self.get_result()
>File "/usr/lib/python2.4/site-packages/kaa/notifier/async.py", line
> 350, in get_result
> raise exc_value
> kaa.no
Jason Tackaberry wrote:
> On Sat, 2008-02-16 at 12:20 +0100, Dirk Meyer wrote:
>>> ~ File "/usr/lib/python2.4/site-packages/kaa/notifier/async.py", line
>>> 284, in get_result
>>> ~raise type, value, tb
>>> AttributeError: 'object' object has no attribute 'title'
>> That looks like an error on
On Sat, 2008-02-16 at 09:39 -0500, Jason Tackaberry wrote:
> It's not a remote exception, it's a locally generated exception whose
> traceback has been lost because it would have needed to be stored. I
> will see what I can do about this.
Tracebacks should be more useful now. See recent commit.
On Sat, 2008-02-16 at 12:20 +0100, Dirk Meyer wrote:
> > ~ File "/usr/lib/python2.4/site-packages/kaa/notifier/async.py", line
> > 284, in get_result
> > ~raise type, value, tb
> > AttributeError: 'object' object has no attribute 'title'
>
> That looks like an error on the other side. If ther
Duncan Webb wrote:
> [email protected]()
> ~def findNextProgramCo(self):
> ~""" """
> ~progress = self.recordserver_rpc('findNextProgram')
> ~yield progress
> ~yield progress.get_result()
>
> This fails with an exception:
> Traceback (most recent call last):
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Tackaberry wrote:
| On Fri, 2008-02-15 at 23:12 +0100, Duncan Webb wrote:
|> Thanks for the examples but all they show me is that you can only yield
|> from other coroutines and can call a callback, but what I can't figure
|> out is how to pass a
On Fri, 2008-02-15 at 23:12 +0100, Duncan Webb wrote:
> Thanks for the examples but all they show me is that you can only yield
> from other coroutines and can call a callback, but what I can't figure
> out is how to pass a result (except in-progress objects) back from
> either a coroutine or a cal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Tackaberry wrote:
| On Fri, 2008-02-15 at 19:03 +0100, Duncan Webb wrote:
|> If I'm understanding this correctly, The problem with callbacks and
|> coroutines is that nothing can be returned so it can be tricky to make
|> the code do what you wan
On Fri, 2008-02-15 at 19:03 +0100, Duncan Webb wrote:
> If I'm understanding this correctly, The problem with callbacks and
> coroutines is that nothing can be returned so it can be tricky to make
> the code do what you want. For example, when someone selects a menu
Not exactly.
@coroutine-decora
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Tackaberry wrote:
| On Fri, 2008-02-15 at 15:29 +0100, Duncan Webb wrote:
|> Actually, I don't see it, but I guess that it blocks some where and
|> never returns?
|
| It will only never return if there's a deadlock (functions A() and B()
| are bo
On Fri, 2008-02-15 at 15:29 +0100, Duncan Webb wrote:
> Actually, I don't see it, but I guess that it blocks some where and
> never returns?
It will only never return if there's a deadlock (functions A() and B()
are both wait()ing on each other). The main loop is still kept alive in
this case tho
Dirk Meyer said the following, on 15/02/2008 10:07:
> Duncan Webb wrote:
>> BTW I like the async.wait() call it makes life much easier.
>
> wait should be avoided because it calls step() again. Let me give you
> an example: you have a mainloop running (calling step). Now you are in
> a callback an
On Fri, 2008-02-15 at 10:07 +0100, Dirk Meyer wrote:
> which will call another callback that also uses step. This means, that
> the first step will not return until the second one is done!
In practice, I suspect this is ok most of the time.
But as a rule, you're right, wait() should be avoided.
Duncan Webb wrote:
> BTW I like the async.wait() call it makes life much easier.
wait should be avoided because it calls step() again. Let me give you
an example: you have a mainloop running (calling step). Now you are in
a callback and call step() to wait. Inside wait you call step again
which wi
Jason Tackaberry said the following, on 14/02/2008 22:11:
> On Thu, 2008-02-14 at 22:00 +0100, Duncan Webb wrote:
>> The timings make sense but the get_result is blocking in the coroutine
>> but is okay for the wait.
>
> I'm a bit unsure what the bug is. Could you elaborate on what you're
> seein
On Thu, 2008-02-14 at 22:00 +0100, Duncan Webb wrote:
> The timings make sense but the get_result is blocking in the coroutine
> but is okay for the wait.
I'm a bit unsure what the bug is. Could you elaborate on what you're
seeing and what you expect to see?
It would also greatly help if you cou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Tackaberry wrote:
| On Thu, 2008-02-14 at 19:07 +0100, Duncan Webb wrote:
|> What happens is:
|> freevo execute src/tv/record_client.py getNextProgramStart
|> xml_rpc_server at 'http://localhost:18001/'
|> 06:20: getNextProgramStart begin
|> 06:2
On Thu, 2008-02-14 at 19:07 +0100, Duncan Webb wrote:
> What happens is:
> freevo execute src/tv/record_client.py getNextProgramStart
> xml_rpc_server at 'http://localhost:18001/'
> 06:20: getNextProgramStart begin
> 06:20: getNextProgramStart.progress= 0xb6eea24c>
But are you sure that the InProg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dirk Meyer wrote:
| Hi,
|
| Jason and I broke the kaa.notifier API again. We renamed some stuff
| and changed some parameter. Sorry about that, but the new API looks
| much better now and I don't think we will break anything in the near
| future. As a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Tackaberry wrote:
| On Thu, 2008-02-14 at 17:38 +0100, Dirk Meyer wrote:
|> That looks like a Python 2.4 bug. Take a look at corotine.py, there is
|> the _process function that creates the error. It should only use the
|> 'send' function for Pyth
On Thu, 2008-02-14 at 17:38 +0100, Dirk Meyer wrote:
> That looks like a Python 2.4 bug. Take a look at corotine.py, there is
> the _process function that creates the error. It should only use the
> 'send' function for Python 2.5 detected by _python25. Can you debug
> this please.
Yes, that's it.
Duncan Webb wrote:
> Dirk Meyer said the following, on 13/02/2008 23:04:
>> Duncan Webb wrote:
>>> Jason Tackaberry wrote:
>>> | On Wed, 2008-02-13 at 21:58 +0100, Dirk Meyer wrote:
>>> |> and changed some parameter. Sorry about that, but the new API looks
>>> |> much better now and I don't think w
On Thu, 2008-02-14 at 07:37 +0100, Duncan Webb wrote:
> I cleaned out the build and site-packages but do not have pynotifier
> installed.
Just curious -- long shot -- do you have beacon running?
-
This SF.net email is spons
Dirk Meyer said the following, on 13/02/2008 23:04:
> Duncan Webb wrote:
>> Jason Tackaberry wrote:
>> | On Wed, 2008-02-13 at 21:58 +0100, Dirk Meyer wrote:
>> |> and changed some parameter. Sorry about that, but the new API looks
>> |> much better now and I don't think we will break anything in t
Duncan Webb wrote:
> Jason Tackaberry wrote:
> | On Wed, 2008-02-13 at 21:58 +0100, Dirk Meyer wrote:
> |> and changed some parameter. Sorry about that, but the new API looks
> |> much better now and I don't think we will break anything in the near
> |> future.
> |
> | Speak for yourself, I'm just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Tackaberry wrote:
| On Wed, 2008-02-13 at 21:58 +0100, Dirk Meyer wrote:
|> and changed some parameter. Sorry about that, but the new API looks
|> much better now and I don't think we will break anything in the near
|> future.
|
| Speak for yours
On Wed, 2008-02-13 at 21:58 +0100, Dirk Meyer wrote:
> and changed some parameter. Sorry about that, but the new API looks
> much better now and I don't think we will break anything in the near
> future.
Speak for yourself, I'm just getting started. :)
But what I intend to break is more peripher
Hi,
Jason and I broke the kaa.notifier API again. We renamed some stuff
and changed some parameter. Sorry about that, but the new API looks
much better now and I don't think we will break anything in the near
future. As a side-effect, the Freevo 1.8 trunk may be broken now. But
I guess, it does no
Hi,
I just finished the kaa.notifier changes discussed here and in the irc
channel. I also updated all kaa modules and Freevo 2.0 to reflect the
changes, Freevo 1.x branch is broken I guess. Here a list of changes:
1. Rename kaa.notifier mainloop control:
kaa.notifier.init() is kaa.main.select
On Sun, 2008-01-20 at 11:18 +0100, Dirk Meyer wrote:
> A second reason: you always get one parameter for your callback when
> you connect to an InProgress object (the return value or the
> exception). With your proposal it is harder to handle return and
> exception in one function, IMHO it looks st
Dirk Meyer wrote:
> Jason Tackaberry wrote:
>> On Fri, 2008-01-18 at 23:00 +0100, Dirk Meyer wrote:
>>> I added some doc for this. This task should be done in two steps.
>>> First make sure yield_execution always returns an InProgress object
>>> and second add the new Python 2.5 code. I did some ch
Jason Tackaberry wrote:
> On Fri, 2008-01-18 at 23:00 +0100, Dirk Meyer wrote:
>> I added some doc for this. This task should be done in two steps.
>> First make sure yield_execution always returns an InProgress object
>> and second add the new Python 2.5 code. I did some changes and added
>> some
On Fri, 2008-01-18 at 23:00 +0100, Dirk Meyer wrote:
> I added some doc for this. This task should be done in two steps.
> First make sure yield_execution always returns an InProgress object
> and second add the new Python 2.5 code. I did some changes and added
> some doc. I will stop here to discu
Dirk Meyer wrote:
> 6. Add support for foo = yield something in kaa.base.
I added some doc for this. This task should be done in two steps.
First make sure yield_execution always returns an InProgress object
and second add the new Python 2.5 code. I did some changes and added
some doc. I will stop
Dirk Meyer wrote:
> 3. Rename Thread to ThreadCallback and rename start to __call__. A new
>Thread class will inherit from ThreadCallback and add a deprected
>warning and this functions also has a start function with a
>deprected warning.
Done without the Thread wrapper.
> 4. Adjust a
Jason Tackaberry wrote:
> See the attached, which implements it the way I think it should be
> (roughly). I think this is an elegant implementation. I didn't inherit
> ThreadCallback from your BackgroundTask class because I couldn't get it
> to work. You'll see what I mean when I try to make it
Jason Tackaberry wrote:
> See the attached, which implements it the way I think it should be
> (roughly). I think this is an elegant implementation. I didn't inherit
> ThreadCallback from your BackgroundTask class because I couldn't get it
> to work. You'll see what I mean when I try to make it
Jason Tackaberry wrote:
> On 2008-01-18 09:22, Dirk Meyer wrote:
>> One problem with BackgroundTask is that it has signals for completed
>> and exception and the InProgress objects connects to these
>> signals. That does not work with the idea that you can call the
>> callback more than once.
>
> A
On 2008-01-18 09:22, Dirk Meyer wrote:
> One problem with BackgroundTask is that it has signals for completed
> and exception and the InProgress objects connects to these
> signals. That does not work with the idea that you can call the
> callback more than once.
Another was that the decorated fun
Dirk Meyer wrote:
> 1. Adjust all kaa modules and freevo to the new notifier namespace
>stuff. The deprecated warnings in kaa.base will be kept but should
>not be visible for any kaa modules and Freevo 2.0. But since we
>break the API, they will be removed before the next release.
Done
On 2008-01-17 16:16, Dirk Meyer wrote:
> 3. Rename Thread to ThreadCallback and rename start to __call__. A new
>Thread class will inherit from ThreadCallback and add a deprected
>warning and this functions also has a start function with a
>deprected warning.
>
Don't just rename it;
First summary:
I will do the following tomorrow. All API changes will be written down
in base/API_CHANGE.txt.
1. Adjust all kaa modules and freevo to the new notifier namespace
stuff. The deprecated warnings in kaa.base will be kept but should
not be visible for any kaa modules and Freevo 2
Jason Tackaberry wrote:
> On 2008-01-17 15:50, Dirk Meyer wrote:
>> Code using ThreadCallback already has to be renamed because we reuse
>> this name. But I guess it is easy.
>
> Does anything use ThreadCallback directly? My guess is most things just
> use the execute_in_thread decorator.
You are
On 2008-01-17 15:50, Dirk Meyer wrote:
> Code using ThreadCallback already has to be renamed because we reuse
> this name. But I guess it is easy.
Does anything use ThreadCallback directly? My guess is most things just
use the execute_in_thread decorator.
Jason Tackaberry wrote:
> On 2008-01-17 15:47, Dirk Meyer wrote:
>> I think that there is a lot of code using Thread :(
>
> A temporary wrapper should be easy to write. What's one more? :)
Code using ThreadCallback already has to be renamed because we reuse
this name. But I guess it is easy.
Di
On 2008-01-17 15:47, Dirk Meyer wrote:
> I think that there is a lot of code using Thread :(
A temporary wrapper should be easy to write. What's one more? :)
-
This SF.net email is sponsored by: Microsoft
Defy all challenge
Jason Tackaberry wrote:
> On 2008-01-17 15:40, Dirk Meyer wrote:
>> So you suggest s/ThreadCallback/NamedThreadCallback and
>> s/Thread/ThreadCallback? And rename start in Thread to __call__.
>
> I guess that sums it up. What do you think?
I think that there is a lot of code using Thread :(
Disc
On 2008-01-17 15:40, Dirk Meyer wrote:
> So you suggest s/ThreadCallback/NamedThreadCallback and
> s/Thread/ThreadCallback? And rename start in Thread to __call__.
I guess that sums it up. What do you think?
-
This SF.net em
Jason Tackaberry wrote:
> Maybe that's what ThreadCallback should do: run a callback in a new
> thread every time. This obviates the need for the Thread class (it can
> be removed) -- it basically _is_ the Thread class except that it's a
> callable. And we can have a separate class to run a callb
On 2008-01-17 15:26, Dirk Meyer wrote:
> ThreadCallback(object)
>
> MainThreadCallback(ThreadCallback):
> ThreadCallback.__init__('main', ...)
>
> Thread(ThreadCallback):
> ThreadCallback.__init__(None, ...)
>
I wasn't really suggesting this as an implementation (conceding that
MainThre
Jason Tackaberry wrote:
> On 2008-01-17 15:12, Dirk Meyer wrote:
>> What does None do? A thread called None or main?
>
> None will spawn a new thread each time it's called. It won't use
> jobserver. It replicates Thread behavior.
So the code will look like
ThreadCallback(object)
MainThreadCall
On 2008-01-17 15:12, Dirk Meyer wrote:
> What does None do? A thread called None or main?
None will spawn a new thread each time it's called. It won't use
jobserver. It replicates Thread behavior.
-
This SF.net email is sp
On 2008-01-17 15:11, Dirk Meyer wrote:
> Gentoo still uses 2.4 and 2.5 is still masked. I have no idea why they
> still keep it.
Not sure either. It's not like 2.5 is new.
> Python 2.4 is a mimimum because kaa uses decorators at some points and
> you can't install decorated code even if you do n
Jason Tackaberry wrote:
> On 2008-01-17 14:47, Dirk Meyer wrote:
>>> ThreadCallback('name', somefunc)(arguments)
>>
>> What about priority?
>
> Make it a tuple?
>
> ThreadCallback(('name, 10), somefunc)(arguments)
So ('name', 10) start it in name with prio 10, 'name' in name with
default prio.
Jason Tackaberry wrote:
>> Nice. But that would move our target platform to 2.5. Do we want to do
>> that? I agree, it looks much nicer this way.
>
> Well, I wasn't actually suggesting that, but we may want to consider
> it. Here are the facts:
>
>1. Python 2.5 was released in September 2006,
On 2008-01-17 14:47, Dirk Meyer wrote:
>> ThreadCallback('name', somefunc)(arguments)
>
> What about priority?
Make it a tuple?
ThreadCallback(('name, 10), somefunc)(arguments)
or:
ThreadCallback(None, somefunc)(arguments)
-
On 2008-01-17 14:35, Dirk Meyer wrote:
>> But this doesn't work in the case where the decorated function doesn't
>> yield anything but just returns something.
>
> That is ugly anyway.
There is an argument to be made there, granted. You might say that if
the decorated function is not a generator,
Jason Tackaberry wrote:
R> On 2008-01-17 14:30, Dirk Meyer wrote:
>> Please do. Attached a patch that handles ThreadCallback similar to
>> Thread and Process but adds a __call__ method.
>
> So if I understand this correctly, this doesn't work with nameless
> threads? So this doesn't merge ThreadCa
On 2008-01-17 14:30, Dirk Meyer wrote:
> Please do. Attached a patch that handles ThreadCallback similar to
> Thread and Process but adds a __call__ method.
So if I understand this correctly, this doesn't work with nameless
threads? So this doesn't merge ThreadCallback and Thread ...
Also are Th
Jason Tackaberry wrote:
> On 2008-01-17 14:22, Dirk Meyer wrote:
>> I simple way to do this without added extra logic to a Signal is to
>> _not_ call the first next() right now but wait at least one main loop
>> iteration. This will force the return of an InProgress object.
>
> But this doesn't wor
Jason Tackaberry wrote:
> On 2008-01-17 14:06, Dirk Meyer wrote:
>> Yes, conceptually they are the same, but the implentation is a very
>> different. 'main' needs a completly different JobServer. Right now we
>> have MainThreadCallback is a simple class, we would have to greate a
>> MainJobServer t
On 2008-01-17 14:22, Dirk Meyer wrote:
> I simple way to do this without added extra logic to a Signal is to
> _not_ call the first next() right now but wait at least one main loop
> iteration. This will force the return of an InProgress object.
But this doesn't work in the case where the decorate
On 2008-01-17 14:06, Dirk Meyer wrote:
> Yes, conceptually they are the same, but the implentation is a very
> different. 'main' needs a completly different JobServer. Right now we
> have MainThreadCallback is a simple class, we would have to greate a
> MainJobServer to inherit MainThreadCallback f
Jason Tackaberry wrote:
> On 2008-01-17 13:54, Dirk Meyer wrote:
>> This would remove all our 'if isinstance(returnvalue, InProgress)'
>> special cases since we know we always get an InProgress object. This
>> will make the code much simpler. But we should be carefull when using
>> a yield_executio
On 2008-01-17 13:54, Dirk Meyer wrote:
> This would remove all our 'if isinstance(returnvalue, InProgress)'
> special cases since we know we always get an InProgress object. This
> will make the code much simpler. But we should be carefull when using
> a yield_execution inside a yield_execution in
Jason Tackaberry wrote:
> On 2008-01-16 13:12, Dirk Meyer wrote:
>> They do similar things. If you use a Thread, it will be started on
>> start() and do its job. The ThreadCallback gets a thread name to
>> execute it. So when you have 100 functions you want to call in a
>> thread, a Thread will spa
Jason Tackaberry wrote:
> On a related note, I'd like to update the yield_execution() decorator so
> that it returns an InProgress in every case. I recently updated it to
> just return the result if the decorated function doesn't yield anything
> (rather than before where it assumed there was a ne
On 2008-01-17 12:02, Jason Tackaberry wrote:
> cb = kaa.ThreadCallback('thumbnailer', generate_thumbnail)
> cb('file.jpg').connect(handle_thumbnail_done)
>
I still like this API but I see a race condition here: if the thread
executes and completes before connect() is called, handle_thum
On 2008-01-16 13:12, Dirk Meyer wrote:
> They do similar things. If you use a Thread, it will be started on
> start() and do its job. The ThreadCallback gets a thread name to
> execute it. So when you have 100 functions you want to call in a
> thread, a Thread will spawn 100 threads while a ThreadC
Jason Tackaberry wrote:
> As I understand what you wrote, it sounds ok to me. I've never used
> ThreadCallback so I don't know why you would use it over Thread. If
> they basically do the same thing, let's merge them.
They do similar things. If you use a Thread, it will be started on
start() and
On Wed, 2008-01-16 at 12:01 +0100, Dirk Meyer wrote:
> attached a patch how I think a BackgroundTask should look like. I
> added BackgroundTask to async.py and use it in Process and
> Thread. Tell me what you think.
Ok, will have a look some time today.
> On a site-notice: We have Thread() that
Hi Jason and everyone else,
attached a patch how I think a BackgroundTask should look like. I
added BackgroundTask to async.py and use it in Process and
Thread. Tell me what you think.
On a site-notice: We have Thread() that has a start() function. This
class calls a function in a new thread. Thi
Andreas Büsching wrote:
>> Remember the discussions we had about timer. Should a timer fire again
>> when the same timer is still in progress? Do we schedule the new timer
>> when the callback is started or when it is stopped? Some parts of kaa
>> need the way it is now and it is the same way glib
Hi,
On Fri, 2007-12-28 at 18:22 +0100, Dirk Meyer wrote:
> Andreas Büsching wrote:
> > If I remember correctly I suggested to implemented a twisted-notifier in
> > pyNotifier as I do not like the idea to have a feature in nf_generic
> > that in most case is not used ("un-used" code that requires c
1 - 100 of 137 matches
Mail list logo
