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;
Evan Hisey wrote:
> Good news, kaa metadata does now see my vcds, bad news freevo 1.x
> still does not like them. It know just gives a clean error detecting
> disks. Looks like duncan may have to make some changes to match the
> new code.
It seems to work for me, I've been busy testing VCDs for t
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:42, Dirk Meyer wrote:
>> - kaa.notifier.loop()
>> + kaa.main.start()
>
> Shouldn't this be kaa.main.run()? :)
Old changes, oops.
Dischi
--
All wiyht. Rho sritched mg kegtops awound?
pgpSSGV9EJGfw.pgp
Description: PGP signature
--
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:42, Dirk Meyer wrote:
> - kaa.notifier.loop()
> + kaa.main.start()
Shouldn't this be kaa.main.run()? :)
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
ht
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
Fine by me.
I'll wait another week before I begin merging the two on my own unless
I get feedback to the contrary.
Michael
--- Jason Tackaberry <[EMAIL PROTECTED]> wrote:
> On 2008-01-15 00:23, Michael Beal wrote:
> > Please contact me directly so we can trade code and see what comes
> of it!
>
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
33 matches
Mail list logo
