| dialtone (n=dialtone@213-156-52-97.fastres.net) joined #pypy. | 01:12 | |
| __lucio___ (n=__lucio_@190.50.219.209) joined #pypy. | 05:33 | |
| __lucio__ (n=__lucio_@190.50.210.15) left irc: Read error: 110 (Connection timed out) | 05:51 | |
| cursor (n=peter@brln-4d05302b.pool.mediaWays.net) joined #pypy. | 06:53 | |
| cmusick (n=cmusick@s188.IaichiFL48.vectant.ne.jp) got netsplit. | 06:55 | |
| cmusick (n=cmusick@s188.IaichiFL48.vectant.ne.jp) returned to #pypy. | 06:55 | |
| lac_ (n=lac@c-22c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy. | 06:59 | |
| lac (n=lac@pdpc/supporter/gold/lac) left irc: Read error: 110 (Connection timed out) | 07:07 | |
| Rhamphoryncus (n=rhamph@unaffiliated/rhamphoryncus) left irc: "Valid HTML! http://validator.w3.org/ | Support ISO 8601! http://www.cl.cam.ac.uk/~mgk25/iso-time.html" | 07:08 | |
| jacob22 (n=jacob@c-22c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Read error: 110 (Connection timed out) | 07:09 | |
| jacob22 (n=jacob@c-22c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy. | 07:09 | |
| __lucio___ (n=__lucio_@190.50.219.209) left irc: | 07:26 | |
| cursor (n=peter@brln-4d05302b.pool.mediaWays.net) left irc: | 07:43 | |
| pedronis (n=chatzill@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy. | 08:23 | |
| lac_ (n=lac@pdpc/supporter/gold/lac) left irc: "using sirc version 2.211+KSIRC/1.3.12" | 08:24 | |
| cursor (n=peter@brln-4d0543ba.pool.mediaWays.net) joined #pypy. | 09:21 | |
| fijal (n=fijal@245.142.broadband3.iol.cz) joined #pypy. | 09:49 | |
| fijal | hi | 09:49 |
|---|---|---|
| pedronis | mmh, running py.test -d rpython shows various obscure failures | 09:52 |
| fijal | -d you say... | 09:53 |
| fijal | hum | 09:53 |
| fijal | what exactly? | 09:53 |
| fijal | cache problems? | 09:53 |
| fijal | pedronis: how was dyla? | 09:53 |
| pedronis | extregistry problems | 09:53 |
| pedronis | duplicate entries or entries not found | 09:54 |
| pedronis | this is using all linux machines | 09:54 |
| fijal | well, the duplicate extregistry | 09:54 |
| fijal | is usually a problem which is reported above, but swallowed | 09:54 |
| fijal | no idea why | 09:55 |
| pedronis | rpython/test/test_extfuncregister.py fails locally too | 09:56 |
| fijal | it works for me | 09:57 |
| fijal | hum | 09:57 |
| pedronis | did you update? | 09:57 |
| pedronis | it failed on wyvern too | 09:57 |
| arigato (n=arigo@d83-180-98-57.cust.tele2.ch) joined #pypy. | 09:57 | |
| pedronis | arigato: morning | 09:58 |
| fijal | yes, I've got it up to date | 09:58 |
| fijal | arigato: hi | 09:58 |
| fijal | pedronis: no, it works for me | 09:59 |
| Action: fijal tries fresh checkout | 09:59 | |
| fijal | ah no, armin broke it somehow | 10:00 |
| fijal | of course :) | 10:00 |
| fijal | it's 45473 | 10:00 |
| fijal | lookup fails with KeyError | 10:00 |
| pedronis | arigato: test_extfuncregister.py doesn't pass anymore, together with other stuff | 10:00 |
| fijal | looks like armin didn't really wake up :) | 10:01 |
| fijal | pedronis: how was dyla? | 10:01 |
| arigato | hi | 10:02 |
| arigato | oups | 10:02 |
| arigato | oups oups, stupid typo, give me 2.5 seconds | 10:02 |
| Action: fijal gives up asking about dyla | 10:03 | |
| liptone | arigo - r45482 - Oups! | 10:04 |
| arigato | fijal: dyla went nicely | 10:05 |
| pedronis | arigato: you didn run the tests ;) | 10:05 |
| arigato | I'd like to write a bit more about it, but with cfbolz when he's back from the rest of ECOOP | 10:05 |
| fijal | anything interesting different than pypy? | 10:05 |
| fijal | ah, ok | 10:05 |
| arigato | pedronis: not all of them, no :-) sorry | 10:05 |
| fijal | so I'll read it later | 10:05 |
| fijal | I'm off for a while, will be back in 2h | 10:05 |
| pedronis | I want to do a bit more of malloc mess cleanup today | 10:05 |
| arigato | fijal: see also the irc logs of two days ago | 10:05 |
| Action: fijal reads | 10:06 | |
| fijal | arigato: I think it makes sense to do pypy-1.0-sandbox release | 10:07 |
| fijal | cause it's something that is missing in python and also we don't need too much of external library support for that | 10:07 |
| fijal | (would be nice to make it more secure on rpython level - like check for NULL pointers + check for list lenghts always, etc.) | 10:07 |
| fijal | anyway | 10:07 |
| Action: fijal off | 10:07 | |
| pedronis | we need to fix some other bugs before is reccomendable tough | 10:08 |
| fijal | yes, sure | 10:08 |
| fijal | I'm talking about future | 10:08 |
| pedronis | at least weakrefs | 10:08 |
| fijal (n=fijal@245.142.broadband3.iol.cz) left irc: "Leaving" | 10:08 | |
| pedronis | I just don't want to have to make another release when we have to say that even basic things are not that stable | 10:09 |
| arigato | yes, makes sense | 10:09 |
| arigato | that too | 10:09 |
| arigato | (note also that a weakref-less sandboxed Python would already be quite useful in many cases) | 10:27 |
| cursor (n=peter@brln-4d0543ba.pool.mediaWays.net) left irc: Read error: 110 (Connection timed out) | 10:30 | |
| xorAxAx | why weakrefless? | 10:33 |
| arigato | because they can crash currently | 10:34 |
| xorAxAx | because they are broken? | 10:35 |
| arigato | yes | 10:38 |
| pedronis | I see, but I still think that giving signal of improved stability is as important as giving out experimental features | 10:42 |
| Nick change: liptone -> lungtone | 10:54 | |
| xorAxAx | lungtone: rename weakref | 11:01 |
| Nick change: lungtone -> weakreftone | 11:01 | |
| arigato (n=arigo@d83-180-98-57.cust.tele2.ch) left irc: Read error: 110 (Connection timed out) | 11:12 | |
| santagada (n=santagad@201-14-124-120.bsace706.dsl.brasiltelecom.net.br) joined #pypy. | 12:58 | |
| cmusick (n=cmusick@s188.IaichiFL48.vectant.ne.jp) left irc: "Quick! Kill your client! Bersirc 2.2 is here! [ http://www.bersirc.org/ - Open Source IRC ]" | 13:17 | |
| fijal (n=fijal@245.142.broadband3.iol.cz) joined #pypy. | 13:21 | |
| Action: fijal back | 13:21 | |
| fijal | pedronis: sandboxed version would be really cool. But also waiting a bit for more mature release would be useful as well | 13:24 |
| santagada (n=santagad@201-14-124-120.bsace706.dsl.brasiltelecom.net.br) left irc: "good bye" | 13:30 | |
| cmusick (n=cmusick@s188.IaichiFL48.vectant.ne.jp) joined #pypy. | 14:06 | |
| doc_python (n=doc_pyth@84-73-211-45.dclient.hispeed.ch) joined #pypy. | 14:13 | |
| __doc__ (n=lbo@62-2-90-134.static.cablecom.ch) left irc: Nick collision from services. | 14:14 | |
| Nick change: doc_python -> __doc__ | 14:14 | |
| __doc___ (n=lbo@62-2-90-134.static.cablecom.ch) joined #pypy. | 14:14 | |
| fijal | exarkun: hey | 14:19 |
| stakkars (n=tismer@i577B7405.versanet.de) joined #pypy. | 14:33 | |
| fijal | stakkars: hi | 14:33 |
| lac (n=lac@pdpc/supporter/gold/lac) joined #pypy. | 14:34 | |
| stakkars_ (n=tismer@i577B7766.versanet.de) left irc: Read error: 110 (Connection timed out) | 14:42 | |
| stakkars | fijal: hi | 14:54 |
| fijal | stakkars: have you seen my pypy-dev mail? | 14:55 |
| stakkars | no, I was busy with my talk abstract (still not ready) | 14:56 |
| fijal | for what? | 14:56 |
| fijal | anyway, you should like it :) | 14:56 |
| fijal | (regarding stackless performance vs erlang) | 14:57 |
| Action: exarkun yawns | 15:01 | |
| fijal | exarkun: I asked you a question yesterday :) | 15:02 |
| exarkun | good morning | 15:02 |
| exarkun | fijal: I probably didn't know the answer | 15:02 |
| exarkun | let's see what I can make up | 15:02 |
| exarkun | OpenSSL is needed for a bunch of functionality, so are a couple other extensions to a lesser degree (eg, pycrypto) | 15:03 |
| fijal | pycrypto? what's that? | 15:03 |
| fijal | openssl sounds like a plan | 15:03 |
| exarkun | there might be something funny w/ the socket module, I saw a couple "bad file descriptor" errors I think | 15:04 |
| exarkun | pycrypto has a bunch of crypto related stuff in it :) some of it is in python but it has extension modules too | 15:05 |
| fijal | well, socket module is somehow scary | 15:05 |
| exarkun | for things like aes mostly | 15:05 |
| fijal | I'm quite sure it segfaults together with threads | 15:05 |
| exarkun | oof :( | 15:06 |
| fijal | there is bunch of things which are not working in pypy (like weakrefs) which really need to be fixed | 15:06 |
| fijal | I don't know how much this relates to threads and how much to socket to be honest | 15:06 |
| fijal | exarkun: openssl like ssl objects in socket or wrapper around openssl? | 15:07 |
| exarkun | erm, sorry, /PyOpenSSL/ - so wrapper around openssl | 15:07 |
| exarkun | although tbh, if pypy-c gets to the point of being usable, it would be worthwhile for someone (maybe me) to implement a new layer of ssl support based on a better OpenSSL wrapper than PyOpenSSL, if pypy has one | 15:08 |
| fijal | "if pypy-c gets to the point of being usable" | 15:08 |
| fijal | you know, "in the fullness of time"... | 15:08 |
| exarkun | :) | 15:08 |
| fijal | I'm trying hard :) | 15:09 |
| exarkun | progress is definitely being made | 15:09 |
| stakkars | fijal: ah, thanks! | 15:09 |
| fijal | still, there are some issues hard to tackle | 15:09 |
| fijal | (ie threads) | 15:09 |
| stakkars | yes, interesting. Although it seems that in the end stackless is slower than erlang? | 15:09 |
| exarkun | I guess there are some gc issues outstanding too? | 15:09 |
| stakkars | is Erlang a compiled language? | 15:10 |
| fijal | exarkun: yes | 15:10 |
| fijal | stakkars: I don't know | 15:10 |
| fijal | well, but gc is bigger question, rffi is first step towards implementing better gc's | 15:10 |
| fijal | (gc is only performance question) | 15:10 |
| exarkun | stakkars: it has a native code compiler, yes | 15:10 |
| exarkun | I'm not sure if it was used in the benchmarks fijal linked to | 15:10 |
| stakkars | ah. So this is comparing apples to peaches | 15:11 |
| fijal | stakkars: but it's still not worth to invest time in erlang if it's just slightly faster | 15:11 |
| fijal | stakkars: not really | 15:11 |
| exarkun | probably the more interesting thing about E is what one of the people pointed out in the comments on that page | 15:11 |
| fijal | exarkun: what was that? | 15:11 |
| exarkun | which is that you can run each of your processes (E for "thread") on a different computer without doing any extra work | 15:12 |
| stakkars | actually, time is spent in the interpreter. Things can become interesting with PyPy and the example written in RPython, at some point | 15:12 |
| fijal | yes, but it assumes you did extra work already | 15:12 |
| exarkun | fijal: wrote your program in E? :) | 15:12 |
| fijal | yes :) | 15:13 |
| exarkun | hmm why do I keep saying E. | 15:13 |
| stakkars | exarkun: yes, good point. This is something to try with Stackless PyPy, not in C any more | 15:14 |
| exarkun | stakkars: yea :) | 15:14 |
| fijal | exarkun: have you tried running any twisted application on top of pypy-c? | 15:15 |
| fijal | or too early? | 15:15 |
| stakkars | so adding to my intentions why I wanted PyPy is to have an easy way to extend/improve heavily on Stackless :-) | 15:16 |
| exarkun | fijal: not yet | 15:16 |
| fijal | exarkun: +1 | 15:17 |
| fijal | exarkun: anyway, I guess that you'll need to wait a bit, there is need for huge fixes/refactorings in pypy now | 15:20 |
| fijal | sorry :) | 15:26 |
| exarkun | fijal: understandable. are there ideas for how those things need to happen yet? | 15:28 |
| fijal | not that I know of :) | 15:30 |
| fijal | well, threads need to be fixed and I'll try to tackle those | 15:30 |
| fijal | (ie cpython regression test hang) | 15:31 |
| fijal | there is a pressure on simplification of malloc engine | 15:31 |
| fijal | which will eventually lead to new gcs (well, in a long run) | 15:31 |
| fijal | exarkun: when py3k will be out? | 15:43 |
| exarkun | pretty soon I guess, a month from now or something like that? | 15:44 |
| fijal | exarkun: so no, pypy won't be usable before py3k is out :) | 15:45 |
| exarkun | well, that's alright | 15:46 |
| exarkun | py3k won't be usable before py3k is out, either | 15:46 |
| fijal | even after I guess for a while | 15:47 |
| exarkun | yea | 15:47 |
| stakkars | ok I posted to this Erlang Blog. Let's see what happens. | 15:50 |
| idnar | exarkun: you mean Erlang just now, not E, right? | 15:50 |
| exarkun | yes | 15:51 |
| fijal | stakkars: link please? | 15:52 |
| stakkars | fijal: why, it is your link you mailed me. | 15:53 |
| stakkars | http://muharem.wordpress.com/2007/07/31/erlang-vs-stackless-python-a-first-benchmark/#comment-1780 | 15:53 |
| fijal | stakkars: laziness mostly. You've got it in your browser, sorry :) | 15:54 |
| fijal | stakkars: "... PyPy project, which is going to be | 15:55 |
| fijal | the superior Python at some point." - bold statement | 15:55 |
| stakkars | yes, this is my conviction | 15:56 |
| fijal | stakkars: I share your point, absolutely | 15:56 |
| fijal | but it's still not-right-now | 15:56 |
| fijal | stakkars: If I won't I'll not invest my own time in that, believe me :) | 15:56 |
| stakkars | "going to be" is not right now | 15:56 |
| fijal | sure ;-) | 15:56 |
| fijal | well, there are open questions | 15:57 |
| fijal | like "why stackless build is 20% slower" | 15:57 |
| fijal | or so | 15:57 |
| fijal | I still claim that pypy is superior already, no doubt, but going to broader audience is somewhat scary for me | 15:57 |
| fijal | stakkars: also pypy did not try any other model than gil (and even gil is broken) so this needs time | 15:59 |
| fijal | still I'm not questioning superiority of pypy :) | 15:59 |
| stakkars | yes. I know why, I just can't yet see how to reduce this. The stackless support is actually too fine-grained. | 15:59 |
| fijal | what do you mean? | 16:00 |
| fijal | I meant "why?" | 16:01 |
| fijal | pedronis: are you there? | 16:02 |
| stakkars | you can switch between RPython coroutines in low-level, and 50% of all fns create extra support code, which clobbers the generated code. Although Stackless only needs to jump between app-level things. | 16:02 |
| pedronis | fijal: what's up? | 16:03 |
| fijal | pedronis: I think I need help with rpython and threads :-/ | 16:03 |
| pedronis | not now | 16:03 |
| stakkars | we are taking little advantage of this super-capability, so it's a waste. Just hard to change | 16:03 |
| pedronis | I'm working on cleaning up malloc | 16:03 |
| pedronis | a bit more | 16:03 |
| weakreftone | fijal - r45485 - Intermediate checkin, some support for thread.start_new_thread | 16:04 |
| fijal | stakkars: ah, I got it | 16:04 |
| fijal | pedronis: ok, I'll be off soon, you can take a look at last checkin if you have time and will | 16:04 |
| stakkars | there are some things: | 16:04 |
| fijal | I'm trying to have some thread.start_new_thread extregistry entry and I receive strange errors | 16:04 |
| stakkars | We would need to transform in a way that we can take advantage of tail recursion, producing less state to save | 16:05 |
| stakkars | then we would need a way to save state without much extra code in every function. But I don't | 16:06 |
| stakkars | see how to do this with a C backend, since the locals must be visible. | 16:06 |
| fijal | well, not that I've got a solution out-of-the-box | 16:06 |
| fijal | but I see your problem | 16:07 |
| stakkars | Actually, it would be more efficient if the unwind handling could be outside the functions. | 16:07 |
| fijal | the idea would be to have stackless transform, transform only functions which are really up to save state, right? | 16:07 |
| stakkars | so the C implementation is still more efficient, while also more incomplete :) | 16:07 |
| fijal | not sure if I express this in an understandable manner :-/ | 16:08 |
| fijal | stakkars: well, the problem is that the only way to build I/O applications is to use stackless or threads | 16:08 |
| stakkars | fijal: well, I think we do this already. But there are lots of state which is not really needed. | 16:08 |
| fijal | threads are not there (and are sucky), so we really need stackless in some sense | 16:09 |
| stakkars | that's good for the stackless idea | 16:09 |
| fijal | what's good? | 16:10 |
| pedronis | that our thread sucks? | 16:10 |
| fijal | well, that's not good in any case | 16:11 |
| stakkars | hehe, yes a bit. Don't worry, joking | 16:11 |
| fijal | I'm worrying | 16:11 |
| fijal | stakkars: the thing about pypy is "we support every possible paradigm you would like to have" which is simply not true | 16:15 |
| stakkars | fijal: did I say that? | 16:16 |
| fijal | well, not really, but we're missing a point having broken or none implementation of thread | 16:16 |
| fijal | IMHO | 16:16 |
| stakkars | we? | 16:18 |
| pedronis | well, we have various broken stuff, nothing special about any of them, apart that adding new stuff instead of fixing the old broken one is not a completely sane thing | 16:18 |
| fijal | pedronis: we've got mostly threads and weakrefs, anything else? | 16:18 |
| pedronis | the LLVM backend is broken for example | 16:19 |
| fijal | well, that's a different issue | 16:19 |
| stakkars | no | 16:19 |
| pedronis | the extcompiler is kind of broken too | 16:19 |
| fijal | js frontend is broken as well, but we can leave without it | 16:19 |
| fijal | we can still say that we've got nice and cool python interpreter without extcompiler or llvm backend | 16:20 |
| fijal | s/leave/live/ | 16:20 |
| fijal | but we cannot say that without threads | 16:20 |
| pedronis | well, we need to finish converging to a sane style of ext functions, to decide how to proper GIL release around them | 16:20 |
| fijal | that's happening (slowly) | 16:21 |
| stakkars | if you are reducing the scope of PyPy to compete with CPython, yes. | 16:21 |
| fijal | stakkars: well, how can we leave without a bit of reduce? | 16:24 |
| fijal | stuff like extcompiler needs serious work, for which I don't see volunteers | 16:24 |
| stakkars | leave what? | 16:25 |
| fijal | s/leave/live/ | 16:25 |
| fijal | I would blame my disgraphy :) | 16:25 |
| fijal | dysgraphia | 16:26 |
| stakkars | pedronis: ext functions are the blocker to get threading correctly? | 16:26 |
| fijal | stakkars: no | 16:27 |
| pedronis | a bit | 16:27 |
| fijal | heh :) | 16:27 |
| pedronis | releasing the GIL around a mess of different approaches to call external function is a mess | 16:27 |
| fijal | we've got enough support now, we just need to move stuff, am I right? | 16:28 |
| stakkars | messines, a transitive propery :) | 16:28 |
| pedronis | well, we need to think how to release the GIL properly in the rffi world | 16:28 |
| fijal | still, it's easier than question "how to release GIL here, here and there" | 16:28 |
| fijal (n=fijal@245.142.broadband3.iol.cz) left irc: Remote closed the connection | 16:43 | |
| weakreftone | pedronis - r45486 - make this test really test something and skip it because right now it is broken. malloc removal doesn't know about zero malloc | 17:24 |
| Rhamphoryncus (n=rhamph@unaffiliated/rhamphoryncus) joined #pypy. | 17:36 | |
| stakkars | weakreftone: rename GIL | 17:46 |
| Nick change: weakreftone -> GILtone | 17:46 | |
| Rhamphoryncus | mmm GIL | 18:32 |
| dialtone (n=dialtone@213-156-52-97.fastres.net) left irc: Read error: 110 (Connection timed out) | 18:36 | |
| dialtone (n=dialtone@213-156-52-97.fastres.net) joined #pypy. | 18:44 | |
| Dekcarki (i=rico@port-ip-213-211-228-77.reverse.mdcc-fun.de) joined #pypy. | 18:53 | |
| Action: pedronis is mostly through slaying flavored_malloc_* and zero_malloc* | 19:09 | |
| lac | pedronis is a hero. Would you like a laurel wreath or the king's daughter? | 19:41 |
| pedronis | :) | 19:42 |
| Dekcarki (i=rico@port-ip-213-211-228-77.reverse.mdcc-fun.de) left irc: Read error: 104 (Connection reset by peer) | 20:00 | |
| Dekcarki (i=rico@port-ip-213-211-228-77.reverse.mdcc-fun.de) joined #pypy. | 20:13 | |
| DR0ID_ (n=DR0ID_@241.156.77.83.cust.bluewin.ch) joined #pypy. | 20:19 | |
| DR0ID_ | huh, more people than i expected ;-) | 20:20 |
| DR0ID_ (n=DR0ID_@241.156.77.83.cust.bluewin.ch) left #pypy. | 20:20 | |
| Dekcarki (i=rico@port-ip-213-211-228-77.reverse.mdcc-fun.de) left irc: "Verlassend" | 20:34 | |
| DR0ID_ (n=DR0ID_@241.156.77.83.cust.bluewin.ch) joined #pypy. | 20:37 | |
| DR0ID_ | so here I am (again) | 20:37 |
| lac | rehi DR0iD_ | 20:37 |
| lac | so you were asking how pypy is going. | 20:37 |
| DR0ID_ | yes | 20:38 |
| DR0ID_ | wait | 20:38 |
| lac | as a scientific experiment, it is successful beyond the wildest dreams, | 20:38 |
| DR0ID_ | let me ask fist something: | 20:38 |
| lac | sure | 20:38 |
| DR0ID_ | if I understand the pypy project correctly, you try to write a "trasnformer" that transforms python code to native c code (or other languages too), right? | 20:38 |
| lac | yes, also we can take input from other languages than python, prolog works | 20:39 |
| lac | scheme is getting very close. | 20:39 |
| DR0ID_ | ok, so I got the idea right | 20:39 |
| lac | as in it works for a lot of it, not all yet. | 20:39 |
| lac | you have more questions, or do I try to answer your question now? | 20:40 |
| DR0ID_ | no more question at the moment :-) | 20:40 |
| lac | Ok, I am trained to be a university professor. | 20:41 |
| DR0ID_ | :-) | 20:41 |
| lac | and when we lecture we are suppsoed to look at our students to tell if we are boring them with stuff they already know | 20:41 |
| lac | I cannot see you. | 20:41 |
| lac | If I bore, 'type up' ok? | 20:41 |
| Action: DR0ID_ ist listening | 20:41 | |
| DR0ID_ | ok | 20:41 |
| lac | Ok, everbody on the planet says 'C++ is the language to learn because it is fast' | 20:42 |
| lac | and 'dynamic languages are slow' | 20:42 |
| lac | and you think about that for a bit, and then conclude: | 20:42 |
| lac | but LISP was dynamic, and LISP was fast. | 20:42 |
| lac | Therefore, being dynamic is not a-priori a barrier for being slow. | 20:43 |
| mmarshall (n=mmarshal@190.4.208.45) joined #pypy. | 20:43 | |
| lac | It merely has never been done. | 20:43 |
| DR0ID_ | hmm | 20:43 |
| lac | mmarshall: you want a recap of what I already said? | 20:44 |
| DR0ID_ | question: what is the exact difference in static and dynamic languages? | 20:44 |
| lac | statically typed: i.e you declare the type of your variables ahead of time. int x y | 20:44 |
| DR0ID_ | ok | 20:44 |
| lac | like C does. or C++ | 20:45 |
| DR0ID_ | and dynamic as in python where a= something | 20:45 |
| lac | so, clearly the job is harder for a language where you can reassign the types. | 20:45 |
| lac | and in particular, you have to look at how a thing is used before you can tell | 20:45 |
| lac | what it has been used for. | 20:46 |
| lac | And, if you are going to have a dynamic language type inferring machine | 20:46 |
| lac | you will need a lot of memory for that. Memory we did not have 35 years ago | 20:47 |
| DR0ID_ | just wondering, how does it the interpreter of python? | 20:47 |
| DR0ID_ | because the interpreter is written in C++, right? | 20:47 |
| lac | when the c ommoin wisdowm 'dynamic language must be slow' was written. | 20:47 |
| lac | DR0ID: you are confused. There is the python we all know and love. 2.5 is the top version. | 20:48 |
| lac | It is written in C, for the most part, not C++ | 20:48 |
| DR0ID_ | well, right | 20:48 |
| DR0ID_ | but still | 20:48 |
| lac | then there is PyPy. We made a subset of Python -- or mostly makde rules for ourselves which | 20:49 |
| lac | are a subset of what you can do in python. | 20:49 |
| DR0ID_ | if I declare in python a=something | 20:49 |
| lac | we call this RPython, for restricted Python. | 20:49 |
| DR0ID_ | then the C code of python must handle this in a way | 20:49 |
| lac | and pypy is written in Rpython. | 20:49 |
| DR0ID_ | how? | 20:49 |
| lac | and then we generate C code. | 20:49 |
| DR0ID_ | ok | 20:50 |
| lac | we handle all of the language stuff in python. | 20:50 |
| lac | or rather this: | 20:50 |
| mmarshall | lac: sure, I'll take a recap (my internet connection is reeeaaallly slow, but I can follow along.) | 20:50 |
| lac | http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html | 20:50 |
| lac | ok, mmarshall -- about to paste the bit you missed into a msg bin to you | 20:51 |
| lac (n=lac@pdpc/supporter/gold/lac) left irc: Excess Flood | 20:52 | |
| lac (n=lac@c-22c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy. | 20:52 | |
| lac | ow, i was disonnected | 20:52 |
| lac | maybe pasting in 35 lines to mmarshal privately was a bad idea. | 20:53 |
| lac | maybe was independent. | 20:53 |
| DR0ID_ | yeah Exces flood | 20:53 |
| DR0ID_ | [21:53] lac has disconnected: Excess Flood | 20:53 |
| lac | ok, my fault. | 20:53 |
| lac | ok. so, given that we got lots of memory then how can you get speed? why is it that statically typed ones do get speed? | 20:55 |
| lac | and the answer is that they pre-know that this is an int and an int, and therefore an int int add. | 20:55 |
| DR0ID_ | yes | 20:55 |
| lac | now when CPython (what we call 2.5 and predeçessors, what you are used to calling python) | 20:56 |
| lac | goes to add 2 integers, it knows that it has 2 integers as well. | 20:56 |
| lac | But it has to figure those things out every time afresh. | 20:57 |
| Rhamphoryncus | int or long ;) | 20:57 |
| DR0ID_ | ok that extry figuring out is making it slower? | 20:57 |
| DR0ID_ | extra* | 20:57 |
| lac | (just say int for now. this is a cool question, but orthogonal to the point I want to make) | 20:57 |
| lac | so, if you were willing to do it, you could say -- last time I added those things together, they were int plus | 20:58 |
| Rhamphoryncus | (yeah. int->long is actually a SECOND reason why python is slower than C) | 20:58 |
| lac | int. So if I just kept the int-adding framework around | 20:58 |
| lac | then the next time I needed to add some ints, | 20:59 |
| lac | I could reuse it, rather than generate it on the fly. | 20:59 |
| lac | This would be faster, at the price of a lot of memory left around. | 20:59 |
| lac | Does this make sense to you? | 21:00 |
| DR0ID_ | sure | 21:00 |
| DR0ID_ | you still need the check, but the framework is in memory | 21:00 |
| lac | we do dirty tricks like this in the graphics world all the time, but pure computer languages frown on it. | 21:00 |
| lac | correct. | 21:00 |
| lac | So there is this person called Armin Rigo, and he thought of this. | 21:00 |
| lac | he is usually around here as 'arigato' or 'arigo' | 21:01 |
| lac | but not now. | 21:01 |
| lac | And he made psyco | 21:01 |
| lac | have you ever heard of that? | 21:01 |
| DR0ID_ | ah, psyco, always wondered how it works | 21:01 |
| DR0ID_ | yes I have | 21:02 |
| lac | Ok, it works like that, but since its for Cpython, it has to do its work in C | 21:02 |
| DR0ID_ | I'm just reading the link you gave | 21:04 |
| DR0ID_ | you have some restrictions in pypy? | 21:04 |
| lac | ok. mmarshall and anybody else who is reading this but not understanding, speak up now | 21:04 |
| lac | yes, that was the coding guide I gave you which listed the restrictions in RPYTHON. | 21:05 |
| lac | we have written python-in-python, yes, but we have to be careful internally to not use the most | 21:05 |
| DR0ID_ | so the restrictions are for RPYTHON and not for python itself? | 21:05 |
| lac | dynamic features of python. | 21:06 |
| lac | we can interpret all of python, as duýnamic as you like, and Jit it and everything. | 21:06 |
| mmarshall | I'm following :) | 21:06 |
| lac | but if you want to hack on the compiler part you need to use rpython -- python with | 21:06 |
| lac | restrictions. | 21:06 |
| DR0ID_ | ok | 21:07 |
| lac | one of them is 'global variables cannot be changed' | 21:07 |
| DR0ID_ | I have seen that, like 'const' typed variable in C | 21:07 |
| lac | so, what we write is in python, it is just that we cannot use the language to its most flexibleness. | 21:07 |
| lac | It is still pleanty more flexible than C or C++ | 21:08 |
| lac | and that is the point. | 21:08 |
| DR0ID_ | sure | 21:08 |
| lac | Very high level languages have their advantages in writing compilers too. | 21:08 |
| lac | So here is Armin Rigo and he writes pysco | 21:08 |
| lac | http://psyco.sourceforge.net/ | 21:09 |
| lac | and psyco is an extension module that you can load with your regular python program and it will speed it up | 21:09 |
| DR0ID_ | yes, doing magic ;-) | 21:10 |
| lac | especially for pygame people like you two. | 21:10 |
| lac | because we do lots and lots and lots of integer ops | 21:10 |
| DR0ID_ | that is true | 21:10 |
| lac | so saving that around makes a lot of sense for us to be faster | 21:10 |
| lac | But then, one day, Armin thought, it is a real pain in the ass to have to recode all this C | 21:11 |
| lac | all the time. | 21:11 |
| DR0ID_ | it is some sort of caching the data | 21:11 |
| lac | Wy not have a high level language version of this. | 21:11 |
| lac | and since Armin knows python, this is the language he would prefer to write compilers in. | 21:12 |
| lac | It is a pretty good language for this, as well. | 21:12 |
| lac | Ruby would also be good, as would lisp or scheme. | 21:12 |
| lac | C++ would not. | 21:12 |
| lac | perl would not but for different reasons. | 21:12 |
| DR0ID_ | so he is involveld into pypy too? | 21:13 |
| lac | armin? he is one of the 2 or 3 lead people of it. | 21:13 |
| DR0ID_ | oh, ok | 21:13 |
| lac | these days he is 'mr. pypy' not just 'mr. psyco' | 21:13 |
| DR0ID_ | :-) | 21:13 |
| lac | But should samuele pedroni (pedronis here, who is awake and will correct me if I go wrong) | 21:14 |
| lac | want to be called 'mr. pypy' he can take that title too. | 21:14 |
| __lucio__ (n=__lucio_@190.50.219.209) joined #pypy. | 21:15 | |
| lac | also stakkars: christain tismer | 21:15 |
| lac | and cfbolz: carl fredreich bolz | 21:15 |
| lac | and hpk: holger Krekel | 21:15 |
| lac | those people and me were at the very first pypy sprint. actually samuele wasn't | 21:16 |
| lac | these days jakub and fijal and simonpy are doing a lot of work, as is pauldeg. | 21:17 |
| lac | jacob22 and I work a tiny bit when we can. | 21:17 |
| lac | The rest of the people here watch mostly, though some have attended sprints and made code at one time. | 21:17 |
| DR0ID_ | ok | 21:18 |
| lac | I am probably deeply slighting somebody here. | 21:18 |
| lac | but the rest are lurkers. | 21:18 |
| lac | AntonK: you are not a lurker! you are contrinbuting even if we haven't found a way to get you to a sprint | 21:19 |
| lac | and I am an idiot | 21:19 |
| DR0ID_ | so what is the current status and what is your next goal to achive? | 21:19 |
| lac | maciek fijialkowski is anything nut a lurker! writes tons of the hardest stuff! ALSO michael hudson | 21:19 |
| lac | so I am an idiot at people. sorry. | 21:19 |
| DR0ID_ | nvm | 21:20 |
| AntonK | :) | 21:20 |
| AntonK | lac: right now I'm thinking about implementing tail call stuff for llvm | 21:20 |
| lac | ok, so I had the idea that it would be nice to be paid for this. | 21:20 |
| lac | so we made this a 6th framework international EU ITS project. | 21:21 |
| lac | and we got paid. nice to have my tax money used for something useful for a change. | 21:21 |
| DR0ID_ | wow, so you get paid for researching pypy? | 21:21 |
| lac | we did. stopped in march. | 21:21 |
| DR0ID_ | ok | 21:21 |
| lac | was nice for 18 months, except for all the damn EU reports. | 21:22 |
| lac | and the paperwork of other sorts | 21:22 |
| lac | But so, this is where we stand. | 21:22 |
| DR0ID_ | but pypy will still be developed? | 21:22 |
| lac | oh yes. | 21:23 |
| DR0ID_ | ok | 21:23 |
| lac | but if you know somebody who wants to pay us, we like money. | 21:23 |
| DR0ID_ | lol, I'm a student myself, so no money ;-) | 21:23 |
| lac | and progress is slower now that people are not being paid to do this full time. | 21:24 |
| ded (n=ded@lor34-1-82-240-239-109.fbx.proxad.net) joined #pypy. | 21:24 | |
| lac | i.e. Samuele Pedroni works for the same company I do, Open End AB in Sweden. | 21:24 |
| DR0ID_ | so, could I take a script of mine and translate it into say C code? does that work already? | 21:24 |
| lac | yes | 21:25 |
| lac | pypy works. | 21:25 |
| lac | there are no restrictions on what you can translate. | 21:25 |
| lac | except that threadiung is pretty so-so | 21:25 |
| lac | and maybe 2 more things. | 21:25 |
| lac | but yes, it works. | 21:26 |
| DR0ID_ | even script using pygame? | 21:26 |
| DR0ID_ | scripts* | 21:26 |
| lac | yes | 21:26 |
| DR0ID_ | good work! | 21:26 |
| lac | we use pygame to develop pypy. | 21:26 |
| DR0ID_ | how? | 21:26 |
| lac | we make AST trees and display them using pygame | 21:26 |
| Action: Rhamphoryncus is fixing threading for cpython. It'll presumably come back to PyPy at some point | 21:26 | |
| DR0ID_ | AST? forgot what that is, sorry | 21:27 |
| Rhamphoryncus | abstract syntax tree | 21:27 |
| lac | Abstract syntax trees | 21:27 |
| DR0ID_ | ok | 21:27 |
| Action: lac thinks that doing co-operative schedulting with tasklets and greenlets is better than threads anyhow | 21:27 | |
| lac | .... but we ought to support threading better in any case. | 21:27 |
| Action: Rhamphoryncus thinks scaling up to multiple CPUs is mandatory | 21:28 | |
| Action: lac wants to see Rhamphoryncus get his mods that support that past python-dev first because she thinks that will be a very hard political fight | 21:29 | |
| Action: lac would rather not think of the politics of python now, though, unpleasant as that is. | 21:29 | |
| lac | So, where are we? | 21:30 |
| Rhamphoryncus | hehe, it could be, but posting a patch rather than arguing ill-researched half-baked ideas will help ;) | 21:30 |
| AntonK | lac: python politics is nothing compared to gcc's one :) | 21:30 |
| Rhamphoryncus | yeah, I'll shut up and let you continue :) | 21:30 |
| DR0ID_ | I hate to so say that I will have to leave in about 10 minutes so you better hurry up if you want to tell more or something important | 21:31 |
| lac | One. we have the very first just in time specialiser in the world | 21:31 |
| lac | this is pure joy in scientific worlds, solves a 35+ year old scs problem | 21:31 |
| Rhamphoryncus | scs? | 21:32 |
| DR0ID_ | scs problem? | 21:32 |
| lac | Two, we badly need a better gc. boehm and ref counting does not do it. | 21:32 |
| lac | er csc -- computer science. | 21:32 |
| DR0ID_ | gc? | 21:32 |
| lac | garbage collector | 21:32 |
| DR0ID_ | ok | 21:32 |
| lac | we thinking of porting Jype | 21:32 |
| lac | Three: we are now in a stage where people can implement better algorithms for types | 21:33 |
| lac | and | 21:33 |
| lac | plug them in | 21:33 |
| lac | sayt a b-tree version of python dicts. | 21:33 |
| DR0ID_ | jype? | 21:33 |
| lac | so pypy now needs people who are hot at making algorithms | 21:33 |
| lac | jype is IBM new virtual sytem for java | 21:34 |
| lac | we can translitterate the code | 21:34 |
| DR0ID_ | ok, never heard about it | 21:34 |
| DR0ID_ | making algorithms | 21:34 |
| DR0ID_ | what kind? any? | 21:34 |
| lac | there is a gc in there that has lots of cool academic papers about it, saying it is hot. | 21:34 |
| lac | never used it myself | 21:34 |
| lac | any that would be useful to speed up a python type for sure. | 21:35 |
| lac | others ... depends | 21:35 |
| DR0ID_ | how many types exists in python? | 21:36 |
| lac | we already are 6000 times faster than Cpython for integers | 21:36 |
| lac | but for strings we are slower, mostly. | 21:36 |
| DR0ID_ | O_o | 21:36 |
| lac | and we are not really that good at optimising code. | 21:36 |
| DR0ID_ | strings are more complicated datastructures | 21:36 |
| lac | we have the most straightforward implementation of so many things. | 21:37 |
| DR0ID_ | me neither ;-) | 21:37 |
| ded | hi | 21:37 |
| DR0ID_ | sorry to interrupt, but I have to leave now | 21:37 |
| lac | ok, take care and thank you. | 21:37 |
| DR0ID_ | I will read up when I get back home | 21:37 |
| DR0ID_ | cu | 21:37 |
| lac | But the man who made direty rects c9uld make pypy gfaster, I know | 21:37 |
| Action: DR0ID_ bbl | 21:38 | |
| lac | so we want to rec ruit you in some way if we can. | 21:38 |
| ded | is that possible to use compiz fusion effect with python? | 21:38 |
| lac | what is 'compiz fusion effect'? | 21:38 |
| ded | compiz fuision is the project who unit beryl and compiz | 21:38 |
| mmarshall | ded: I doubt it | 21:38 |
| lac | can you point me at a url, I can see what I think. | 21:39 |
| exarkun | ded: all you need to do is call some functions in a C library | 21:39 |
| mmarshall | ded: but you're probably in the wrong channel :) | 21:39 |
| ded | ok sorry | 21:39 |
| exarkun | ded: there's nothing particularly difficult or interesting about compiz, nor anything which particulary ties the answer to pypy (except that you probably aren't using pypy when you write python code...) | 21:40 |
| lac | if these are C funtion library, then, yes you probably can but pypy is not where you want to look. | 21:40 |
| lac | on the other hand, I might be the person you want to talk to anyhow in a different channel like pypy | 21:40 |
| lac | because I write C extensions all the time. | 21:41 |
| ded | lac witch one? | 21:41 |
| lac | So if you point me at a url I can say 'yes' 'no' and 'looks like a lot of work' at you if you like | 21:41 |
| lac | me? all sorts of things for biopython | 21:41 |
| ded | it is not the same thing so ... | 21:42 |
| lac | but a C extension is a C extension. what counts is how they are written not what for | 21:42 |
| ded | compiz fusion has'nt got official website but you got beryl and compiz website | 21:43 |
| ded | http://www.beryl-project.org/ | 21:43 |
| __lucio__ (n=__lucio_@190.50.219.209) left irc: | 21:45 | |
| lac | Ok. from this very short look -- all things using OpenGL can be wrapped nicely. | 21:45 |
| ded | right but they are already done effect that i would like to interact whith | 21:46 |
| lac | to the extent that beryl wants to do its own stuff with desktops not using OpenGL, you could have | 21:47 |
| lac | problems | 21:47 |
| lac | ok, let us move to #python to discuss this there. | 21:47 |
| lac | because this is the wrong place | 21:47 |
| ded | no i am not registed | 21:47 |
| ded | sorry | 21:47 |
| lac | #python is a group just like this, so its not to matter that you are not registered | 21:48 |
| ded | it refuse to log unregisted user | 21:48 |
| lac | oh | 21:49 |
| ded | from nickserv | 21:49 |
| lac | i did not know that this was possible for groups | 21:49 |
| lac | excuse me. | 21:49 |
| lac | can you go to pygame? | 21:49 |
| ded | yes i am here | 21:49 |
| mmarshall | Ok, so I'm sitting here looking at the pypy-1.0.0 source tree... which module should I read first? | 21:50 |
| mmarshall | (I skimmed a few in magic a while back, but that's it.) | 21:50 |
| exarkun | mmarshall: what do you want to accomplish? | 21:55 |
| ded (n=ded@lor34-1-82-240-239-109.fbx.proxad.net) left #pypy. | 22:00 | |
| mmarshall | exarkun, No clue. | 22:06 |
| exarkun | Ah | 22:06 |
| mmarshall | exarkun, I just want to get to know pypy. | 22:06 |
| exarkun | Well, you might want to check out trunk@HEAD and look at that | 22:06 |
| mmarshall | allright. I get internet over a GPRS network, so the checkout might finish overnight :P | 22:07 |
| exarkun | pypy/translator/goal/targetpypystandalone.py is kind of the top of the python interpreter. or maybe pypy/bin/py.py is. | 22:07 |
| mmarshall | So what is the state of threading in pypy right now? | 22:08 |
| exarkun | "sort of" I guess. I don't really know in any detail. | 22:08 |
| mmarshall | Ok, that looks like a good start. | 22:19 |
| lac | mmarshall sorry that I was not being attentive. was fixing ded's problem which started out as 'I need to write a | 22:33 |
| lac | C exgtension' and ended up as 'this is a cool object relational mapper called dbus' | 22:34 |
| lac | but it took time. | 22:34 |
| lac | now, your questions that 'read the code' dpoes not fix? | 22:34 |
| mmarshall | hehe, actually, he started out asking to make a compiz fusion effect... but whatever. | 22:34 |
| lac | aha. | 22:35 |
| lac | I got him onto the wrong foot, but he seems ok now. | 22:35 |
| lac | but back to you. | 22:35 |
| lac | what do you want to learn about pypy now? | 22:35 |
| lac | reading code in this case will not help nearly as much as reading the tests wíll | 22:36 |
| mmarshall | Ah, ok. | 22:36 |
| lac | for an overview. | 22:36 |
| mmarshall | Yeah, I was starting to notice that there is A LOT of code :) | 22:36 |
| lac | we have some code that is tricky for a necessary reason | 22:36 |
| lac | some because it happened that way | 22:36 |
| lac | and some because well, nobodyu knows that any more | 22:37 |
| lac | 'seemed like a good idea at the time' | 22:37 |
| lac | reading the tests is a better way to get an overview. | 22:37 |
| mmarshall | A while back I made a little library that I called 'Cellulose'. It handles 'data flow' (or it seems some people call it that.) I'm somewhat interested in implementing some of it's ideas deeper into the language. (Similar to some of the stuff in pypy's 'magic' package.) | 22:38 |
| mmarshall | (There's a half-hearted website for cellulose here: http://matthewmarshall.org/projects/cellulose/) | 22:39 |
| mmarshall | And I'm interested in the state of threading in pypy... | 22:41 |
| mmarshall | ... with the last version of cellulose I added some stuff for spreading out calculating values over multiple threads, all with shared state and automatic cache invalidation. | 22:42 |
| lac | I am reading this now | 22:56 |
| lac | on the surface, it looks like something that pypy could speed up a lot | 22:57 |
| lac | is it speed your problem, or concurrency, or I don't have a problem, its just my interest, or ... | 22:57 |
| lac | mmarshall: do you know about the 'thunk object space' in pypy? | 22:59 |
| dialtone (n=dialtone@213-156-52-97.fastres.net) left irc: Read error: 104 (Connection reset by peer) | 22:59 | |
| lac | http://www.nikat.org/codespeak.net/pypy/dist/pypy/doc/getting-started.html#lazily-computed-objects | 23:01 |
| mmarshall | speed isn't a problem. | 23:04 |
| mmarshall | I guess one thing that I'm interested in is being 'robust.' | 23:04 |
| mmarshall | I really liked the 'taintable' thing in magic. | 23:05 |
| mmarshall | I guess I'm really just interested in experimenting with putting this sort of thing deeper into the language to help prevent any common mistakes. | 23:05 |
| mmarshall | But maybe I'm not thinking strait. | 23:06 |
| mmarshall | It's actually been about two months since I have thought about it really; I might need to spend some time collecting my thoughts again :-/ | 23:06 |
| mmarshall | So, I guess to answer your question, "I don't have a problem, it's just my interest" | 23:08 |
| mmarshall | :) | 23:08 |
| niche (n=chatzill@ool-4572d84a.dyn.optonline.net) joined #pypy. | 23:09 | |
| Rhamphoryncus | mmarshall: I'm quite interested in anything threading related, but my knowledge of pypy itself is limited | 23:10 |
| Ekarderif (n=opera@adsl-76-203-7-43.dsl.emhril.sbcglobal.net) joined #pypy. | 23:11 | |
| mmarshall | Yeah, but I didn't remember what they were called :) | 23:11 |
| Rhamphoryncus | Cellulose looks interesting, but I suspect only useful for fairly specialized problems | 23:12 |
| Rhamphoryncus | hrm. I wonder how that compares to using memcached for website generation :D | 23:13 |
| mmarshall | Rhamphoryncus, At it's heart, it's really just caching with automatic invalidation... so it could be used for a lot of things. | 23:15 |
| mmarshall | That's something I've thought of. | 23:15 |
| mmarshall | The problem is on the database layer :-/ | 23:15 |
| Rhamphoryncus | Would I be correct in assuming the Cellulose implementation isn't distributed? | 23:16 |
| mmarshall | Rhamphoryncus, what I originally developed cellulose for was a GUI library. | 23:16 |
| lac | mmarx | 23:17 |
| mmarshall | The idea was that it could work similar to HTML/CSS... | 23:17 |
| Rhamphoryncus | *nod* I've done a GUI library too :) | 23:17 |
| mmarshall | ... instead of HTML you have your python objects using cellulose... | 23:17 |
| lac | mmarshall: you are outr kind of customer. sorry I was busy in the pypthon channel | 23:17 |
| mmarshall | ... and you have a simple way to create a layout that is automatically kept up to day with the data in your models. | 23:18 |
| Rhamphoryncus | yeah | 23:18 |
| lac | mmarshall: you are -- no pun intended- marshelling your objects (or pickelling them) and stuffing them into a database for use later | 23:18 |
| lac | or what? | 23:18 |
| Rhamphoryncus | I've believed that was the correct approach for years now. It's still not well mainstream though | 23:19 |
| mmarshall | No, it's not distributed yet :) | 23:19 |
| mmarshall | but it's something I've wanted to do. | 23:19 |
| mmarshall | lac, np | 23:19 |
| stakkars | someone mentioned me, but I don't find it | 23:20 |
| lac | He stakkars. was me | 23:21 |
| mmarshall | lac, No I haven't done any database stuff with cellulose yet. | 23:21 |
| lac | was in 'history of project; original memebers' | 23:21 |
| stakkars | My name is Eliza. Please ask me a question. | 23:21 |
| lac | mmarshall: your project looks like an interesting one, one that pypy might be able to do in a completely differenet way | 23:22 |
| mmarshall | Rhamphoryncus, what gui lib have you done? | 23:22 |
| lac | one that we could say '' oh cool, with taint and with I am not sure what yet' we can change the way we think about | 23:23 |
| lac | aps. | 23:23 |
| Rhamphoryncus | mmarshall: nothing published. It was an experimentation in threading, basically ended up being similar to active objects | 23:23 |
| DR0ID_ (n=DR0ID_@241.156.77.83.cust.bluewin.ch) left irc: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org" | 23:23 | |
| stakkars | lac: they want me to give a keynote in Dresden, too. Should I go for it? Fearing overloads. | 23:23 |
| lac | stakkars: being eliza was not listed in your credits. you will have to take credit for that yourself- | 23:23 |
| lac | stakkars what days? | 23:23 |
| stakkars | unfortunately on the 7th. I would give the keynote, and then go to England :-( hate to hurry | 23:24 |
| stakkars | bui I also hate to not take advantage. Oh. Should I? | 23:25 |
| stakkars | the eliza stuff is granted, btw. try it. | 23:25 |
| lac | stakkars: are you to give the same talk? if so do it. | 23:26 |
| lac | except that I want you on my pyweek team to make a game in one week., | 23:26 |
| lac | but curse personal pleasure and personal advantage | 23:27 |
| lac | profesionally its better if you go! | 23:27 |
| stakkars | I am going to give 2 talks at PyCon U>K, one for beginners and an advanced one. | 23:27 |
| lac | yes, but i want us to make a game in one week ending the 9th | 23:27 |
| lac | pyweek end is pyconul end | 23:27 |
| stakkars | no idea what they expect from me in Dresden. Maybe something completely differect, like Arlo. Dunno if I'm ready for this. | 23:28 |
| lac | we could sprint before on something not serious like pypy but fun like pyweek | 23:28 |
| lac | staqkkars: no aggreeing before you find out what they want. | 23:28 |
| stakkars | And, especially different: will be in German, I guess :-] | 23:28 |
| lac | not if its the same topic. | 23:28 |
| lac | I mean, will be hell if I had to give a talk in German | 23:29 |
| lac | but for you, english is so good, the pyconuk will not stress you | 23:29 |
| stakkars | I almost never gave a talk in German. Would be a bunch of wording jokes, I think | 23:30 |
| niche | Does anyone know of the JoelOnSoftware article that dealt with compilers? | 23:32 |
| stakkars | lac: no, talking will be fine. And I will do a nice beginner's talk with lots of examples. | 23:33 |
| ergo | niche: the one who lead to the discussion about PIC's and the self project? | 23:34 |
| niche | I'm not entirely sure, because I did a Google search and he had more than one article... but this specific article had 5 or so imaginary scenarios, and he went on to talk about how a compiler was the best solution. | 23:34 |
| stakkars | lac: but a keynote, while would love this more than anything else, what should I tell them? I would need to be up-to-date with everything, but I'm far away from this. Well, not soo far, maybe | 23:36 |
| Action: stakkars right now setting up lots of servers and frameworks, going to supports sites like mine and stackless and starship, all that long-neglected stuff, again. Maybe I could use this for a talk... | 23:38 | |
| stakkars | lac: ok I'll write to the dresden guys, asking what they would expect from me. | 23:40 |
| GILtone | pedronis - r45487 - kill flavor_malloc_*, zero_malloc_* now only malloc_* operations should be present in graphs until gc transform malloc and malloc_varsize now always carry a dictionary of flags as second operand, the | 23:42 |
| pedronis | good, now both gc transformation and backends need to care about less stuff | 23:46 |
| GILtone | pedronis - r45488 - update with next steps regarding gc/mem mgmt stuff | 23:55 |
| lac | stakkars: agree to do it. beause you want to. | 23:56 |
| stakkars | wot? | 23:57 |
| lac | stakkars I am in bad shape holding irc conversations on 3 windows at once and watching my program flunbk 30 tests | 23:57 |
| lac | I say, well, go give the talk in german. sounds like you want to | 23:57 |
| stakkars | lac: you want me to overly stress myself? Yes, I understand. | 23:58 |
| lac | stakkars not at all | 23:58 |
| stakkars | yes I want to. | 23:58 |
| lac | what I want is for us to make this in such a way it is not overly stressful. | 23:58 |
| lac | it is easy to say ' cannot, overstress' | 23:59 |
| lac | but you want this. | 23:59 |
| lac | so we make a plan that does not damage your health | 23:59 |
| stakkars | I want to harden my place in the noosphere, obviously. There seems to be a lack, since some while. | 23:59 |
| --- Sun Aug 5 2007 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!