[00:16] pedronis (~Samuele_P@c-0c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050317]"
----- silence for 1 hr and 58 minutes ----- [02:14] idnar_ (mithrandi@idnar.user) left irc: Read error: 145 (Connection timed out)
----- silence for 6 hr and 21 minutes ----- [08:35] thingie24 (~rmt38@valhalla.ccp.cc) joined #pypy.
----- silence for 33 minutes ----- [09:08] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
----- silence for 32 minutes ----- [09:40] Gromit (~bear@dialin-212-144-177-247.arcor-ip.net) joined #pypy.
[09:40] arigo (~arigo@134.99.18.225) joined #pypy.
----- silence for 40 minutes ----- [10:20] _hannes (rvzzgdp@i528C118D.versanet.de) joined #pypy.
----- silence for 27 minutes ----- [10:47] stakkars (~tismer@82.144.60.19) joined #pypy.
----- silence for 22 minutes ----- [11:09] <arigo> hi!
[11:10] <stakkars> hi :'-(
[11:10] _hannes (rvzzgdp@i528C118D.versanet.de) left irc: Read error: 104 (Connection reset by peer)
[11:13] <stakkars> I was suffering from flu till yesterday. Now I think I'm better, and my brain BIOS doesn't crash again, like Sunday
----- silence for 1 hr and 39 minutes ----- [12:52] Gromit (~bear@dialin-212-144-177-247.arcor-ip.net) left irc: "Client Exiting"
----- silence for 42 minutes ----- [13:34] arigo (~arigo@134.99.18.225) left irc: "lunch"
----- silence for 42 minutes ----- [14:16] Gromit (~bear@dialin-212-144-177-232.arcor-ip.net) joined #pypy.
----- silence for 17 minutes ----- [14:33] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[14:35] arigo (~arigo@stups.cs.uni-duesseldorf.de) joined #pypy.
[14:37] <cfbolz> hi all!
[14:37] <arigo> hi!
[14:37] <cfbolz> I found some strange things going on with longs (not just after my checkin).
[14:38] <cfbolz> Is there a legitimate reason why pow(2L, -3L) should call pow__Long_Long_None several times?
[14:38] <arigo> twice?
[14:39] <cfbolz> no, more like three times.
[14:39] <cfbolz> and the arguments change
[14:39] <arigo> argh
[14:40] <cfbolz> I get something like:
[14:40] <cfbolz> >>>> pow(2L, -3L)
[14:40] <cfbolz> pow__Long_Long_None 2 -3
[14:40] <cfbolz> pow__Long_Long_None 2 57
[14:40] <cfbolz> pow__Long_Long_None 10 0
[14:40] <cfbolz> 0.125
[14:41] <arigo> uh
[14:41] <cfbolz> very strange
[14:41] <arigo> but if I try, I only get one call, "2 -3"
[14:41] <arigo> couldn't it be something in your code, not checked in yet?
[14:41] <arigo> ah wait
[14:42] <arigo> no, I know
[14:42] <cfbolz> forgot the long?
[14:42] <arigo> it's the printing of the result
[14:42] <arigo> if you do x = pow(2L, -3L) you only get the expected line
[14:42] <cfbolz> aah.
[14:42] <arigo> I believe that some code in _float_formatting computes 2**57 and 10**0...
[14:42] <cfbolz> and if you do print 0.125 you get it too
[14:42] <cfbolz> I see
[14:42] <arigo> yes.
[14:43] <cfbolz> ok, it's not a bug then.
[14:43] <arigo> yip.
[14:43] <cfbolz> But there were more problems in the long implementation: at the moment true_div = floor_div = div for longs. I'm fixing it.
[14:44] <arigo> ok
[14:54] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[14:55] <pedronis> hi
[14:55] <arigo> hi!
[14:56] <pedronis> cfbolz: are you working on long?
[14:57] <pedronis> you need to take care of the positive/negative case in long__Int
[14:57] <pedronis> long(-1) right now gives the wrong result
[15:03] <cfbolz> pedronis: yes I do.
[15:03] <cfbolz> oops. I'll fix it
[15:03] <pedronis> you need to do r_uint(-x) if x is negative or -r_uint(x)
[15:04] <cfbolz> right. I think I allready did it but it's not checked in.
[15:05] <pedronis> ok
----- silence for 17 minutes ----- [15:22] <cfbolz> It's fixed now. It seems that targetpypy1 is broken. Is that something I did?
[15:22] <cfbolz> The error is 'AssertionError: unexpected ovf check on unsigned'
[15:25] <pedronis> no
[15:25] <pedronis> the annotattor cannot make sense of the code in ovfcheck
[15:25] <cfbolz> ok
----- silence for 19 minutes ----- [15:44] <stakkars> yes, a const 2**58 is there, this is correct.
[15:45] <cfbolz> I got it now. I just suspected a bug in my pow__Long_Long_None implementation and was astonished that it got called several times.
[15:47] <cfbolz> stakkars: (OT) is it intentional that www.stackless.com is not showing anything useful? someone asked on comp.lang.python
[15:55] <stakkars> big oops (OT)
[15:55] <stakkars> the server was down, and this Zope site has to be started,manually. Trying it...
[15:57] <stakkars> eek, there is some damage, of course...
[16:04] _hannes (~yuuhu@i528C118D.versanet.de) joined #pypy.
[16:06] <stakkars> up, again. But still no updated content, must do this!
[16:07] <cfbolz> I'll reply to the post.
[16:09] <stakkars> an hour ago, we just finished a never-ending project which ate up all spare time.
[16:09] <stakkars> spare time will now go into Stackless,again :-)
[16:10] <cfbolz> I wish I had such a thing as spare time :-)
[16:11] <stakkars> I too wished you had it. You would take better care of it than me :-)
[16:13] <stakkars> cfbolz: I saw a checkin-message that you are implementing some long objects!
[16:13] <stakkars> This is nice. I wanted to do this at some time, too, but Armin said, we might
[16:14] <stakkars> find that already implemented, somewhere. Did you search the net a little bit for something usable?
[16:14] <cfbolz> nope.
[16:15] <arigo> I searched a bit and didn't find anything, so I no longer have this objection now -- but maybe I missed it.
[16:15] <stakkars> fine
[16:15] <cfbolz> But most of the things I implemented are adaptet from CPython's implementation anyway
[16:15] <pedronis> cfbolz: now the annotator special case ovfcheck and ovfcheck_lshift properly, stil the generators need to do the right thing
[16:15] <cfbolz> pedronis: I'll try to fix genllvm tonight
[16:16] <pedronis> arigo: targetpypy1 now again finishes annotation but dies with compiler errors
[16:16] <arigo> ok
[16:17] <arigo> some OP_XXX missing, I assume
[16:18] arre (ac@ratthing-b3fa.strakt.com) left irc: Remote closed the connection
[16:19] <pedronis> cfbolz: btw, I have implemented a first draft of the idea of computing maximal sets of PBCs that are accessed
[16:20] <pedronis> arigo: it laments a missing OP_ABS
[16:20] <arigo> I see
[16:20] <arigo> odie has drafts of OP_STR and OP_ORD, too
[16:23] <cfbolz> pedronis: Yes I saw that. I'll look at it later this week (lectures start tomorrow so I have a bit less time for PyPy :-( )
[16:30] <arigo> oups, warning
[16:30] <arigo> I just renamed g_operation.h
[16:31] <arigo> if you wanted to write some OP_XXX but didn't start yet, svn up...
[16:34] <pedronis> arigo: at some point we discussed to use only location for specialization, because of the problems with getting temporarely less general results
[16:34] <arigo> yes
[16:34] <pedronis> arigo: can I switch the few places using argtypes
[16:35] <pedronis> one problem is that we are going to get a lot of different versions of wrap
[16:35] <arigo> indeed
[16:36] <arigo> we could also hack a bit to avoid the temporarily-less-general issue
[16:37] <arigo> it might even not be that hard
[16:38] <pedronis> when idea was to alwasys mix in the previous result
[16:38] <pedronis> s/when/one
[16:38] <arigo> yes, if we can *find* this previous result
[16:39] <pedronis> yes
[16:42] <pedronis> arigo, another solution is to keep a per location -> used types mapping
[16:42] <pedronis> and use that union of current types with types to decide what to pick
[16:42] <pedronis> arigo: with those types
[16:43] <arigo> the problem is not what to pick, but to make the specialized function's result at least as general as it was the last time
[16:43] <arigo> i.e. a "per location -> already seen return value" mapping should do
[16:44] <pedronis> yes, the other approach may generate less functions
[16:44] <pedronis> but it's a bit more complicated
[16:44] <arigo> "the other" == "the latter" ? yes
[16:45] <pedronis> I mean mixing input types instead of just mixing the result
[16:45] <arigo> we don't need to mix the input types
[16:46] <arigo> the annotator guarantees that they will only ever get more general, for a given location.
[16:48] <pedronis> indeed
[16:49] <pedronis> so we have functions that return less general results with more generals inputs?
[16:49] <pedronis> when specialized
[17:04] <pedronis> arigo: it is easy to construct an example, I admit of being confused right now?
[17:04] <arigo> they return temporarily less general results,
[17:04] <arigo> because they are not fully annotated
[17:04] <arigo> let me try to find an example
[17:09] <arigo> hum, it's difficult to find small examples, I guess because of block ordering
[17:10] <pedronis> I see
[17:10] <pedronis> if :
[17:10] <pedronis> x= less general
[17:10] <pedronis> else:
[17:10] <pedronis> x= more general
[17:11] <pedronis> z = f(x) # f specialized on types
[17:11] <pedronis> but it indeed depends on which order things are analyzed
[17:14] <pedronis> arigo: no, I'm still confused
[17:15] <pedronis> x cannot be less general
[17:16] <arigo> no but it can be different, which means it invokes another f
[17:16] <arigo> this other copy of f can be less completely analysed at this point in time
[17:16] <arigo> so we can temporarily find a less general answer z
[17:19] <pedronis> ok, we don't have this problem with methods because we explicitly mix the answers of all candidates
[17:20] <arigo> right
[17:20] <arigo> if 'self' is generalized to a parent class, the previous methods are still in the lot
[17:21] <pedronis> yes
[17:21] <pedronis> the problem here is that we call different things we could not be fullly analyzed
[17:21] <pedronis> the not fully analyzed plays a central role in the problem
[17:22] <pedronis> s/we/which
[17:23] <arigo> yes.
[17:23] <pedronis> so using mapping location -> previous result for the argtypes case should fix this
[17:23] <arigo> yes
[17:24] <pedronis> but yes constructing an example is not trivial at all, because of the analysis order
[17:24] <arigo> precisely
[17:24] <arigo> I'm trying without success,
[17:25] <arigo> s/,/
[17:26] idnar (mithy@idnar.user) left irc: "leaving"
[17:29] Gromit (~bear@dialin-212-144-177-232.arcor-ip.net) left irc: "supper"
[17:41] <cfbolz> can a SomeInteger be unsigned but not nonnegative?
[17:41] <arigo> possibly
[17:41] <arigo> I guess nonnegative should be ignored if unsigned=True
[17:42] <arigo> if you do a subtraction between r_uints I suppose the nonnegative flag gets lost.
[17:42] <pedronis> I was thinking the same thing yesterday
[17:42] <arigo> :-)
[17:42] <pedronis> nonneg is not that meaningful for unsigned
[17:43] <cfbolz> ah. It's probably unrelated to my problems anyway. I try to find out why W_Longobject is not annotated properly.
[17:43] <cfbolz> It's a problem in my code somewhere but I can't find it.
[17:44] <pedronis> what exactly is not annotated properly?
[17:45] <pedronis> of course the longs may still pollute things
[17:45] <cfbolz> no. I reduced it to the minimal case which contains only my new code
[17:45] <cfbolz> operations with r_uints allways produce r_uints, right?
[17:46] <pedronis> yes, that's what is expected
[17:46] <pedronis> there could be a bug
[17:47] <cfbolz> I rather guess that I forgot to explicitely convert something to a r_uint
[17:48] <arigo> ah, annotator/binaryop.py is not complete wrt unsigned
[17:48] <pedronis> yes the digits list that is annotated properly ?
[17:48] <pedronis> s/yes/is
[17:48] <cfbolz> yes. It degenerates to SomeObject
[17:49] <cfbolz> a list of SomeObject, I mean
[17:49] <arigo> annotation seems to be missing unsigned support for:
[17:49] <arigo> neg
[17:49] <arigo> abs
[17:49] <arigo> pow
[17:49] <arigo> .
[17:49] <cfbolz> and and_
[17:50] <cfbolz> that seems to cause my problem
[17:50] <arigo> how's that? and_ seems to be ok
[17:51] <pedronis> and_ seems correct
[17:51] <arigo> cfbolz: actually there is no chance to annotate it
[17:51] <cfbolz> why?
[17:51] <arigo> unless you remove all references to CPython's long
[17:51] <arigo> (or am I messing something up?)
[17:51] <cfbolz> the annotator is doing quite all right.
[17:51] <cfbolz> The isinstance(digits, long) clause gets removed
[17:52] <arigo> (forget that)
[17:52] <cfbolz> because I never call it with a long as an arg
[17:53] <pedronis> long(x) right now is annotated as SomeObject
[17:53] <pedronis> wich is somehow right but can pollute things
[17:53] <cfbolz> anyway, and_(SomeInteger(noneg=True, unsigned=True), (65536)) is annotated to SomeObject!
[17:53] <cfbolz> maybe the constant is something strange
[17:53] <arigo> argh, or there is confusion between 'and' and 'and_'
[17:53] <cfbolz> ok. I take everything back
[17:54] <cfbolz> (65536L) is a long, of course
[17:56] <cfbolz> targetpypy1 doesn't have any SomeObjects in Function signatures any more :-)
[17:57] <arigo> excellent :-)
[17:58] <cfbolz> and at a first glance it seems if SomeObjects occur anywhere else they are always treated with an isinstance
[17:58] <cfbolz> and have no operations performed on them
[17:58] <arigo> to to go back to genllvm? :-)
[17:59] <cfbolz> yes
[17:59] <cfbolz> :-)
[18:00] <cfbolz> well, there is still a lot to do for W_LongObjects, too. division for an instant
[18:00] <arigo> :-)
[18:00] <cfbolz> But since they support now enough for targetpypy1, maybe I'll try to get that to work with genllvm first
[18:10] Gromit (~bear@dialin-212-144-175-089.arcor-ip.net) joined #pypy.
[18:24] <arigo> grmf
[18:24] <arigo> I am working on fully typed lists in genc
[18:24] <arigo> spent some time getting the conversion between them and PyListObjects right
[18:24] <arigo> now I realize that it makes test fail,
[18:25] <arigo> because you cannot just convert a list to another representation and keep both around
[18:25] <arigo> as changes to one will not show up in the other
[18:25] <arigo> so lists cannot fall back to PyListObject, they must be complete or not there at all...
[18:29] <cfbolz> yes. That's one of the problems I couldn't solve while thinking about using genllvm with the CPython API
[18:31] <cfbolz> You could convert all the elements of the list back and forth all the day.
[18:31] <arigo> but you don't know when to convert them
[18:32] <arigo> once the original and the copy list take an independent live, synchronization becomes essentially impossible
[18:32] <cfbolz> ah. right. the conversion doesn't prevent the original list to be used.
[18:33] <pedronis> well, you need to wrap the RPython list a PyObject wich cannot probably be a PyListObject
[18:33] <pedronis> s/a/as a
[18:33] <arigo> yes, a thin accessor PyMyOwnListObject
[18:34] <arigo> makes some sense, but I have the same problem the other way around
[18:34] <arigo> if you get a PyObject* and wants to have an RPython list of some type
[18:36] <pedronis> that's more difficult problem
[18:38] <pedronis> the other solution is to support only copying
[18:38] <arigo> well, right now I'm doing a no-support approach
[18:41] <pedronis> I'm about to commit something along the lines of what we discussed to preserve the more general results invariant with argtypes specialisation
[18:41] <arigo> good
[18:43] <cfbolz> arigo: when is a list typically used in both incarnations?
[18:45] <arigo> when things are incomplete :-)
[18:45] <arigo> for example, without support for the .append method
[18:45] <arigo> the list is converted to a PyObject, the method called, then the converted list dropped!
[18:46] <cfbolz> ok. couldn't the list be only converted for one operation an converted back afterwards?
[18:47] <arigo> yeees, in theory, but it's fragile
[18:47] <arigo> the one operation could be a call to another function
[18:47] <arigo> then this other function could also have a reference to the original list
[18:48] <cfbolz> and distaster strikes. I guess I'm too simpleminded :-)
[18:49] <arigo> well, mutable objects are much harder to get right for compilers that we imagine
[18:50] <cfbolz> but we're in the process of finding out just how hard
[18:50] <cfbolz> :-)
[18:50] <arigo> :-)
[18:50] <cfbolz> but it's a lot easier if you don't have different representations for the same object
[18:51] <arigo> yes
[18:52] <cfbolz> you could have a flag on the RPython object that tells whether a CPython representation has be created. But then you had to check before each op that uses the RPython version whether you have to convert back.
[18:53] <arigo> yes, the RPython version could have a pointer to the CPython version
[18:53] <cfbolz> exactly
[18:53] <arigo> all in all it's quite messy
[18:54] <cfbolz> yes. And the benefit of using a RPython list at all disapperas
[18:54] <cfbolz> s/peras/pears
[18:55] <arigo> quite so
[18:56] <cfbolz> that kind of prevents the gradual adaption of genc to support more types, right?
[18:57] <arigo> that's a problem, yes
[19:12] <cfbolz> I'm going home. See you tommorow.
[19:12] <arigo> see you!
[19:12] <cfbolz> bye
[19:13] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
----- silence for 31 minutes ----- [19:44] arigo (~arigo@stups.cs.uni-duesseldorf.de) left irc: "dinner time"
[19:55] idnar (mithrandi@idnar.user) joined #pypy.
[20:00] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: "Leaving"
[20:00] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 16 minutes ----- [20:16] idnar (mithrandi@idnar.user) left irc: Read error: 60 (Operation timed out)
[20:20] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: "Leaving"
[20:21] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[20:31] r0g3l10 (~rogelio@201.128.14.213) joined #pypy.
[20:31] Gromit (~bear@dialin-212-144-175-089.arcor-ip.net) left irc: "Client Exiting"
----- silence for 19 minutes ----- [20:50] <stakkars> interesting stuff for this evening. I will try to dive into this completely now.
[20:57] r0g3l10 (~rogelio@201.128.14.213) left irc: "Leaving"
[21:10] Roey (~Roey@Roey.sustaining.supporter.pdpc) joined #pypy.
[21:10] <Roey> hi
[21:10] <Roey> oh cool this place exists.
[21:10] <Roey> hey listen
[21:11] <Roey> is pypy available as a debian module?
[21:11] <Roey> is it still being written?
[21:11] <Roey> has it released??
[21:15] <Roey> oh, I see from the docs how to get its source.
[21:15] <stakkars> it is still quite in the beginning.
[21:16] <Roey> oh ok.
[21:16] <stakkars> well, parts are very far, the interpreter is complete, some C libraries still need back-translation.
[21:16] <Roey> so.. would a python compiler written in python mean it can be extended with extensions written in python???
[21:16] <Roey> ok
[21:17] <stakkars> The current major goal is generating efficient C or what ever code, to get a stand-alone, fast thing.
[21:17] <Roey> stakkars: which C libs are going to remain in C?
[21:17] <stakkars> None
[21:17] <Roey> hmm, ok.
[21:17] <Roey> well at some point they have to interface to system libraries.
[21:17] <stakkars> well, a tiny kernel will need to stay.
[21:17] <stakkars> sure.
[21:18] <Roey> stakkars: wait a sec
[21:18] <Roey> are you Christian Tismer?
[21:23] <stakkars> I think so :-)
[21:32] <hpk> Roey: i can attest that he is himself most of the time :-)
[21:33] Action: hpk slowly recovers from the dentist ...
[21:33] Action: stakkars notices that :-)
[21:38] stakkars (~tismer@82.144.60.19) left irc: "'bye"
[21:47] <Roey> cool
[21:47] <Roey> stakkars: nice to meet you! your name has popped up so many times over the years here and there on the Internet.. (when you come back)
[21:47] <Roey> hpk: hi
[21:47] <Roey> hpk: I need to schedule a dentist appt.
[21:48] <Roey> hpk: somehow out of the blue one of my teeth started hurting when I put cold water on it
[21:48] <hpk> i have to admit that i am not too fond of speaking about teeth problems :-)
[21:53] <Roey> oh :)
[21:53] <Roey> ok
[21:53] <Roey> hpk: what's your name?
[21:53] <Roey> I am Roey
[21:53] <Roey> Holger Krekel, ok.
[21:53] <Roey> nice to meet you
[21:53] <hpk> training self-conversations? :-)
[21:53] <Roey> wie ist deiner Deutsch?
[21:53] <Roey> ;)
[21:53] <Roey> *dein, deiner, (?)
[21:54] <hpk> not very good, i am mostly talking english anyway
[21:54] <hpk> dein
[21:54] <Roey> ah
[21:54] <Roey> oh
[21:54] <Roey> you're not german?
[21:54] <hpk> i am, kind of
[21:54] <Roey> ok
[21:54] <Roey> are you turkish??
[21:54] <Roey> (there are many Turks in Germany)
[21:55] <hpk> yes, well that is a somewhat complicated question
[21:55] <Roey> ah
[21:55] <hpk> which could easily get us into a philosophy course
[21:55] <Roey> ;)
[21:55] <Roey> so what langs do you nkow
[21:55] <Roey> *know
[21:55] <hpk> and i am actually in programming mood right now ...
[21:55] <hpk> mostly english and german
[21:55] <hpk> some spanish at some point but that's it
[21:56] <Roey> oh ok
[22:05] arigo (~arigo@134.99.18.225) joined #pypy.
[22:08] <hpk> arigo: hi armin
[22:08] <arigo> hi!
[22:08] <Roey> hi
[22:08] <hpk> arigo: i think i am going to open up/hang out on a new "#pylib" channel to not pollute the pypy channel too much :-)
[22:09] <hpk> i just had some wild ideas about execnet
----- silence for 17 minutes ----- [22:26] Action: pedronis leaving
[22:26] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
[22:28] <hpk> Roey: it's not private but it's implementation discussions :-)
[22:30] <Roey> ah ok
[22:30] <Roey> it'd certainly go over my head then!!
[22:31] <hpk> implementation discussions not even about pypy directly
[22:31] <hpk> but about http://codespeak.net/py/current/doc/execnet.html
[22:31] <hpk> which you might or might not find interesting enough to waste brain cells on :-)
[22:32] Action: Roey reads
----- silence for 22 minutes ----- [22:54] <Roey> 1.3 What about Security? Are you completly nuts?
[22:54] <Roey> change the typo
[22:54] <Roey> from "completly" to "completely"
[22:54] <Roey> in the above link
[22:58] <hpk> fixed, thanks
[23:01] <Roey> =)
[23:03] <Roey> are you familiar with KDE's DCOP protocol?
[23:03] <hpk> nope
[23:03] <Roey> I was thinking maybe that had some overlap with this project
[23:03] <Roey> ah
[23:03] <Roey> dcop is how KDE apps communicate
[23:03] <hpk> yes, i know that much :-)
[23:10] <Roey> ah ok :)
[23:10] <Roey> could execnet be implemented in Twisted?
[23:11] <hpk> it should be usable in some way, i haven't tried
[23:11] <dialtone> I think so
[23:11] <Roey> ok
[23:11] <Roey> like
[23:12] <Roey> are you guys positioning this library for inclusion into the SPL?
[23:12] <Roey> (standard python library)
[23:12] <hpk> not on my part
[23:12] <dialtone> but probably hpk doesn't want twisted as a dep ;)
[23:12] <dialtone> which is reasonable
[23:12] pedronis (~Samuele_P@c-358b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[23:12] <Roey> I see.
[23:13] <Roey> dialtone: I had to not use the python http libs because they are blocking
[23:13] <dialtone> that's why you can write your own protocol implementation in twisted and use it with execnet transparently
[23:13] <Roey> dialtone: and instead I used KIO::get()
[23:13] <Roey> ok
[23:13] <dialtone> twisted has already 2 http implementations :)
[23:13] <Roey> I know I know
[23:13] <Roey> I didn't want to use twisted because I didn't feel like adding yet another dep to my python kde program
[23:14] <Roey> maybe someday when it will be standard on all distributions
[23:14] <dialtone> now that it has been split you may consider distributing it with your app
[23:14] <dialtone> to remove the dep
[23:14] <dialtone> just distribute twisted-code and twisted-web (or web2
[23:15] <hpk> but these are two deps instead of one, no?
[23:16] <hpk> btw, we might want to switch this discussion to the new #pylib channel to not pollute #pypy to much :-)
[23:16] <dialtone> there's the Twisted-Sumo if you don't like separation :)
[23:16] <dialtone> sure
[23:17] <hpk> Roey: we switched the discussion to the #pylib channel
[23:19] <Roey> oh, ok
----- silence for 26 minutes ----- [23:45] arigo (~arigo@134.99.18.225) left irc: "[x]chat"
[00:00] --- Wed Apr 13 2005