[PATCH] network streams ported to new API
This patch ports all network streams to the new stream api, so network.c is no more the meander it's been so far. The semantics of protocol management and the relative prorities are the same as the current ones. All streams work as much as the current code, on all the samples I tested. being the patch quite big I had to gzip it. If no one object I will commit after the end of LinuxTag, so we won't have bad surprises during the show, but when does it finish? Nico
Hi, On Thu, May 26, 2005 at 10:33:10PM +0200, Nico Sabbi wrote:
If no one object I will commit after the end of LinuxTag, so we won't have bad surprises during the show, but when does it finish?
It's from June 22.-25., so I'd say there is enough time to fix any bugs before *g* Greetings, Reimar Döffinger
Hi, On Thu, May 26, 2005 at 10:33:10PM +0200, Nico Sabbi wrote:
being the patch quite big I had to gzip it.
The printf -> mp_msg changes and many of those cases where you added static are independant and really should go in a separate patch (that can be applied "at once", since the worst that can happen would be an easily fixable compilation error). Greetings, Reimar Döffinger
Reimar Döffinger wrote:
Hi, On Thu, May 26, 2005 at 10:33:10PM +0200, Nico Sabbi wrote:
being the patch quite big I had to gzip it.
The printf -> mp_msg changes and many of those cases where you added static are independant and really should go in a separate patch (that can be applied "at once", since the worst that can happen would be an easily fixable compilation error).
Greetings, Reimar Döffinger
in theory yes, but they are both obviously correct and much tested. Should I really undo and redo such big changes that take a good portion of the patch?
Hi, On Thu, May 26, 2005 at 11:35:10PM +0200, Nico Sabbi wrote:
Reimar Döffinger wrote:
The printf -> mp_msg changes and many of those cases where you added static are independant and really should go in a separate patch (that can be applied "at once", since the worst that can happen would be an easily fixable compilation error).
in theory yes, but they are both obviously correct and much tested. Should I really undo and redo such big changes that take a good portion of the patch?
If that's really necessary maybe no, but I think you should be able to do it by editing the patch (you can just delete all blocks that contain more than these changes). Well, I guess it's not a must, but I sure would prefer it... Greetings, Reimar Döffinger
Reimar Döffinger wrote:
fixable compilation error).
in theory yes, but they are both obviously correct and much tested. Should I really undo and redo such big changes that take a good portion of the patch?
If that's really necessary maybe no, but I think you should be able to do it by editing the patch (you can just delete all blocks that contain more than these changes). Well, I guess it's not a must, but I sure would prefer it...
Greetings, Reimar Döffinger
Please, try this
Reimar Döffinger wrote:
If that's really necessary maybe no, but I think you should be able to do it by editing the patch (you can just delete all blocks that contain more than these changes). Well, I guess it's not a must, but I sure would prefer it...
Greetings, Reimar Döffinger
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
committed without printf->mp_msg and redefinitions as static. They will go
On Thu, May 26, 2005 at 10:33:10PM +0200, Nico Sabbi wrote:
If no one object I will commit after the end of LinuxTag, so we won't have bad surprises during the show, but when does it finish?
Commit before so we can make a release on LinuxTag with the cleaned up code :) And commit the printf --> mp_msg stuff right away I would say. Diego
participants (3)
-
Diego Biurrun -
Nico Sabbi -
Reimar Döffinger