P.J. Eby wrote:
At 05:16 PM 7/15/2009 +0200, Joachim König wrote:
f you have m different versions of n packages then
you could have n**m different combinations for an application so you
need a
possiblilty to select one combination from n**m possible ones at
application
startup time. Is this
Tarek Ziadé wrote:
So basically "site-packages" is a distribution location that is
avoided by everyone because it doesn't
know how to handle multiple versions.
I think you overrate the importance of having multiple versions of a
package available
for the same python interpreter. If you have m d
Guido van Rossum wrote:
On Tue, Mar 10, 2009 at 1:11 PM, Christian Heimes wrote:
[...]
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54.
[...]
If I understand the post properly, it's up to the app to call fsync(),
and it's only necessary when you're doing on
Phillip J. Eby wrote:
> It would be, if .eggs were a packaging format, rather than a binary
> distribution/runtime format.
>
> Remember "eggs are to Python as jars are to Java" -- a Java .jar
> doesn't contain documentation either, unless it's needed at
> runtime. Same for configuration files.
Phillip J. Eby wrote:
> Second, there were no uninstall tools for it, so I'd have had to
> write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it
> ain't easy, and I have an aversion to deleting stuff on people's
> systems without knowing what will break. There's a big difference
Adam Olsen wrote:
> That would depend on whether Joachim's wait() refers to the individual
> tasks' calls or the scheduler's call. I assumed it referred to the
> scheduler. In the basic form it would literally be select.select(),
> which has O(n) cost and often fairly large n.
The wait(events, ti
Armin Rigo wrote:
> I just realized that this is not really true in the present context.
> If the goal is to support programs that "look like" they are
> multi-threaded, i.e. don't use callbacks, as I think is Joachim's goal,
> then most of the time the wait() function would be only called with a
>
[EMAIL PROTECTED] wrote:
> When you boil it down, Twisted's event loop is just a notification for
> "a connection was made", "some data was received on a connection", "a
> connection was closed", and a few APIs to listen or initiate different
> kinds of connections, start timed calls, and commu
Joachim König-Baltes wrote:
> The problem solved by this approach is to allow a number of cooperating
> threads to wait for an event without the need to busy loop or block by
> delegating
> the waiting to a central instance, the scheduler. How this efficient
> waiting is
>
Adam Olsen schrieb:
> I don't think we're on the same page then. The way I see it you want
> a single async IO implementation shared by everything while having a
> collection of event loops that cooperate "just enough". The async IO
> itself would likely end up being done in C.
>
No, I'd like to
Adam Olsen wrote:
> I agree with everything except this. A simple function call would
> have O(n) cost, thus being unacceptable for servers with many open
> connections. Instead you need it to maintain a set of events and let
> you add or remove from that set as needed.
We can learn from kevent h
[EMAIL PROTECTED] wrote:
[...]
> microtreading:
> Exploiting language features to use cooperative multitasking in tasks
> that "read" like they are single-threaded.
>
> asynchronous IO:
> Performing IO to/from an application in such a way that the
> application does not wait for any IO ope
12 matches
Mail list logo
