| rekamso (~textual@67.51.82.66) left irc: Ping timeout: 248 seconds | 00:03 | |
| Da_Blitz (~Da_Blitz@203.56.250.63) left irc: Ping timeout: 252 seconds | 00:07 | |
| whitelynx|work (~whitelynx@63.241.75.144) left irc: Quit: Ex-Chat | 00:07 | |
| EnCuKou_ (~encukou@ip-94-113-220-25.net.upcbroadband.cz) joined #pypy. | 00:25 | |
| EnCuKou (~encukou@ip-94-113-220-25.net.upcbroadband.cz) left irc: Read error: Connection reset by peer | 00:25 | |
| DasIch (~DasIch@p4FFDF331.dip.t-dialin.net) left irc: Quit: DasIch | 00:31 | |
| tilgovi (~randall@couchdb/developer/tilgovi) joined #pypy. | 00:42 | |
| Rhyolite | how can I get an assert to drop into pdb? | 00:50 |
|---|---|---|
| fijal | --pdb | 01:00 |
| fijal | for py.test | 01:00 |
| fijal | Rhyolite: is this what you wanted? | 01:01 |
| Rhyolite | thanks. I'll try that | 01:02 |
| JaRoel (~jaroel|4d@office.fourdigits.nl) left irc: Remote host closed the connection | 01:10 | |
| fermianyon (~lane@wan-217-185.usouthal.edu) left irc: Ping timeout: 252 seconds | 01:10 | |
| JaRoel|4d (~jaroel|4d@office.fourdigits.nl) joined #pypy. | 01:10 | |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64-2/builds/31 | 01:22 |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/203 | 01:29 |
| Rhyolite | fijal: testing the PPC64 backend, I repeated hit an assert in _check_invariant of RegisterManager | 01:30 |
| Rhyolite | that longevity > position | 01:30 |
| Rhyolite | The op always appears to be setarrayitem_gc | 01:31 |
| squiddy (~squiddy@g224194089.adsl.alicedsl.de) left irc: Quit: Leaving | 01:36 | |
| JaRoel|4d (~jaroel|4d@office.fourdigits.nl) left irc: Remote host closed the connection | 01:38 | |
| etrepum (~bob@accessnat4.mochimedia.net) left irc: Ping timeout: 244 seconds | 01:42 | |
| ThomasWaldmann | moin | 01:45 |
| nettok (~quassel@190.148.241.226) joined #pypy. | 01:46 | |
| ThomasWaldmann | https://bitbucket.org/thomaswaldmann/python-search-benchmark/ code http://paste.pocoo.org/show/534547/ results for pypy / cpython | 01:46 |
| bbot2 | 4Failure: 15http://buildbot.pypy.org/builders/own-macosx-x86-32/builds/775 | 01:47 |
| Action: ThomasWaldmann had quite good results for whoosh compared to xappy/xapian and thought he could maybe completely catch up to x. by using pypy, but no, it is slower. | 01:49 | |
| nedbat (~nedbat@python/psf/nedbat) joined #pypy. | 01:55 | |
| Rhyolite | anyone awake? | 01:58 |
| dzen | yes | 01:58 |
| Rhyolite | good | 01:59 |
| dzen | note sure :p | 01:59 |
| Rhyolite | well, if you're awake, do something useful :-) | 01:59 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/1924 | 02:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/677 | 02:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/337 | 02:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/327 | 02:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/pypy-c-app-level-linux-x86-64/builds/675 | 02:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/1194 | 02:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/pypy-c-Ojit-no-jit-linux-x86-32/builds/858 | 02:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/pypy-c-app-level-linux-x86-32/builds/1511 | 02:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/788 | 02:00 |
| dzen | Rhyolite: I was trying to convince me to go to bed | 02:00 |
| dzen | but, How can I help you ? | 02:00 |
| Rhyolite | well, then you're not awake :-) | 02:00 |
| Rhyolite | I'm trying to debug an assertion in the pypy register allocator | 02:01 |
| dzen | wow | 02:02 |
| dzen | seems that I'm not that awake :p | 02:02 |
| dzen | no, sorry | 02:04 |
| Rhyolite | okay. | 02:04 |
| Rhyolite | have a good sleep | 02:04 |
| dzen | I do use pypy, but I'm not friendly with its code | 02:04 |
| dzen | thanks | 02:04 |
| Action: ThomasWaldmann does multiple runs of the benchmark in same process | 02:04 | |
| JaRoel|4d (~jaroel|4d@office.fourdigits.nl) joined #pypy. | 02:05 | |
| xcx (56183acb@gateway/web/freenode/ip.86.24.58.203) left irc: Quit: Page closed | 02:19 | |
| setmeaway2 (setmeaway3@118.45.149.247) left irc: Quit: Leaving | 02:34 | |
| setmeaway (~setmeaway@118.45.149.247) joined #pypy. | 02:34 | |
| aboudreault (~alanb@osgeo/member/aboudreault) joined #pypy. | 02:36 | |
| aboudreault__ (~alanb@modemcable072.19-23-96.mc.videotron.ca) joined #pypy. | 02:36 | |
| asmeurer_ (~asmeurer@c-174-56-21-245.hsd1.nm.comcast.net) left irc: Quit: asmeurer_ | 02:38 | |
| nedbat (~nedbat@python/psf/nedbat) left irc: Ping timeout: 245 seconds | 02:38 | |
| aboudreault__ (~alanb@modemcable072.19-23-96.mc.videotron.ca) left irc: Quit: Leaving | 02:42 | |
| ericflo (~ericflo@75.103.8.110) left irc: Quit: ericflo | 02:49 | |
| fermianyon (~lane@c-71-229-21-197.hsd1.al.comcast.net) joined #pypy. | 02:59 | |
| Moku (~John@osbk-4db17529.pool.mediaWays.net) joined #pypy. | 03:04 | |
| Shanita (~John@osbk-4db17d45.pool.mediaWays.net) left irc: Ping timeout: 240 seconds | 03:04 | |
| Nick change: Moku -> Guest17487 | 03:04 | |
| nedbat (~nedbat@python/psf/nedbat) joined #pypy. | 03:05 | |
| horieyui (~horieyui@113.106.212.39) joined #pypy. | 03:06 | |
| icrazyhack (~horieyui@113.106.212.37) left irc: Ping timeout: 252 seconds | 03:09 | |
| icrazyhack (~horieyui@124.165.209.20) joined #pypy. | 03:10 | |
| horieyui (~horieyui@113.106.212.39) left irc: Ping timeout: 268 seconds | 03:11 | |
| horieyui (~horieyui@114.119.1.27) joined #pypy. | 03:12 | |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-32/builds/1012 | 03:13 |
| EnCuKou_ (~encukou@ip-94-113-220-25.net.upcbroadband.cz) left irc: Quit: Mizím. | 03:13 | |
| EnCuKou_ (~encukou@ip-94-113-220-25.net.upcbroadband.cz) joined #pypy. | 03:14 | |
| icrazyhack (~horieyui@124.165.209.20) left irc: Ping timeout: 244 seconds | 03:14 | |
| icrazyhack (horieyui@222.47.159.116) joined #pypy. | 03:15 | |
| horieyui (~horieyui@114.119.1.27) left irc: Ping timeout: 248 seconds | 03:16 | |
| dracman (~draco@212.255.40.55) left irc: Ping timeout: 252 seconds | 03:18 | |
| dracman (~draco@212.255.25.35) joined #pypy. | 03:25 | |
| JaRoel|4d (~jaroel|4d@office.fourdigits.nl) left irc: Remote host closed the connection | 03:32 | |
| tellone (~tellone@h55eb1cd7.selukra.dyn.perspektivbredband.net) joined #pypy. | 03:33 | |
| bfirsh (u1308@gateway/web/irccloud.com/x-gywhtslgstswqkkt) left irc: Remote host closed the connection | 03:36 | |
| Alex_Gaynor (u1246@gateway/web/irccloud.com/x-ylepxbqdwnoboepd) left irc: Remote host closed the connection | 03:36 | |
| oal (u4126@gateway/web/irccloud.com/x-hpqxbbfhybbdtlbv) left irc: Remote host closed the connection | 03:36 | |
| bfirsh (u1308@gateway/web/irccloud.com/x-yunvqxoskymuuhkx) joined #pypy. | 03:41 | |
| oal (u4126@gateway/web/irccloud.com/x-blrjtkigsdtwvnmu) joined #pypy. | 03:42 | |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/own-linux-x86-32/builds/1924 | 04:15 |
| Alex_Gaynor (u1246@gateway/web/irccloud.com/x-omermbdidzetlndc) joined #pypy. | 04:16 | |
| #pypy: mode change '+o Alex_Gaynor' by ChanServ!ChanServ@services. | 04:16 | |
| verte-wleslie (~verte@python/site-packages/verte) joined #pypy. | 04:23 | |
| oal (u4126@gateway/web/irccloud.com/x-blrjtkigsdtwvnmu) left irc: Remote host closed the connection | 04:36 | |
| Alex_Gaynor (u1246@gateway/web/irccloud.com/x-omermbdidzetlndc) left irc: Remote host closed the connection | 04:36 | |
| bfirsh (u1308@gateway/web/irccloud.com/x-yunvqxoskymuuhkx) left irc: Remote host closed the connection | 04:36 | |
| oal (u4126@gateway/web/irccloud.com/x-bvuoshqsksukpjow) joined #pypy. | 04:43 | |
| nedbat (~nedbat@python/psf/nedbat) left irc: Ping timeout: 255 seconds | 04:44 | |
| nettok (~quassel@190.148.241.226) left irc: Remote host closed the connection | 04:47 | |
| setmeaway2 (setmeaway3@118.45.149.247) joined #pypy. | 04:54 | |
| setmeaway (~setmeaway@118.45.149.247) left irc: Read error: Connection reset by peer | 04:55 | |
| Alex_Gaynor (u1246@gateway/web/irccloud.com/x-cfnpvjrrtplwnnkc) joined #pypy. | 04:56 | |
| #pypy: mode change '+o Alex_Gaynor' by ChanServ!ChanServ@services. | 04:56 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) left irc: Ping timeout: 240 seconds | 05:03 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) joined #pypy. | 05:04 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) left irc: Max SendQ exceeded | 05:08 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) joined #pypy. | 05:09 | |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/pypy-c-app-level-linux-x86-32/builds/1511 | 05:19 |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/pypy-c-Ojit-no-jit-linux-x86-32/builds/858 | 05:20 |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/pypy-c-app-level-linux-x86-64/builds/675 | 05:25 |
| zain (~textual@c-67-160-201-63.hsd1.ca.comcast.net) joined #pypy. | 05:37 | |
| papercrane (~papercran@c-76-103-172-115.hsd1.ca.comcast.net) joined #pypy. | 05:37 | |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/1194 | 05:44 |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/677 | 05:53 |
| machrider (~machrider@c-67-180-177-185.hsd1.ca.comcast.net) joined #pypy. | 05:57 | |
| machrider | is there a limitation that xrange can't handle big integers? | 05:58 |
| verte-wleslie | yes | 05:58 |
| machrider | haha, ok | 05:59 |
| verte-wleslie | support for big integers was only added in python 3 | 05:59 |
| verte-wleslie | so this isn't a pypy thing | 05:59 |
| machrider | weird, this code works in cpython 2.7 | 05:59 |
| machrider | and if i s/xrange/range it works in pypy | 06:00 |
| verte-wleslie | in cpython 2.6.6, I get "OverflowError: long int too large to convert to int" | 06:01 |
| machrider | i might be confused, but | 06:02 |
| machrider | pypy: http://pastie.org/3182466 | 06:02 |
| machrider | cpython 2.7: http://pastie.org/3182467 | 06:02 |
| machrider | it might be that cpython is using 64-bit integers | 06:02 |
| machrider | not "big" integers | 06:03 |
| verte-wleslie | yes | 06:03 |
| verte-wleslie | check sys.maxint | 06:03 |
| machrider | ah, yes... 9223372036854775807 vs 2147483647 | 06:04 |
| machrider | thanks | 06:04 |
| verte-wleslie | no worries | 06:04 |
| machrider | all this time i thought python magically had no integer limits | 06:06 |
| machrider | but there are cases where it does, apparently. | 06:06 |
| verte-wleslie | yeah, that's been a bit of an irritation for some time | 06:06 |
| verte-wleslie | I think itertools.count doesn't have the limitation, though | 06:07 |
| verte-wleslie | it doesn't :) | 06:07 |
| machrider | haha, great | 06:07 |
| kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #pypy. | 06:09 | |
| verte-wleslie | and of course, in pypy, writing a better xrange is practically no cost once the jit kicks in | 06:09 |
| machrider | on the upside: this program runs 2x as fast in pypy | 06:09 |
| machrider | verte-wleslie: good point | 06:09 |
| aboudreault (~alanb@osgeo/member/aboudreault) left irc: Ping timeout: 240 seconds | 06:30 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) left irc: Ping timeout: 240 seconds | 06:40 | |
| verte-wleslie (~verte@python/site-packages/verte) left irc: Quit: ~~~ Crash in JIT! | 06:43 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) joined #pypy. | 06:44 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) left irc: Ping timeout: 240 seconds | 06:49 | |
| bbot2 | 4Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/337 | 06:50 |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) joined #pypy. | 06:51 | |
| bbot2 | 3Success: 15http://buildbot.pypy.org/builders/own-linux-x86-64/builds/788 | 06:53 |
| Taggnostr (~quassel@host229-64-dynamic.116-80-r.retail.telecomitalia.it) left irc: Remote host closed the connection | 06:54 | |
| xcombelle (~xcombelle@AToulouse-551-1-40-156.w90-11.abo.wanadoo.fr) joined #pypy. | 07:13 | |
| bbot2 | 4Failure: 15http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/327 | 07:42 |
| Da_Blitz (~Da_Blitz@203.56.250.63) joined #pypy. | 07:51 | |
| `fox` (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) joined #pypy. | 07:59 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) left irc: Ping timeout: 240 seconds | 07:59 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) joined #pypy. | 08:00 | |
| machrider (machrider@c-67-180-177-185.hsd1.ca.comcast.net) left #pypy. | 08:06 | |
| stakkars (~tismer@p5DDB7A14.dip.t-dialin.net) left irc: Read error: Connection reset by peer | 08:07 | |
| stakkars (~tismer@p5DDB7A14.dip.t-dialin.net) joined #pypy. | 08:08 | |
| fermianyon (~lane@c-71-229-21-197.hsd1.al.comcast.net) left irc: Ping timeout: 240 seconds | 08:21 | |
| xcombelle (~xcombelle@AToulouse-551-1-40-156.w90-11.abo.wanadoo.fr) left irc: Quit: I am a manual virus, please copy me to your quit message. | 08:38 | |
| amaury_ (~amaury_@46-127-23-192.dynamic.hispeed.ch) joined #pypy. | 08:44 | |
| Nisstyre (~yours@c-208-90-102-250.netflash.net) left irc: Ping timeout: 240 seconds | 08:45 | |
| papercrane (~papercran@c-76-103-172-115.hsd1.ca.comcast.net) left irc: Quit: Computer has gone to sleep. | 08:57 | |
| squiddy (~squiddy@f053086148.adsl.alicedsl.de) joined #pypy. | 09:15 | |
| oakdog8 (~oakdog8@telsasoft-host81.dsl.visi.com) left irc: | 09:19 | |
| ch_jyx (~ch_jyx@csl2wk29.cse.ust.hk) joined #pypy. | 09:25 | |
| christophler (~web49_an_@84.45.87.204) joined #pypy. | 09:25 | |
| `fox` (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) left irc: Ping timeout: 240 seconds | 09:28 | |
| antocuni (~antocuni@host157-123-dynamic.2-87-r.retail.telecomitalia.it) joined #pypy. | 09:45 | |
| ch_jyx (~ch_jyx@csl2wk29.cse.ust.hk) left irc: Remote host closed the connection | 09:55 | |
| stakkars (~tismer@p5DDB7A14.dip.t-dialin.net) left irc: Read error: Connection reset by peer | 10:14 | |
| stakkars (~tismer@p5DDB7A14.dip.t-dialin.net) joined #pypy. | 10:14 | |
| tumbleweed | why does pypy.tool.runsubprocess call subprocess from a fork? | 10:16 |
| tumbleweed | (background: as expected, I need to find a way to make pypy make noise while running "make", rather than waiting for it to complete before outputting anything) | 10:17 |
| lesshaste (~lesshaste@87-194-206-189.bethere.co.uk) left irc: Quit: Leaving | 10:17 | |
| Da_Blitz | why dont you make a shell wrapper and include it in the PATH you invoke pypy with | 10:28 |
| tumbleweed | no, the problem is that pypy captures all make's output | 10:33 |
| Action: tumbleweed is attempting just changing execute_make | 10:33 | |
| Da_Blitz | oh, so not play back an mp3 while compiling | 10:40 |
| Da_Blitz | sorry for my mistake then | 10:41 |
| fijal | tumbleweed: do you want to know why? | 10:42 |
| fijal | also, why make capturing is wrong? | 10:42 |
| amaury_ | tumbleweed: IIRC this was done to ensure that "make" can run at the end of translation | 10:49 |
| amaury_ | even when no more memory is available | 10:49 |
| etrepum (~bob@75-101-96-144.dsl.static.sonic.net) joined #pypy. | 10:52 | |
| fijal | amaury_: no, it's due to bug in POSIX/linux | 10:52 |
| fijal | it's not about memory being available | 10:53 |
| fijal | it's because fork() & exec() requires 2x virtual memory | 10:53 |
| fijal | and if you don't have it - crash | 10:53 |
| amaury_ | I thought that fork() uses copy-on-write memory? | 10:53 |
| fijal | it still allocates virtual memory | 10:54 |
| whyking (~quassel@p4FFB7932.dip.t-dialin.net) joined #pypy. | 10:55 | |
| whyking (~quassel@p4FFB7932.dip.t-dialin.net) left irc: Remote host closed the connection | 10:55 | |
| tilgovi (~randall@couchdb/developer/tilgovi) left irc: Remote host closed the connection | 10:58 | |
| whyking_ (~quassel@p4FFB70F7.dip.t-dialin.net) left irc: Ping timeout: 252 seconds | 10:59 | |
| arigato (~arigo@adsl-89-217-33-163.adslplus.ch) joined #pypy. | 11:32 | |
| kenaan | 12arigo default 11039bd6756d51 15/pypy/jit/metainterp/test/test_ajit.py: Write a test for max_unroll_loops, based on an idea by Hakan. | 11:49 |
| fijal | hi armin | 11:52 |
| arigato | hi | 11:52 |
| Action: fijal is happy with numpy | 11:53 | |
| arigato | :-) | 11:55 |
| arigato | let's rename "numpypy"->"numpy"->"happy" | 11:55 |
| fijal | happy is already a php interpreter written in rpython | 11:59 |
| fijal | did you send me a paper about it or was it cfbolz? | 11:59 |
| fijal | "paper" | 11:59 |
| fijal | abstract and a paywall | 11:59 |
| Action: arigato upgrades from firefox 6 to firefox 9 in about 1 minute and doesn't notice any big difference | 12:01 | |
| arigato | that was not me | 12:02 |
| fijal | ? | 12:02 |
| fijal | arigato: ? | 12:03 |
| arigato | answering your question above | 12:03 |
| fijal | ah ok :) | 12:03 |
| arigato | ah, I missed "fijal:", sorry :-) | 12:03 |
| fijal | http://dl.acm.org/citation.cfm?id=2047854 | 12:03 |
| k_bx (~k_bx@unstuck-evidence.volia.net) joined #pypy. | 12:13 | |
| fijal (~fijal@196-215-5-11.dynamic.isadsl.co.za) left irc: Ping timeout: 240 seconds | 12:14 | |
| fijal (~fijal@196-210-150-33.dynamic.isadsl.co.za) joined #pypy. | 12:14 | |
| mikefc | anyone got the actual paper? | 12:16 |
| fijal | mikefc: no | 12:16 |
| fijal | we can probably ask the author | 12:16 |
| DasIch (~DasIch@p4FFDF331.dip.t-dialin.net) joined #pypy. | 12:19 | |
| arigato | I did, from HHU | 12:21 |
| fijal | arigato: can you send it to me then? | 12:21 |
| arigato | yes | 12:21 |
| fijal | or tell me it's not very interesting :) | 12:21 |
| arigato | no, it is | 12:21 |
| arigato | as far as I can tell | 12:21 |
| `fox` (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) joined #pypy. | 12:22 | |
| fijal | arigato: do you know by chance rules of unrolling? | 12:22 |
| fijal | like | 12:23 |
| fijal | how do I figure out which operation prevents unrolling? | 12:23 |
| k_bx (~k_bx@unstuck-evidence.volia.net) left irc: Ping timeout: 255 seconds | 12:24 | |
| arigato | I don't know them | 12:24 |
| fijal | do you know how to fnid out? | 12:26 |
| fijal | or am I as good at reading the source as you're? | 12:26 |
| fijal | AAAAAaaaaaa | 12:28 |
| fijal | arigato: ok, I'm a moron | 12:28 |
| fijal | I was looking *at the preamble* | 12:28 |
| fijal | because the actual loop is so small I didn't notice it | 12:28 |
| fijal | "good" | 12:28 |
| h0l0gr4ph1c (~Edmund@ppp118-209-252-72.lns20.mel6.internode.on.net) joined #pypy. | 12:34 | |
| arigato | :-) | 12:37 |
| fijal | arigato: what we might want is a simplified version of array operations for small arrays | 12:38 |
| fijal | well | 12:38 |
| fijal | we can have arbitrary amounts of hacks :) | 12:38 |
| arigato | yes :-) what do you mean, though? | 12:39 |
| tumbleweed | fijal: the problem I have with capturing is that we time out builds on Debian, if they don't output something for X seconds | 12:41 |
| tumbleweed | fijal: I worked around half of that problem by forcing the mandelbrots to be displayed even when not on a TTY | 12:42 |
| tumbleweed | but make can take a while | 12:42 |
| fijal | arigato: we can have different strategies for small and large arrays | 12:43 |
| fijal | for example if array does not fit in the cache, it's crucial that we do fetch it only once | 12:44 |
| azanella (~azanella@189.6.80.131) joined #pypy. | 12:44 | |
| fijal | if the array is really small, we might want to reduce boilerplate, because temporaries are not expensive | 12:44 |
| fijal | tumbleweed: just display more mandelbrot each time you get a piece of make output and make sure it's not buffered? | 12:45 |
| fijal | arigato: would you mind if I improve check_simple_loop (a rhetorical question) | 12:45 |
| tumbleweed | yes, I just thought of that, too. That's upstreamable | 12:45 |
| arigato | tumbleweed: add "def f(): while 1: print "x"; sleep(60)" "start_new_thread(f, ())" | 12:46 |
| tumbleweed | arigato: I'd rather not capture the output, it doesn't seem very useful | 12:46 |
| tumbleweed | but the question I asked was, why the fork in runsubprocess? | 12:46 |
| arigato | fijal: please do | 12:47 |
| fijal | tumbleweed: I answered above, to not explode on lack of virtual memory on fork() and exec() | 12:47 |
| tumbleweed | oh, right | 12:47 |
| arigato | tumbleweed: it's documented in the first 3 lines of the source, too | 12:47 |
| tumbleweed | yeah, when I read that, I thought tthat was referring to the forking earlier rather than later, rather than the forrk implicit in Popen | 12:48 |
| nedbat (~nedbat@python/psf/nedbat) joined #pypy. | 12:55 | |
| fox_ (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) joined #pypy. | 13:02 | |
| `fox` (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) left irc: Read error: Connection reset by peer | 13:02 | |
| azanella (~azanella@189.6.80.131) left irc: Ping timeout: 252 seconds | 13:07 | |
| DasIch_ (~DasIch@p4FFDE521.dip.t-dialin.net) joined #pypy. | 13:08 | |
| DasIch (~DasIch@p4FFDF331.dip.t-dialin.net) left irc: Ping timeout: 244 seconds | 13:10 | |
| Nick change: DasIch_ -> DasIch | 13:10 | |
| fijal | arigato: for one I would like to introduce a file size limit at some point | 13:11 |
| fijal | we have multiple >1000LOC files | 13:11 |
| arigato | :-) | 13:12 |
| arigato | makes sense | 13:12 |
| fijal | like say there is no real reason why history.py contains all the stats things | 13:12 |
| JaRoel|4d (~jaroel|4d@sink.jaroel.nl) joined #pypy. | 13:20 | |
| fijal | arigato: blog post btw? | 13:21 |
| arigato | yes | 13:22 |
| arigato | about to go | 13:22 |
| arigato | done | 13:22 |
| fijal | cool :) | 13:23 |
| Action: arigato -> walk | 13:28 | |
| arigato (~arigo@adsl-89-217-33-163.adslplus.ch) left irc: Quit: See you | 13:28 | |
| cocoatomo (~cocoatomo@p2118-ipbf901souka.saitama.ocn.ne.jp) joined #pypy. | 13:29 | |
| h0l0gr4ph1c (~Edmund@ppp118-209-252-72.lns20.mel6.internode.on.net) left irc: Quit: Leaving | 13:29 | |
| H0l0gr4ph1c (~Edmund@ppp118-209-252-72.lns20.mel6.internode.on.net) joined #pypy. | 13:30 | |
| tumbleweed | I've got as far as working out that the mandelbrots are driven by the log, but I can't see how one triggers a mandelbrot dot. Hints? | 13:31 |
| fijal | something.dot() | 13:31 |
| tumbleweed | I don't see anyone doing that except ansi_print | 13:31 |
| timotimo | btw, is there an argument to translate.py that increases the mandelbrot speed? | 13:32 |
| tumbleweed | I assume I don't want to initalise a new mandlelbrot driver just for runsubprocess | 13:32 |
| tumbleweed | oh, log.dot | 13:32 |
| tumbleweed | duh | 13:32 |
| tumbleweed | mind if I commit this, then? http://paste.pocoo.org/show/534681/ | 13:39 |
| tumbleweed | what's the general review process? Commit small things, stage larger things in branches for review? | 13:41 |
| timotimo | almost everything is done in branches, but i would say such a small and obviously correct (hahahahahahaha) thing could be committed directly after review | 13:42 |
| timotimo | (i'm not actually a pypy dev) | 13:42 |
| fijal | tumbleweed: I do mind | 13:42 |
| fijal | this is nonsense | 13:42 |
| fijal | tumbleweed: there is no point in drawing dots just because time passes | 13:42 |
| fijal | you can still draw dots each time you receive stuff from make | 13:43 |
| fijal | tumbleweed: in general controversial changes (like introducing threads) should go into a branch :) | 13:43 |
| fijal | for example starting a thread would slow down pypy by a small bit (did you know that?) | 13:43 |
| tumbleweed | fijal: heh | 13:43 |
| fijal | also, it's ugly | 13:44 |
| fijal | like, does it behave correctly with C-c now? | 13:44 |
| fijal | or just breaks? | 13:44 |
| tumbleweed | fijal: that's harder to do, because the current protocol is repr() each way | 13:44 |
| fijal | or continues printing dots? | 13:44 |
| tumbleweed | sure, of course threads have overhead | 13:45 |
| fijal | no | 13:45 |
| fijal | threads have overhead on *other threads* | 13:46 |
| tumbleweed | due to GIL | 13:46 |
| fijal | due to less good assembler | 13:46 |
| fijal | anyway, I do mind :) | 13:46 |
| tumbleweed | which is why I asked | 13:46 |
| fijal | and the usual process is either a branch or a review on paste.pocoo.org if you can get someone to look right now | 13:46 |
| Action: tumbleweed goes for the non-trhead approach, with a fancier protocol | 13:47 | |
| nedbat (~nedbat@python/psf/nedbat) left irc: Ping timeout: 276 seconds | 13:48 | |
| Rhyolite | fijal: ping | 13:54 |
| fox_ (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) left irc: Read error: Connection reset by peer | 13:54 | |
| fijal | Rhyolite: pongish | 13:54 |
| Rhyolite | in trace logs, where does pypy print the "p" versus "i", etc.? | 13:55 |
| Rhyolite | what code is choosing that letter based on the type of variable? | 13:55 |
| fijal | ' | 13:55 |
| fijal | kind of box | 13:55 |
| timotimo | pointer vs integer? | 13:56 |
| fijal | ''p' is PtrBox, 'i' is IntBox, 'f' is FloatBox | 13:56 |
| Rhyolite | so it's in the class for PtrBox, etc how it is displayed? | 13:56 |
| Rhyolite | I am trying to understand the assertion failure in RegisterManager::__check_invariants() for the PPC backend | 13:57 |
| Rhyolite | and understand more about regalloc to track down where a register is being allocated | 13:58 |
| `fox` (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) joined #pypy. | 13:58 | |
| fijal | ok | 13:58 |
| fijal | so I can explain to you what the assertion means, but it has nothing to do with 'p' and 'i' | 13:58 |
| fijal | it's about computing longevity | 13:58 |
| Rhyolite | the assertion always is failing on op setarrayitem_gc | 13:58 |
| fijal | can you paste the entire traceback? | 13:58 |
| Rhyolite | I can, but there are only two instructions that matter | 13:59 |
| Rhyolite | It fails on | 13:59 |
| Rhyolite | setarrayitem_gc(Const(* GCREF hidden), Const(0), i16, | 13:59 |
| Rhyolite | descr=<pypy.jit.backend.llsupport.descr.ArrayDescr object at | 13:59 |
| Rhyolite | 0x117f86d0>) | 13:59 |
| Rhyolite | and the failure is about the longevity of a variable that does not exist in the function | 14:00 |
| Rhyolite | but would be the next PtrBox variable in the sequence | 14:00 |
| Rhyolite | In other words, the last instructions are | 14:00 |
| Rhyolite | p26 = guard_exception(...) | 14:00 |
| Rhyolite | finish() | 14:00 |
| Rhyolite | and the longevity failure is for p27 | 14:00 |
| Rhyolite | but at the position of setarrayitem_gc | 14:01 |
| Rhyolite | The longevity is (15,15) | 14:02 |
| Rhyolite | where 15 is setarryitem_gc | 14:02 |
| fijal | (15, 15) | 14:02 |
| fijal | that sounds bogus | 14:02 |
| Rhyolite | right | 14:02 |
| Rhyolite | the whole thing is bogus | 14:02 |
| fijal | can you look at the longevity computation and see if it's right? | 14:02 |
| Rhyolite | but force_allocate_reg looks like it will create a variable sort of like that | 14:03 |
| Rhyolite | if isinstance(v, TempBox): | 14:03 |
| Rhyolite | self.longevity[v] = (self.position, self.position) | 14:03 |
| kenaan | 12fijal numpypy-axisops 1154af8d89c99e 15/pypy/: kill some dead code | 14:04 |
| kenaan | 12fijal numpypy-axisops 1116b16c97b7c1 15/pypy/module/micronumpy/: a test and a fix | 14:04 |
| fijal | can I have a traceback? | 14:05 |
| kenaan | 12fijal numpypy-axisops 119478a09d1230 15/pypy/module/micronumpy/test/test_zjit.py: add a note | 14:05 |
| fijal | I'm still left in the blue as it to what actually explodes | 14:06 |
| fijal | just paste it no paste.pocoo.org | 14:07 |
| fijal | mikefc: ping? | 14:08 |
| Rhyolite | http://paste.pocoo.org/show/534689/ | 14:10 |
| kenaan | 12fijal default 115c19878c1ef9 15/pypy/: (mattip, fijal) merge numpypy-axisops, this adds axis=x argument to reduce functions. | 14:10 |
| kenaan | 12fijal numpypy-axisops 11b5b4522440a5 15/: close merged branch | 14:10 |
| amaury_ (~amaury_@46-127-23-192.dynamic.hispeed.ch) left irc: Ping timeout: 255 seconds | 14:10 | |
| fijal | Rhyolite: you forgot to call possibly_free_var(tmpbox)? | 14:11 |
| fijal | Rhyolite: this is not a traceback btw, at least not full | 14:11 |
| fijal | it's above the stdout/stderr crap :/ | 14:11 |
| fijal | don't ask me why | 14:11 |
| Rhyolite | I was looking for a missing possibly_free_var | 14:11 |
| fijal | mattip: merged | 14:12 |
| Rhyolite | and I'm trying to figure out what and where | 14:12 |
| fijal | ppc-backend branch? | 14:12 |
| fijal | you should merge default one day | 14:12 |
| Rhyolite | fijal: sven and david have been merging from trunk | 14:13 |
| Rhyolite | it's fairly recent | 14:13 |
| Rhyolite | http://paste.pocoo.org/show/534690/ | 14:13 |
| Rhyolite | ppc-jit-backend branch | 14:13 |
| fijal | what is _ensure_value_is_boxed doing? | 14:14 |
| fijal | make_sure_var_in_reg already does that | 14:14 |
| fijal | at least used to :/ | 14:15 |
| fijal | there used to be imm_fine argument | 14:15 |
| Rhyolite | hmm, yes, interesting | 14:16 |
| Rhyolite | prepare_setarryitem_gc seems to be the only one throwing aware those boxes | 14:16 |
| Rhyolite | setting them to _ | 14:16 |
| Rhyolite | for whatever reason the PPC backend is different from the ARM backend | 14:17 |
| Rhyolite | and __ensure_value_is_boxed returns both the unboxed and boxed values | 14:17 |
| fijal | it got killed at some time | 14:18 |
| fijal | anyway | 14:19 |
| fijal | it clearly misses freeing of those boxes | 14:19 |
| nettok (~quassel@190.148.241.226) joined #pypy. | 14:19 | |
| DasIch (~DasIch@p4FFDE521.dip.t-dialin.net) left irc: Quit: DasIch | 14:19 | |
| fijal | but that's ugly interface, I want mine imm_fine argument back :/ | 14:19 |
| fijal | it's a bad name as well | 14:19 |
| fijal | it actually makes sure value is in the register | 14:19 |
| fijal | and not that it is boxed | 14:19 |
| Rhyolite | but, yeah, that appears to be the problem | 14:20 |
| Rhyolite | if I explicitly free those boxes, then life is good | 14:20 |
| Rhyolite | thanks for helping track that down | 14:20 |
| fijal | Rhyolite: not quite | 14:20 |
| fijal | note that there is nothing stopping ofsloc from replacing baseloc | 14:20 |
| fijal | for example | 14:20 |
| fijal | because baseloc is not in forbidden vars to the next call | 14:20 |
| Rhyolite | I'm not saying that there aren't other problems | 14:21 |
| Rhyolite | and the problem you point out also is a bug in the ARM backend | 14:21 |
| fijal | a0, a1, a2 = list(op.getarglist()) | 14:22 |
| lucian (~lucian@cpc1-newc15-2-0-cust84.gate.cable.virginmedia.com) joined #pypy. | 14:22 | |
| fijal | this is probably not rpython | 14:22 |
| fijal | and list is completely redundant here | 14:22 |
| fijal | well ok | 14:22 |
| fijal | you asked me to look at the code and I'm looking :) | 14:22 |
| Rhyolite | :-) | 14:22 |
| fijal | Rhyolite: you need to control all the variables you want to not be moved around | 14:22 |
| fijal | in forbidden_vars | 14:22 |
| Rhyolite | yep | 14:22 |
| k_bx (~k_bx@unstuck-evidence.volia.net) joined #pypy. | 14:22 | |
| fijal | well | 14:23 |
| fijal | it's a mess | 14:23 |
| Rhyolite | I'm playing ignorant at the moment :-) | 14:23 |
| fijal | because you always pass args | 14:23 |
| fijal | ok | 14:23 |
| Rhyolite | I'll include this in the report to David and Sven | 14:23 |
| fijal | so | 14:23 |
| Rhyolite | I'm still learning this stuff -- I'm only debugging it, I didn't write it | 14:23 |
| fijal | probably forbidden_vars should explicitly check if you don't pass consts there | 14:23 |
| fijal | because registers are only allocated to boxes | 14:24 |
| fijal | Rhyolite: well, the regalloc interface is very ugly and hard to get right | 14:24 |
| fijal | but we never came up with a better one :/ | 14:24 |
| Rhyolite | fijal: David, Sven and I all are learning | 14:24 |
| Rhyolite | I'm sure that there are a lot of mistakes lurking | 14:25 |
| Rhyolite | :-/ | 14:25 |
| fijal | I wouldn't mind if someone writes a better regalloc in the process of learning | 14:25 |
| fijal | better = with a better interface | 14:25 |
| fijal | not necesarilly with a better performance | 14:25 |
| fijal | although that would be nice as well | 14:25 |
| kenaan | 12fijal extradoc 11e383a2a0d80b 15/planning/micronumpy.txt: done | 14:26 |
| lucian | interesting post on the blog | 14:28 |
| fijal | Rhyolite: anyway, surf break | 14:28 |
| Rhyolite | cool | 14:29 |
| Rhyolite | have fun! | 14:29 |
| Rhyolite | thanks again | 14:29 |
| whyking (~quassel@p4FFB6B65.dip.t-dialin.net) joined #pypy. | 14:29 | |
| fijal | Rhyolite: no problem, I was serious when I said I would welcome a better API :) | 14:30 |
| Rhyolite | I'll get right on that! | 14:30 |
| asmeurer_ (~asmeurer@c-174-56-21-245.hsd1.nm.comcast.net) joined #pypy. | 14:31 | |
| lucian (~lucian@cpc1-newc15-2-0-cust84.gate.cable.virginmedia.com) left irc: Quit: Leaving | 14:31 | |
| fijal | maybe a with statement? | 14:32 |
| fijal | something like with (a, b, c) as (reg, reg, ecx): | 14:34 |
| kenaan | 12edelsohn ppc-jit-backend 11f657ede0f621 15/pypy/jit/backend/ppc/ppcgen/regalloc.py: possibly free boxes returned by ensure_value_is_boxed. | 14:41 |
| arigato (~arigo@adsl-89-217-33-163.adslplus.ch) joined #pypy. | 14:45 | |
| k_bx (~k_bx@unstuck-evidence.volia.net) left irc: Ping timeout: 248 seconds | 14:47 | |
| arigato | "Evaluation of the PyPy Project; Past, Present and the Future" | 14:47 |
| arigato | another random paper about pypy | 14:47 |
| Da_Blitz | hi arigato | 14:48 |
| Da_Blitz | intresting blog post | 14:48 |
| arigato | hi | 14:48 |
| arigato | :-) | 14:48 |
| DasIch (~DasIch@p4FFDE521.dip.t-dialin.net) joined #pypy. | 14:49 | |
| Da_Blitz | in regards to the post when you said stackless i assume the underlying primitive is still _continuation? | 14:50 |
| Da_Blitz | ie there isnt going to be a fork of the stackless code that does what you propose, but that becuase it uses the continuation code it gains this automatically? | 14:50 |
| arigato | I haven't thought about it to this extent so far | 14:53 |
| arigato | in the blog post when I said "stackless" I meant any existing program using stackless, but the same is true for greenlets and _continuation | 14:53 |
| Da_Blitz | so this would be another new primitive and not an extension of continuations then? | 14:54 |
| arigato | pypy's stackless.py will likely gain it automatically from _continuations, but I'm not sure yet | 14:54 |
| arigato | the point is that in any case you don't need to change the source of any program using stackless or _continuations, but just the stackless or _continuation "event dispatcher" | 14:55 |
| arigato | it's possible too that _continuation is not exactly the right level, and stackless is better | 14:56 |
| Da_Blitz | but i assume the goal is to introduce somthing like erlangs processes only more low level | 14:58 |
| arigato | I don't know enough about Erlang to answer this, but the goal is really to not change the stackless (or other) API one bit | 15:02 |
| arigato | except the following change: | 15:02 |
| arigato | drop the requirement that tasklets run in some precise order | 15:03 |
| arigato | and instead say that if several tasklets are ready to run, | 15:03 |
| arigato | an apparently random order will be picked | 15:03 |
| tumbleweed | fijal: so, better approach? : http://paste.pocoo.org/show/534704/ (I wish subprocess had something inbetween .communicate() and dealing with fds directly) | 15:06 |
| Da_Blitz | thanks for the info | 15:06 |
| arigato | tumbleweed: can you explain what you are trying to achieve? | 15:08 |
| arigato | (again, sorry) | 15:08 |
| arigato | I don't get why printing dots in the subprocess is not enough, i.e. why you need to change runsubprocess.py at all | 15:10 |
| arigato | can't you just adjust Debian's timeout? | 15:10 |
| arigato | or is the problem occurring when we call "make" at the end of translation? | 15:11 |
| tumbleweed | arigato: I can adjust the timeout, but then we lose it's value | 15:11 |
| tumbleweed | I've already seen pypy's tests deadlock | 15:12 |
| tumbleweed | (err, at least, I *think* I can adjust the timeout) | 15:12 |
| tumbleweed | yes, the problem is occuring during make | 15:12 |
| tumbleweed | https://buildd.debian.org/status/package.php?p=pypy&suite=experimental | 15:12 |
| arigato | then it's completely unrelated to runsubprocess.py | 15:12 |
| tumbleweed | make is called with runsubprocess | 15:13 |
| arigato | ok, I see | 15:14 |
| tumbleweed | anyway, that patch had a bug, round 2: http://paste.pocoo.org/show/534711/ | 15:16 |
| arigato | I would prefer a smaller hack, like call "make | tee /dev/stderr" and capture only stderr | 15:21 |
| tumbleweed | that does make things simpler | 15:21 |
| tumbleweed | but also changes runsubprocess' API | 15:22 |
| fijal | arigato: can you give me the random paper? | 15:22 |
| arigato | fijal: it's the first result on googling its name, but I cannot copy the exact url to you :-( | 15:22 |
| fijal | hahaha | 15:22 |
| fijal | ok | 15:22 |
| arigato | google is too clever | 15:22 |
| H0l0gr4ph1c (~Edmund@ppp118-209-252-72.lns20.mel6.internode.on.net) left irc: Quit: Leaving | 15:23 | |
| arigato | tumbleweed: just add an optional keyword argument to "def run_subprocess()" | 15:23 |
| arigato | tumbleweed: ah, a different approach | 15:24 |
| arigato | you can run "translate.py --source" | 15:24 |
| tumbleweed | hah | 15:24 |
| arigato | and then you cd to where the source was created and do "make" | 15:24 |
| arigato | or "make -j" or whatever is the standard on debian | 15:24 |
| tumbleweed | yes, I'll take that, thanks | 15:24 |
| arigato | you can force the directory in which to put the source code, too | 15:25 |
| arigato | see the comments at the start of pypy/tool/udir.py | 15:25 |
| fijal | mikefc: ping | 15:31 |
| fijal | mikefc_: ping | 15:31 |
| fijal | Rhyolite: back, just in case | 15:34 |
| kenaan | 12arigo pypy.org[extradoc] 1107305742afe8 15/: Update the status of stackless. | 15:35 |
| Action: arigato tries to think about "concurrentgen", the concurrent-marksweep gc | 15:41 | |
| fijal | arigato: want me to think with you or not so much? | 15:41 |
| arigato | yes :-) | 15:41 |
| amaury_ (~amaury_@46-127-23-192.dynamic.hispeed.ch) joined #pypy. | 15:41 | |
| arigato | so far it works nicely, but it allocates every object with the system malloc(), with a header that contains a "next" pointer | 15:42 |
| arigato | this is likely what a huge performance impact | 15:42 |
| arigato | I would like a custom allocation method like minimarkpage.py | 15:43 |
| arigato | the problem is how to replace "next" | 15:43 |
| arigato | there are mainly two different linked lists | 15:43 |
| arigato | the list of new objects, and the list of old objects | 15:44 |
| arigato | in a minor collection, the collector thread needs to walk the new object's list | 15:44 |
| arigato | to "sweep" away (i.e. free) the unused new objects | 15:44 |
| fermianyon (~lane@c-71-229-21-197.hsd1.al.comcast.net) joined #pypy. | 15:45 | |
| arigato | if we replace this with a custom allocation method | 15:45 |
| fijal | arigato: I *think* we still need a nursery | 15:45 |
| arigato | then we'll have "pages" containing objects, both old and new | 15:45 |
| fijal | I know this is a bit orthogonal :) | 15:46 |
| arigato | well so far I'm happy that it's a non-moving collector | 15:46 |
| fijal | ok | 15:46 |
| fijal | well, I'm also happy, but it does seem nursery is crucial for performance | 15:46 |
| arigato | yes and no | 15:46 |
| Action: fijal is listening | 15:46 | |
| arigato | "maybe" | 15:46 |
| arigato | it depends if we can also make allocation take just a few asm instructions, which I think we can | 15:47 |
| arigato | just fetching the next free slot in a linked list should not be more than a few asm instructions | 15:47 |
| fijal | ah | 15:48 |
| arigato | the point of having a nursery is that it makes freeing incredibly fast | 15:48 |
| fijal | if you have a good concurrent GC, you generally avoid too large overhead memory-wise right? | 15:48 |
| fijal | because the amount of objects that are not alive and still in memory is small right? | 15:49 |
| arigato | but in this case, freeing would be done by the other thread, so it should also be incredibly fast from the point of view of the main thread | 15:49 |
| arigato | fijal: this is an issue orthogonal to concurrency | 15:49 |
| fijal | is it? | 15:50 |
| arigato | I think so | 15:50 |
| fijal | well, in a single threaded gc you have a tradeoff | 15:50 |
| fijal | because you have to pause each time you want to collect | 15:50 |
| fijal | so if you have a threshold at say 1.3, you'll have at most 30% of unusued memory | 15:50 |
| fijal | but 1.5 would be faster (maybe) | 15:50 |
| fijal | while in concurrent one you keep it close to 1 | 15:51 |
| fijal | no? | 15:51 |
| arigato | true, but there is still a tradeoff: you can't start a collection all the time, otherwise you spend all the time in tracing stack roots or some other non-concurrent setup phase | 15:51 |
| fijal | right | 15:51 |
| arigato | anyway the model I implemented so far is documented in concurrentgen.txt | 15:51 |
| fijal | I have another (orthogonal) question which helps me understand the problem :) | 15:52 |
| arigato | now I'm trying to think how we can improve on the allocation | 15:52 |
| arigato | sure :-) | 15:52 |
| fijal | what's wrong with having minimark with a concurrent thread that collects nursery all the time | 15:52 |
| fijal | ? | 15:52 |
| arigato | you can't start a collection all the time, otherwise you spend all the time in tracing stack roots or some other non-concurrent setup phase | 15:53 |
| fijal | right, so not all the time | 15:53 |
| fijal | but say when it's half-full or so | 15:53 |
| arigato | yes, maybe | 15:53 |
| arigato | but note that there is a hard point | 15:53 |
| fijal | the point being that by far the most time it's spent in the gc is trace_and_drag_out_of_nursery | 15:53 |
| arigato | in a moving collector, it's much harder to write a concurrent version | 15:54 |
| fijal | and this is our problem right now - creating large collections takes forever | 15:54 |
| fijal | ah ok :) | 15:54 |
| fijal | because freeing mean you actually have to make sure someone does not just overwrite it? | 15:54 |
| fijal | or read it or something | 15:54 |
| arigato | no | 15:54 |
| arigato | because trace_and_drag_out_of_nursery makes a copy of the object | 15:55 |
| arigato | so, when do you stop using the original and start using the copy from the main thread? | 15:55 |
| fijal | right | 15:55 |
| fijal | well, there is a very boring approach that probably already gives some speedups | 15:55 |
| arigato | (it's a hard problem, but it has been solved too) | 15:55 |
| fijal | have a stop-the-world that spawns multiple threads | 15:55 |
| fijal | gains unclear | 15:56 |
| arigato | I'm not entirely sure it helps a lot | 15:56 |
| fijal | it does not address the basic problem - gc pauses | 15:56 |
| fijal | they're still pretty much unbound | 15:56 |
| arigato | I don't care that much about gc pauses | 15:56 |
| fijal | ok? | 15:57 |
| arigato | that's not the basic motivation for concurrent-marksweep | 15:57 |
| arigato | the motivation is to improve pypy speed by 10% if you run it on an idle multi-CPU machine | 15:58 |
| arigato | (boringly) | 15:58 |
| fijal | :) | 15:59 |
| fijal | I would not say "you would be better off if you work on X..." | 16:00 |
| fijal | because I don't know X :) | 16:00 |
| fijal | well, I do know X for a few examples, but that's about it | 16:00 |
| fijal | I know how to speed up translate.py by unknown % | 16:01 |
| fijal | two things :) | 16:01 |
| dmalcolm (~david@c-24-61-12-82.hsd1.ma.comcast.net) left irc: Quit: Leaving | 16:01 | |
| fijal | arigato: anyway, I think it's worth checking what sort of speedups you get if you split trace_and_drag_out_of_nursery for X threads | 16:03 |
| fijal | I agree it's not as cool as doing the full concurrent GC though :) | 16:03 |
| arigato | :-) | 16:04 |
| arigato | (also, the fact that it's non-moving may allow other performance tweaks here and there) | 16:04 |
| fijal | yes, of course | 16:04 |
| mattip (~chatzilla@bzq-79-180-120-174.red.bezeqint.net) joined #pypy. | 16:06 | |
| Action: mattip took a break to get my meds in order, feeling much more placid now. | 16:07 | |
| fijal | mattip: hey | 16:07 |
| mattip | fijal: yeah! | 16:07 |
| Rhyolite | fijal: that was fast. your new home is closer to the beach? | 16:07 |
| fijal | Rhyolite: no, just waves were crap | 16:08 |
| fijal | mattip: thanks :) | 16:08 |
| fijal | mattip: you can see what important test we missed btw | 16:08 |
| mattip | multiply. | 16:08 |
| fijal | yeah | 16:08 |
| fijal | something that has identity != 0 | 16:08 |
| mattip | strange, I would have thought the mean() test also would have failed | 16:09 |
| fijal | mean has no identity right? | 16:10 |
| Rhyolite | fijal: BTW, this is the next error: http://paste.pocoo.org/show/534732/ | 16:10 |
| fijal | Rhyolite: well | 16:10 |
| fijal | I told you where the regalloc is broken :) | 16:11 |
| mattip | mean uses sum, view, and promote | 16:11 |
| fijal | go and fix all the things like this | 16:11 |
| fijal | mattip: non of it uses identity != 0 | 16:11 |
| mattip | sorry, I got confused: 0 is not None. | 16:11 |
| DasIch (~DasIch@p4FFDE521.dip.t-dialin.net) left irc: Quit: DasIch | 16:12 | |
| mattip | anyhow, milestone. | 16:12 |
| mattip | Is there still a problem with reshape () ? | 16:13 |
| fijal | jest, something else than 0 or None :) | 16:14 |
| fijal | mattip: yes, if you unskip the end of the test you'll see the problem | 16:14 |
| fijal | mattip: feel like tackling this? | 16:14 |
| mattip | OK. | 16:14 |
| fijal | mattip: thanks for your work btw | 16:18 |
| kenaan | 12bivab arm-backend-2 11bb83f459ff90 15/pypy/jit/backend/arm/assembler.py: Implement case of moving a const float to the stack | 16:19 |
| kenaan | 12bivab arm-backend-2 1144a83931f5cb 15/pypy/jit/backend/arm/locations.py: implement as_key method for const float locations required for using const floats in jumps | 16:19 |
| kenaan | 12bivab arm-backend-2 118ff3eb80d78e 15/pypy/jit/backend/arm/regalloc.py: remove a call that was done twice | 16:19 |
| kenaan | 12bivab arm-backend-2 11483ce484be66 15/pypy/jit/backend/arm/: as pointed out by David Edelsohn and Maciej, get rid of redundant calls to list when accessing the list of in... | 16:19 |
| pedronis (~pedronis@73-53.195-178.cust.bluewin.ch) left irc: Ping timeout: 255 seconds | 16:20 | |
| mattip | np. nuf said. | 16:20 |
| nedbat (~nedbat@python/psf/nedbat) joined #pypy. | 16:22 | |
| pedronis (~pedronis@73-53.195-178.cust.bluewin.ch) joined #pypy. | 16:24 | |
| antocuni (~antocuni@host157-123-dynamic.2-87-r.retail.telecomitalia.it) left irc: Ping timeout: 252 seconds | 16:32 | |
| Rhyolite (~dje@pool-108-6-25-71.nycmny.fios.verizon.net) left irc: Quit: Leaving | 16:33 | |
| Rhyolite (~dje@pool-108-6-25-71.nycmny.fios.verizon.net) joined #pypy. | 16:34 | |
| arigato | fijal: the problem I was trying to solve above is: you have a mixture of old and young objects in the same page, | 16:39 |
| arigato | and every object has a flag that tells you its age | 16:39 |
| arigato | but you want to avoid reading all object's flags just to know | 16:39 |
| arigato | I think there are more or less clever solutions to this problem | 16:40 |
| arigato | on the "more" side, you might add a 32-bit bloom filter for every page | 16:40 |
| `fox` (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) left irc: Read error: Connection reset by peer | 16:45 | |
| tellone (~tellone@h55eb1cd7.selukra.dyn.perspektivbredband.net) left irc: Read error: Operation timed out | 16:45 | |
| `fox` (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) joined #pypy. | 16:49 | |
| bfirsh (u1308@gateway/web/irccloud.com/x-bimfhxsmopzfjqbz) joined #pypy. | 16:52 | |
| cocoatomo (cocoatomo@p2118-ipbf901souka.saitama.ocn.ne.jp) left #pypy ("Leaving..."). | 16:52 | |
| aboudreault (~alanb@osgeo/member/aboudreault) joined #pypy. | 16:59 | |
| Rhyolite | arigato: ping | 17:04 |
| arigato | pong | 17:05 |
| Rhyolite | Interesting blog post update about TM | 17:05 |
| arigato | :-) | 17:05 |
| exarkun | kjjj~. | 17:05 |
| Rhyolite | relating TM to some of the benefits of functional languages | 17:05 |
| arigato | yes, that's one point of view indeed | 17:06 |
| Rhyolite | maybe TM in a non-functional language is a good trade-off | 17:06 |
| arigato | I think it is, probably | 17:06 |
| Rhyolite | are you aware of the problem that functional languages expose? | 17:06 |
| arigato | no? | 17:07 |
| Rhyolite | the problem with functional languages is that they convert the problem to a scheduling problem | 17:07 |
| arigato | i.e. have random dispatch order? | 17:07 |
| Rhyolite | I'm not sure if that encompasses the problem | 17:08 |
| Rhyolite | with functional languages, there eventually is some dependency order | 17:09 |
| Rhyolite | and one has converted the explicit concurrency | 17:09 |
| Rhyolite | to an unlimited number of threads | 17:09 |
| Rhyolite | that must be scheduled in an ideal order | 17:09 |
| Rhyolite | to truly achieve the scalability | 17:09 |
| arigato | do you have some links to more information? | 17:11 |
| Rhyolite | I'm not sure where this was written down | 17:12 |
| Rhyolite | I heard it directly from Arvind :-) | 17:12 |
| arigato | I've a hard time to understand it | 17:12 |
| Rhyolite | maybe we should schedule a discussion about the TM stuff with IBM and I can have you talk with the functional language people as well | 17:16 |
| Rhyolite | but basically, the lack of side effects makes functional languages easier to parallelize | 17:17 |
| Rhyolite | however, unless the algorithm is trivially parallelizable | 17:17 |
| Rhyolite | there ultimately is a dependency order for the threads / actors / whatever | 17:17 |
| Rhyolite | and creating the optimal schedule for those actors becomes the new problem | 17:18 |
| Rhyolite | as the number of actors scales for high concurrency | 17:18 |
| arigato | I'm not sure what you mean by "schedule" there | 17:19 |
| Rhyolite | threads / actors / whatever must be queued on the limited number of computational elements of the system | 17:20 |
| arigato | in the model I have in mind, when a transaction is scheduled to run, it can run at any time: it won't get blocked by not having some data computed only later by someone else | 17:21 |
| Rhyolite | what happens if the data is not ready? | 17:21 |
| arigato | so I don't quite see how scheduling can be more or less optimal | 17:21 |
| Rhyolite | you say it won't get blocked | 17:21 |
| Rhyolite | the transaction fails and runs again until the data is ready? | 17:22 |
| arigato | no | 17:22 |
| arigato | the fact that the transaction is present on the queue means that it can run successfully | 17:22 |
| Rhyolite | right | 17:22 |
| Rhyolite | but what if there are more transactions to run than processors? | 17:22 |
| arigato | then you pick randomly N transactions, or pick the N oldest, or anything | 17:23 |
| arigato | can this create a scheduling problem? I don't see how | 17:23 |
| Rhyolite | okay, but what if some of the transactions conflict? | 17:23 |
| Rhyolite | yes, TM will catch it | 17:24 |
| Rhyolite | but one could have chosen a more optimal list of transactions to run first | 17:24 |
| Rhyolite | that would be more efficient | 17:24 |
| arigato | true | 17:24 |
| Rhyolite | and produce higher performance | 17:24 |
| Rhyolite | and if one picks the worst choice | 17:24 |
| Rhyolite | for the most conflicts | 17:24 |
| Rhyolite | then one can have worse performance than explicit locks | 17:24 |
| Rhyolite | that is what I mean by scheduling problem | 17:24 |
| arigato | from that point of view, we have no control at all | 17:25 |
| Rhyolite | it shifts the locking problem to a scheduling problem | 17:25 |
| Rhyolite | why don't you have control? | 17:25 |
| Rhyolite | or why shouldn't you have control? | 17:25 |
| arigato | I mean, no automatic control | 17:25 |
| arigato | indeed you can think of ways to add explicit control | 17:25 |
| Rhyolite | and there you have your problem | 17:26 |
| arigato | yes, I see | 17:26 |
| Rhyolite | as the number of transactions increase | 17:26 |
| Rhyolite | the scheduling problem becomes harder and harder | 17:26 |
| Rhyolite | and random or LRU or whatever may become worse and worse | 17:26 |
| arigato | I still think of it as a special case, but maybe I'm wrong | 17:26 |
| arigato | e.g. in the translation toolchain of PyPy I kind of think that automatic orders would work fine | 17:27 |
| Rhyolite | the question is whether functional programming makes the high concurrency case easier | 17:27 |
| Rhyolite | for low concurrency with infrequent conflict, why both with function programming or TM? | 17:27 |
| Rhyolite | TM will introduce more overhead | 17:27 |
| arigato | no, it's not exactly that: the question I'm trying to answer is whether it makes it easier to avoid bugs | 17:27 |
| nedbat (~nedbat@python/psf/nedbat) left irc: Ping timeout: 276 seconds | 17:28 | |
| Rhyolite | okay | 17:28 |
| arigato | solving the scheduling problem efficiently in a particular case might be hard | 17:28 |
| arigato | but you are always working with a bug-free model | 17:28 |
| Rhyolite | but avoiding bugs is related to easier to program | 17:28 |
| Rhyolite | think about the limiting cases | 17:29 |
| arigato | it's related, but not the same thing | 17:29 |
| Rhyolite | I have one thread | 17:29 |
| Rhyolite | I can write in TM | 17:29 |
| Rhyolite | but there never will be any conflict | 17:29 |
| `fox` (~fox@host130-111-dynamic.20-79-r.retail.telecomitalia.it) left irc: Ping timeout: 252 seconds | 17:29 | |
| Rhyolite | my single-threaded program is bug free | 17:29 |
| Rhyolite | with or without TM | 17:29 |
| Rhyolite | (for that class of bugs) | 17:30 |
| Rhyolite | then 2 threads | 17:30 |
| mattip (~chatzilla@bzq-79-180-120-174.red.bezeqint.net) left irc: Ping timeout: 268 seconds | 17:30 | |
| Rhyolite | is writing in TM really easier to create bug-free, concurrent application in that case? | 17:30 |
| arigato | then the same program is just as bug-free | 17:30 |
| arigato | but not necessarily conflict-minimal | 17:31 |
| Rhyolite | TM might be easier for the middle range | 17:31 |
| Rhyolite | but for high concurrency | 17:31 |
| Rhyolite | one has to include bugs in the TM implementation as well | 17:31 |
| Rhyolite | and the scheduling implementation | 17:31 |
| Rhyolite | etc. | 17:31 |
| arigato | these don't count | 17:31 |
| arigato | I know that such bugs exist of course | 17:31 |
| arigato | but these don't count here | 17:31 |
| Rhyolite | okay, you're defining away the problem | 17:31 |
| arigato | a TM implementation is done once, and may be hard, whereas the vast majority of programs written are just *using* the TM implementation | 17:32 |
| mattip (~chatzilla@bzq-79-181-110-252.red.bezeqint.net) joined #pypy. | 17:32 | |
| Rhyolite | I think this is where we disagree | 17:32 |
| arigato | yes, in some way I'm indeed defining away the problem | 17:33 |
| Rhyolite | that a TM implementation is done once | 17:33 |
| Rhyolite | a good-enough TM implementation for the mid-range is not the same as a TM implementation for very high concurrency | 17:33 |
| arigato | replace "once" with "10 times" if you prefer | 17:33 |
| arigato | it doesn't change the argument above | 17:34 |
| Rhyolite | I think you are assuming that when the system is stressed, no new problems will be uncovered | 17:34 |
| arigato | no, of course such problems will be discovered | 17:34 |
| arigato | and fixed, and maybe new ones will show up, etc. | 17:34 |
| arigato | but that's the same with, say, any GC | 17:34 |
| Rhyolite | and that there exists a solution for some of the problems | 17:35 |
| Rhyolite | I'm not trying to be argumentative | 17:35 |
| arigato | ah, indeed, we can't be 100% sure of that in advance | 17:35 |
| Rhyolite | I agree with your conclusion for your set of premises | 17:35 |
| Rhyolite | But I think your premises are overly limited | 17:35 |
| Rhyolite | I'll see if I can find a reference to this problem with functional languages | 17:36 |
| arigato | I'm basing all my argument over the work required for the end programmer, completely ignoring the work required for "us" | 17:39 |
| Rhyolite | Yes | 17:40 |
| Rhyolite | but if one encounters another wall due to scheduling | 17:40 |
| Rhyolite | then the end programmer may have to get involved | 17:40 |
| Rhyolite | to provide hints for scheduling | 17:40 |
| Rhyolite | potentially introducing errors | 17:41 |
| Rhyolite | it can be the same problem | 17:41 |
| Rhyolite | in other words, an end programmer can introduce many explicit synchonization barriers | 17:41 |
| Rhyolite | too many | 17:41 |
| Rhyolite | and the program will be correct, but very slow | 17:41 |
| Rhyolite | the errors in concurrency are due to incorrect use and application of the synchronization barriers | 17:42 |
| Rhyolite | similarly, the programmer can do nothing | 17:42 |
| Rhyolite | and encounter horrible scheduling of the transaction | 17:42 |
| Rhyolite | the program will be correct, but very slow | 17:43 |
| Rhyolite | then the end programmer can try to improve the scheduling | 17:43 |
| Rhyolite | and potentially introduce bugs | 17:43 |
| arigato | that's what I don't get | 17:43 |
| arigato | these barriers should not let the programmer misuse them to the point of introducing bugs | 17:43 |
| Rhyolite | okay, but then the programmer may not be able to achieve optimal performance equivalent to explicit barriers | 17:44 |
| arigato | yes, I agree | 17:44 |
| nedbat (~nedbat@python/psf/nedbat) joined #pypy. | 17:44 | |
| arigato | in the same way, the programmer might get more performance from using explicit memory allocation, but can't in Python | 17:44 |
| arigato | maybe the comparison doesn't scale | 17:45 |
| arigato | and what the programmer will be missing would give him very important gains | 17:45 |
| arigato | but I'm unsure | 17:45 |
| arigato | as long as the programmer can freely influence which N transactions to run next, he can theoretically pick the optimal order | 17:46 |
| arigato | without being able to add bugs | 17:46 |
| Action: arigato -> dinner | 17:47 | |
| Rhyolite | okay | 17:47 |
| Rhyolite | bon apetite | 17:47 |
| mattip (~chatzilla@bzq-79-181-110-252.red.bezeqint.net) left irc: Ping timeout: 276 seconds | 17:47 | |
| mattip (~chatzilla@bzq-79-183-112-243.red.bezeqint.net) joined #pypy. | 18:01 | |
| antocuni (~antocuni@host157-123-dynamic.2-87-r.retail.telecomitalia.it) joined #pypy. | 18:02 | |
| Dulak (~michael@unaffiliated/dulak) left irc: Quit: Leaving | 18:04 | |
| Dulak (~michael@unaffiliated/dulak) joined #pypy. | 18:04 | |
| Action: fijal back | 18:11 | |
| tumbleweed | looks like we have some endian issues on s390 https://buildd.debian.org/status/fetch.php?pkg=pypy&arch=s390&ver=1.7%2Bdfsg-2&stamp=1326509576 | 18:18 |
| fijal | tumbleweed: pypy won't work on s390 | 18:22 |
| fijal | it's unsupported | 18:22 |
| tumbleweed | there's a difference between unsupported and won't work | 18:22 |
| tumbleweed | looks like it's mostly working | 18:22 |
| tumbleweed | I'll do what I can for most of the ports. S390 should be particularly easy, because it's crazy fast | 18:23 |
| fijal | well, what I'm saying is that unsupported means that if you fix it today, we won't promise not to break it some other day | 18:24 |
| fijal | given how fast pypy is developed | 18:24 |
| tumbleweed | sure, I suspect very very few upstreams test on s390 | 18:25 |
| tumbleweed | but we still have a pretty good port | 18:25 |
| arigato | as long as pypy-without-jit is seriously slower than cpython, it's a bit pointless | 18:31 |
| arigato | imho | 18:32 |
| fijal | arigato: would a bloom filter make sense for dicts? | 18:32 |
| tumbleweed | yeah, but the port maintainers see it differently. Chances are I'll starte getting patches from them | 18:32 |
| fijal | because right now a large dict updating is particularly bad in pypy | 18:32 |
| arigato | fijal: which operation exactly? | 18:32 |
| tumbleweed | we have jit-less java on a bunch of archs, too... | 18:33 |
| fijal | arigato: setitem on large dict | 18:33 |
| fijal | if you do it in a loop, it invalidates a lot of pages | 18:33 |
| fijal | so the entire card marking is not quite working | 18:33 |
| arigato | ah, I see | 18:34 |
| Alex_Gaynor | fijal: how would a bloom filter help? | 18:34 |
| arigato | a bloom filter that means "this entry was updated, scan it" | 18:34 |
| arigato | I don't know if it's really better than lowering the card page size | 18:35 |
| Alex_Gaynor | can we lower it just for dicts easily? | 18:35 |
| timotimo | fijal: could http://buildbot.pypy.org/summary/longrepr?testname=AppTestUnicodeFormat.%28%29.test_oldstyle_custom_format&builder=own-linux-x86-32&build=1920&mod=objspace.std.test.test_newformat happen because pypy.rlib.rstring.StringBuilder doesn't have its own implementation of unicode_w? | 18:35 |
| Action: arigato looks | 18:36 | |
| fijal | arigato: I'm telling you for like 50th time and I haven't done much, but I would experiment with card marking for everything one day | 18:36 |
| fijal | it's "hard" though | 18:36 |
| arigato | :-) | 18:37 |
| fijal | this is what JVM does | 18:37 |
| fijal | on the other hand JVM was proven to really suck on things that we suck as well | 18:37 |
| fijal | timotimo: you're messing up layers | 18:37 |
| nedbat (~nedbat@python/psf/nedbat) left irc: Ping timeout: 248 seconds | 18:38 | |
| timotimo | fijal: https://chzscience.files.wordpress.com/2011/11/funny-science-news-experiments-memes-dog-science-fuzzy-logic.jpg | 18:39 |
| arigato (~arigo@adsl-89-217-33-163.adslplus.ch) left irc: Read error: Connection reset by peer | 18:40 | |
| fijal | :) | 18:40 |
| fijal | timotimo: ok ok | 18:40 |
| fijal | timotimo: this means that some casting went wrong | 18:40 |
| fijal | but casting happens between W_StringObject, W_UnicodeObject and whatever W_StringBuffer or however it is named | 18:40 |
| timotimo | fijal: somehow i get the impression, that i'm still responsible for fixing this? :) | 18:47 |
| fijal | hahaha :) | 18:51 |
| fijal | I can probably help though | 18:51 |
| nanonyme (nanonyme@unaffiliated/nanonyme) joined #pypy. | 18:53 | |
| Rhyolite | fijal: Is there wifi or good 3G coverage at the beaches? | 18:53 |
| fijal | 3G yes | 18:53 |
| fijal | wifi not so much | 18:53 |
| fijal | internet is expensive here :/ | 18:54 |
| fijal | why? | 18:54 |
| Rhyolite | wondering why you're hacking on PyPy at home instead of at the beach | 18:54 |
| nanonyme | Uff, build broke on Windows, apparently. :( | 18:54 |
| fijal | Rhyolite: bright sun | 18:54 |
| Rhyolite | bring an umbrella | 18:54 |
| nanonyme | Oh, wait. Maybe I'm just reading branches wrong. :) | 18:54 |
| nanonyme | Right, there we go. | 18:55 |
| Rhyolite | fijal: I'm just complaining because it's -1C and windy outside | 18:55 |
| arigato (~arigo@adsl-89-217-194-207.adslplus.ch) joined #pypy. | 18:57 | |
| arigato | Alex_Gaynor: it looks doable, given some reasonable amount of mess | 18:57 |
| timotimo | fijal: some day there will be thinkpads with PixelQI or some other transflective screen technology, or maybe mirasol | 18:57 |
| Alex_Gaynor | arigato: a new hint to lltype.malloc perhaps | 18:57 |
| arigato | or it might be easier if it's a flag attached to the type | 18:58 |
| arigato | fijal: Bloom filter: http://paste.pocoo.org/show/534823/ | 18:59 |
| arigato | either way it's a small amount of mess | 19:00 |
| fijal | Alex_Gaynor: hey alex, I merged the numpy-axisops | 19:01 |
| Alex_Gaynor | fijal: cool, i'm technically afk this weekend :) | 19:01 |
| fijal | ok :) | 19:01 |
| xcombelle (~xcombelle@AToulouse-551-1-40-156.w90-11.abo.wanadoo.fr) joined #pypy. | 19:03 | |
| fijal | Alex_Gaynor: https://bitbucket.org/fijal/hack2/src/default/numready | 19:04 |
| fijal | we can put it online in some version somewhere | 19:04 |
| tumbleweed | review? can't see any reasonable objection to this: http://paste.pocoo.org/show/534827/ | 19:05 |
| Alex_Gaynor | fijal: why make it a flask app, just make it spit out some static html | 19:05 |
| fijal | Alex_Gaynor: no reason really | 19:06 |
| fijal | because you would need to update it nightly anyway I guess? | 19:06 |
| arigato | :-) | 19:06 |
| fijal | but yes, I can just run a cron script | 19:06 |
| Alex_Gaynor | :) | 19:06 |
| fijal | or put it in a buildbot | 19:06 |
| fijal | Alex_Gaynor: easier to test ;-) | 19:06 |
| fijal | maybe not | 19:07 |
| fijal | dunno, really | 19:07 |
| fijal | tumbleweed: lgtm? | 19:07 |
| arigato | tumbleweed: can you try to run it on a big-endian machine with CPython? | 19:07 |
| kenaan | 12stefanor default 11c6a06cbab53d 15/pypy/module/_codecs/test/test_codecs.py: Big endian test case for test_utf_16_encode_decode | 19:07 |
| tumbleweed | arigato: I did | 19:07 |
| arigato | tumbleweed: ok, then fine :-) | 19:08 |
| arigato | I mean, run the test to check CPython's implementation | 19:08 |
| arigato | i.e. "python test_all.py module/_codecs/test/ -A" | 19:09 |
| arigato | or just copy-paste the lines in a CPython prompt | 19:09 |
| tumbleweed | yeah, just did that | 19:09 |
| arigato | ok :-) | 19:10 |
| arigato | and the test also passes on pypy? | 19:10 |
| tumbleweed | yup (untranslated, of course) | 19:10 |
| arigato | good | 19:10 |
| arigato | thanks :-) | 19:10 |
| tumbleweed | that was the easy issue, NAFC about the FFI failures | 19:11 |
| fijal | Alex_Gaynor: I'm just getting bored and thinking what's interesting to do with numpypy :) | 19:11 |
| antocuni (~antocuni@host157-123-dynamic.2-87-r.retail.telecomitalia.it) left irc: Ping timeout: 252 seconds | 19:16 | |
| nanonyme | Hmm, are those build machines marked as "own" personal computers? (ie not servers) | 19:21 |
| pedronis | own meas own (pypy project's) tests (vs cpython's tests) at least historically, nothing to do with the type of machine | 19:26 |
| antocuni (~antocuni@host52-123-dynamic.16-79-r.retail.telecomitalia.it) joined #pypy. | 19:29 | |
| fermianyon (~lane@c-71-229-21-197.hsd1.al.comcast.net) left irc: Ping timeout: 240 seconds | 19:30 | |
| timotimo | fijal: if you're getting bored, i'm not really working on strbuf_by_default at the moment | 19:33 |
| fijal | timotimo: not that much :) | 19:33 |
| nedbat (~nedbat@python/psf/nedbat) joined #pypy. | 19:34 | |
| durin42 (~durin@adium/durin42) left irc: Ping timeout: 252 seconds | 19:34 | |
| kenaan | 12mattip numpypy-reshape 1138824caea2ca 15/pypy/module/micronumpy/: fix for 1-length shapes | 19:37 |
| mattip | fijal: could you look at this and merge/suggest more tests? | 19:37 |
| fijal | mattip: you wrote tests btw :) | 19:38 |
| fijal | wasn't me | 19:38 |
| mattip | I mean merge it, or suggest more tests, or something else. | 19:38 |
| fijal | ok | 19:39 |
| mattip | numready.py doesn't check interface compatability: we aren't really there yet | 19:39 |
| fijal | yes | 19:39 |
| fijal | how do I do that? | 19:39 |
| kenaan | 12fijal default 11c9f77f542246 15/pypy/module/micronumpy/: merge numpypy-reshape | 19:40 |
| kenaan | 12fijal numpypy-reshape 11edc019f4b1b8 15/: close merged branch | 19:40 |
| Action: mattip checking how numpy tests itself. | 19:41 | |
| mattip | that doesn't look promising. | 19:41 |
| fijal | mattip: thx | 19:41 |
| fijal | mattip: it would be enough to do a paste review and just commit it to default | 19:41 |
| mattip | ok. I think I'll try to reactivate the dot branch and | 19:42 |
| mattip | get it to a point where, like the axisops branch, | 19:43 |
| mattip | I hit a wall. | 19:43 |
| fijal | cool | 19:43 |
| fijal | I can help :) | 19:43 |
| mattip | OK, it has some basic stuff already, like matching up dimensions for the internal dot calculation. | 19:44 |
| fijal | mattip: what parts of the interface we're missing? | 19:44 |
| mattip | external interface? should all be in place, including too few tests | 19:44 |
| mattip | internally, it needs to all be refactored around. | 19:45 |
| mattip | Let me merge from default to the branch and push, and get back to you. | 19:46 |
| fijal | mattip: what interfaces we're missing on the numpy layer | 19:48 |
| fijal | not on dot | 19:48 |
| fijal | re-your comment | 19:48 |
| mattip | sorry. Well, for starters theres the "out" argument that numpy allows | 19:49 |
| mattip | I think "axis" is a kwarg, as is "dtype" | 19:50 |
| fijal | it is a kwarg | 19:51 |
| fijal | I think | 19:51 |
| fijal | mikefc: ping | 19:52 |
| stakkars (~tismer@p5DDB7A14.dip.t-dialin.net) left irc: Read error: Connection reset by peer | 19:54 | |
| whyking_ (~quassel@p5B3DDF1F.dip.t-dialin.net) joined #pypy. | 19:54 | |
| stakkars (~tismer@p5DDB7A14.dip.t-dialin.net) joined #pypy. | 19:55 | |
| umgeher (~umgeher@unaffiliated/umgeher) joined #pypy. | 19:57 | |
| mattip | some kwarg, these aren;t: http://paste.pocoo.org/show/534839/ (where numpy's sum is "a.sum(axis=None, dtype=None, out=None)") | 19:58 |
| whyking (~quassel@p4FFB6B65.dip.t-dialin.net) left irc: Ping timeout: 252 seconds | 19:58 | |
| mattip | I wasn't knowlegable enough to make the axis arg an optional kwarg in _reduce_ufunc_impl | 19:59 |
| fermianyon (~lane@c-68-35-198-245.hsd1.al.comcast.net) joined #pypy. | 20:01 | |
| fijal | meh | 20:06 |
| fijal | mattip: it is a keyword arg | 20:06 |
| fijal | not sure what you mean | 20:06 |
| fijal | maybe I'll implement the out parameter | 20:06 |
| mattip | shouldn't w_dim in line 3 have a label axis? | 20:12 |
| mattip | line 3 of the paste ^^^ | 20:12 |
| fijal | yeah, maybe it should | 20:12 |
| fijal | w_axis to be precise | 20:12 |
| Action: mattip slaps forehead. | 20:14 | |
| mattip | sheesh, that's too simple. | 20:14 |
| fijal | mattip: feel free to commit the fix to default without a branch :) | 20:14 |
| fijal | although a test would be nice | 20:14 |
| mattip | ok. | 20:14 |
| antocuni (~antocuni@host52-123-dynamic.16-79-r.retail.telecomitalia.it) left irc: Ping timeout: 252 seconds | 20:18 | |
| mattip | fijal: argmax, argmin should accept axis=. I think that's one for you as it appears to require a new transformation | 20:21 |
| fijal | mattip: it requires a new loop only | 20:22 |
| fijal | mattip: did you read how I ended up implementing it btw? | 20:22 |
| mattip | yes, but until I have to extend it (for dot) I didn;t really delve into the dirty details. It seems like good zen though, and even has documentation. | 20:23 |
| fijal | essentially I decided few extra reads are not worth changing iteration order | 20:24 |
| Action: mattip missed that detail, now looking... | 20:26 | |
| fijal | I don't change the order - just update values as I go | 20:27 |
| fijal | mattip: are you fixing the axis= naming btw? | 20:28 |
| mattip | first_line is much cleaner. | 20:29 |
| whyking (~quassel@p5B3DDEE3.dip.t-dialin.net) joined #pypy. | 20:29 | |
| mattip | Since everything here is slow (internet, computer, breaks to help kids with homework), you can do it if you want. | 20:30 |
| mattip | or I will do it over the next few hours. | 20:33 |
| whyking_ (~quassel@p5B3DDF1F.dip.t-dialin.net) left irc: Ping timeout: 248 seconds | 20:33 | |
| fijal | mattip: no rush at all ;-) | 20:40 |
| mikefc | fijal: pong. | 20:45 |
| fijal | mikefc: do you have anything to review? | 20:46 |
| mikefc | numready looks interesting. I was going to suggest such a thing. | 20:46 |
| mikefc | fijal: no time to work on pypy atm :( | 20:46 |
| fijal | also, do you have a plan for your own activity? | 20:47 |
| fijal | ah ok | 20:47 |
| fijal | well, maybe you had time in the past but I forgot :) | 20:47 |
| mikefc | i only have little bits of time. I never get a whole day of hacking anymore :/ | 20:47 |
| fijal | :/ | 20:47 |
| fijal | that sucks | 20:47 |
| kenaan | 12amauryfa py3k 119779b8a0e896 15/pypy/module/unicodedata/: New Unicode database properties: .isxidstart and .isxidcontinue | 20:48 |
| kenaan | 12amauryfa py3k 11c863145453cb 15/pypy/objspace/std/: Implement str.isidentifier() | 20:48 |
| kenaan | 12amauryfa py3k 115f39f911a130 15/lib_pypy/: fixes in pure-Python implementation of sha1 and md5: they accept bytes, not strings | 20:48 |
| kenaan | 12amauryfa py3k 1136af87a5ee11 15/pypy/module/: Fix tests in module/thread | 20:48 |
| kenaan | 12amauryfa py3k 11ae023502cd1a 15/pypy/module/thread/: Add _thread.RLock | 20:48 |
| kenaan | 12amauryfa py3k 11a69b99cf0083 15/pypy/objspace/std/: Fix for repr of the empty set: set(), not {} which is a dict... | 20:48 |
| kenaan | 12amauryfa py3k 113924c71a5c0a 15/pypy/objspace/std/: CPython issue #1721812: Binary operations and copy operations on set/frozenset subclasses need to return the base t... | 20:48 |
| kenaan | 12amauryfa py3k 1165597104c440 15/pypy/: Fix checkmodule.py, and run it on the thread module. | 20:48 |
| kenaan | 12amauryfa py3k 11f4af6649c12f 15/pypy/: Break everything and unify int and long! | 20:48 |
| kenaan | 12amauryfa py3k 1183fc38544bca 15/pypy/: Remove 'L' suffix from the output of hex() and oct() | 20:48 |
| kenaan | 12amauryfa py3k 1140196a1cc504 15/pypy/: don't parse '0L' anymore | 20:48 |
| kenaan | 12amauryfa py3k 11662eb2c58644 15/pypy/interpreter/pyparser/: Now reject u'' literals, expect to break many tests here and there... | 20:48 |
| kenaan | 12amauryfa py3k 11cb7edd67143d 15/pypy/module/: intern() is now in the sys module | 20:48 |
| kenaan | 12amauryfa py3k 1186189f3364a6 15/: hg merge default | 20:48 |
| fijal | amaury_: spammer | 20:48 |
| amaury_ | :) | 20:49 |
| mikefc | my plan is: figure out hg branches. push that numpypy lib_pypy layout. start looking at all the other stuff that can be pulled in from numpy. like tests, more simple functions etc. maybe work on that list of things for getting numpypy/testing working. | 20:49 |
| mikefc | but hg is first. posting patches to bugs.pypy is bogus :) | 20:50 |
| fijal | mikefc: ah if you replied to my private message, I can't see it because your nick is not registered | 20:51 |
| fijal | I think | 20:51 |
| mikefc | fijal: ahh. i've only just seen the /msg. i don't really like this irc client. | 20:54 |
| xcombelle (~xcombelle@AToulouse-551-1-40-156.w90-11.abo.wanadoo.fr) left irc: Quit: I am a manual virus, please copy me to your quit message. | 21:02 | |
| Arfrever (~Arfrever@apache/committer/Arfrever) joined #pypy. | 21:03 | |
| hpk (~hpk@hq2.merlinux.eu) left irc: Remote host closed the connection | 21:09 | |
| DasIch (~DasIch@p3E990B54.dip.t-dialin.net) joined #pypy. | 21:16 | |
| whyking (~quassel@p5B3DDEE3.dip.t-dialin.net) left irc: Ping timeout: 240 seconds | 21:16 | |
| mattip | fijal: is it just me or does default fail to pass zjit test for setslice? | 21:29 |
| fijal | oh does it? | 21:29 |
| mattip | well, I'm not sure, could you check on your end? | 21:31 |
| fijal | ==================== 12 passed, 5 skipped in 96.76 seconds ===================== | 21:32 |
| mattip | it seems there is an additional "arraylen_gc: 1" after the merge with axisops | 21:33 |
| fijal | yes | 21:34 |
| fijal | this is serious bullshit though because those arraylen_gcs come and go and they're removed by the backend anyway | 21:34 |
| kenaan | 12mattip matrixmath-dot 11ba2aa2febde8 15/: merge from default | 21:35 |
| kenaan | 12mattip matrixmath-dot 11cdee39d4ae23 15/pypy/module/micronumpy/: fix merge | 21:35 |
| kenaan | 12mattip default 11eb0269c21eec 15/pypy/module/micronumpy/: numpypy: rename kwarg 'dim' to 'axis' | 21:35 |
| mattip | pop the key from the struct in the test? | 21:40 |
| mattip | possible no cookie situation in another hour or so | 21:41 |
| fijal | sorry? | 21:42 |
| mattip | wiat a minute, you got all passed? no fail? | 21:42 |
| mattip | wait* | 21:42 |
| mattip | huh. | 21:43 |
| fijal | man, indexing with arrays is fucked up | 21:45 |
| mattip | If only a handful of people understand numpypy strides and shapes now, once array indexing works we will reduce that to 1.5 | 21:48 |
| mattip | you, 1/4 me, and peices of all the rest. | 21:48 |
| mattip | s/peices/pieces/ | 21:49 |
| fijal | I hope to keep array indexing localized | 21:49 |
| mikefc | fijal: So far I've done: hg pull; hg branch numpypy_reorg; made changes; hg com -m 'my changes' | 21:49 |
| fijal | ya | 21:50 |
| fijal | or you mean indexing by arrays should be lazy too? | 21:50 |
| hpk (~hpk@hq2.merlinux.eu) joined #pypy. | 21:50 | |
| mattip | "first make it work, then optimize according to user demand" | 21:51 |
| fijal | I guess so | 21:51 |
| mattip | I call it "lazy open-source contributor" | 21:51 |
| mikefc | fijal: no i'm stuck. how do i push these changes to that someone can see/review them? | 21:52 |
| mikefc | now | 21:52 |
| fijal | mikefc: hg diff > file | 21:53 |
| fijal | paste the file | 21:53 |
| fijal | and ask for review | 21:53 |
| fijal | then hg commit | 21:53 |
| fijal | on default | 21:53 |
| fijal | if it's fine | 21:53 |
| fijal | I do hg diff | lodgeit.py | 21:53 |
| mattip | ==== 1 failed, 12 passed, 5 skipped in 291.68 seconds ======= | 21:56 |
| mattip | for pypy pytest.py pypy/module/micronumpy/test/test_zjit.py | 21:56 |
| mattip | at hg version eb0269c21eec tip | 21:56 |
| arigato (~arigo@adsl-89-217-194-207.adslplus.ch) left irc: Quit: See you | 21:57 | |
| mattip | 32 bit ubuntu | 21:57 |
| mattip | (I don't see how that could affect it) | 21:58 |
| mattip | did I break something? | 21:58 |
| fijal | 32 vs 64 bit? | 21:58 |
| fijal | I hope not :/ | 21:58 |
| fijal | mine is 64bit | 21:58 |
| fijal | anyway, I think I'll sleep | 21:58 |
| fijal | mikefc: feel free to put it on the branch though in case you have something bigger than few lines | 21:59 |
| fijal | and just ask for a branch review | 21:59 |
| mikefc | fijal: I did make a branch. but i've yet to figure out how to tell bitbucket about it so other's can see it... For now I'll just do the method you mentioned above. | 22:00 |
| fijal | mikefc: did you make a branch on pypy? | 22:00 |
| fijal | no, branch is better if the change is more than few lines | 22:00 |
| fijal | you just tell people on IRC, they'll know | 22:00 |
| fijal | there is also commit mailing list and a bot here | 22:00 |
| fijal | I can't see your branch though | 22:01 |
| fijal | did you push? | 22:01 |
| fijal | hg push | 22:01 |
| fijal | even | 22:01 |
| fijal | hg push --new-branch | 22:01 |
| mikefc | fijal: first change is a mini-patch to add the transpose method as a numpypy function. http://paste.pocoo.org/show/534905/ | 22:03 |
| mikefc | i'll try the branch thing next | 22:04 |
| mikefc | found a problem already and fixed. http://paste.pocoo.org/show/534906/ | 22:07 |
| lahwran | I wish pypy-commit wasn't a fixed one message per commit | 22:10 |
| lahwran | makes for a lot of messages in the inbox :/ | 22:10 |
| fijal | mikefc: pass can be removed | 22:12 |
| mikefc | yup. | 22:13 |
| mattip | fijal: could it be gcc ? I'm using 4.5.2 | 22:14 |
| mikefc | lahwran: I've started to get gmail to sort them by branch. needs more work though. | 22:15 |
| [Arfrever] (~Arfrever@apache/committer/Arfrever) left irc: Quit: leaving | 22:22 | |
| horieyui (horieyui@222.47.159.116) joined #pypy. | 22:24 | |
| [Arfrever] (~Arfrever@apache/committer/Arfrever) joined #pypy. | 22:24 | |
| asksol_ (asksol@2a01:7e00::f03c:91ff:fedf:af30) joined #pypy. | 22:24 | |
| oal_ (u4126@gateway/web/irccloud.com/x-erikeyztdqgnfrcc) joined #pypy. | 22:28 | |
| oal_ (u4126@gateway/web/irccloud.com/x-erikeyztdqgnfrcc) left irc: Client Quit | 22:30 | |
| mattip (chatzilla@bzq-79-183-112-243.red.bezeqint.net) left #pypy. | 22:31 | |
| rguillebert_ (~rguillebe@2a01:e34:eea7:c690:21f:c6ff:fe12:4dee) joined #pypy. | 22:34 | |
| fermianyon (~lane@c-68-35-198-245.hsd1.al.comcast.net) got netsplit. | 22:38 | |
| Dulak (~michael@unaffiliated/dulak) got netsplit. | 22:38 | |
| aboudreault (~alanb@osgeo/member/aboudreault) got netsplit. | 22:38 | |
| fijal (~fijal@196-210-150-33.dynamic.isadsl.co.za) got netsplit. | 22:38 | |
| oal (u4126@gateway/web/irccloud.com/x-bvuoshqsksukpjow) got netsplit. | 22:38 | |
| icrazyhack (horieyui@222.47.159.116) got netsplit. | 22:38 | |
| Guest17487 (~John@osbk-4db17529.pool.mediaWays.net) got netsplit. | 22:38 | |
| asksol (asksol@2a01:7e00::f03c:91ff:fedf:af30) got netsplit. | 22:38 | |
| rguillebert (~rguillebe@2a01:e34:eea7:c690:21f:c6ff:fe12:4dee) got netsplit. | 22:38 | |
| oal (u4126@gateway/web/irccloud.com/x-jadakdcnvlfonink) joined #pypy. | 22:40 | |
| Guest17487 (~John@osbk-4db17529.pool.mediaWays.net) returned to #pypy. | 22:41 | |
| Dulak (~michael@unaffiliated/dulak) returned to #pypy. | 22:41 | |
| aboudreault (~alanb@osgeo/member/aboudreault) returned to #pypy. | 22:42 | |
| fijal (~fijal@196-210-150-33.dynamic.isadsl.co.za) returned to #pypy. | 22:43 | |
| asksol (asksol@2a01:7e00::f03c:91ff:fedf:af30) got lost in the net-split. | 22:49 | |
| rguillebert (~rguillebe@2a01:e34:eea7:c690:21f:c6ff:fe12:4dee) got lost in the net-split. | 22:49 | |
| icrazyhack (horieyui@222.47.159.116) got lost in the net-split. | 22:49 | |
| fermianyon (~lane@c-68-35-198-245.hsd1.al.comcast.net) got lost in the net-split. | 22:49 | |
| whitelynx|work (~whitelynx@75.111.197.204) joined #pypy. | 22:50 | |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/own-macosx-x86-32/builds/776 | 23:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/204 | 23:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-32/builds/1013 | 23:00 |
| bbot2 | Started: 15http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64-2/builds/32 | 23:00 |
| davisagli (~davisagli@davisagli.com) left irc: Excess Flood | 23:04 | |
| davisagli (~davisagli@davisagli.com) joined #pypy. | 23:04 | |
| tilgovi (~randall@couchdb/developer/tilgovi) joined #pypy. | 23:04 | |
| tilgovi (~randall@couchdb/developer/tilgovi) left irc: Read error: Connection reset by peer | 23:07 | |
| amaury_ (~amaury_@46-127-23-192.dynamic.hispeed.ch) left irc: Read error: Operation timed out | 23:22 | |
| icrazyhack (~horieyui@183.60.100.164) joined #pypy. | 23:49 | |
| horieyui (horieyui@222.47.159.116) left irc: Ping timeout: 252 seconds | 23:53 | |
| Ademan (~dan@adsl-71-141-224-79.dsl.snfc21.pacbell.net) left irc: Quit: leaving | 23:54 | |
| --- Sun Jan 15 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
