[00:14] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) left irc: "http://fredrikj.net";
----- silence for 37 minutes ----- [00:51] <hpk> pedronis: test_compare.py never passed, btw
[00:52] <hpk> pedronis: it doesn't raise an exception but it doesn't produce the correct output eitehr (and only starting recently was this really checked)
[00:52] <pedronis> ah
[00:52] <pedronis> it's a messy test
[00:52] <pedronis> involving coercion
[00:52] <pedronis> making it pass for Jython was fun too
[00:53] <pedronis> it probably need to be run with --oldstyle
[00:53] <pedronis> btw
[00:53] <pedronis> needs
[00:53] <pedronis> that's an issue too
[00:53] <pedronis> some tests has a chance to pass only with --oldstyle
[00:53] <hpk> can we switch between oldstyle and newstyle at run time or only at init time?
[00:54] <pedronis> you can switch changing the builtin.__metaclass__
[00:55] <pedronis> if things imported with the wrong __metclass__ don't cause problems
[00:55] <hpk> so we should try adding a flag to the test declarations i guess
[00:56] <pedronis> yes
[00:56] <pedronis> test_compare is a candidate for needing it for example
[00:56] <hpk> btw, "py.test --oldstyle test_compare.py" works a lot better but produces on output-failure (compared to 10 or so without --oldstyle)
[00:56] <pedronis> yes, I thought that
[00:56] <pedronis> it really depends on coercion stuff
[00:57] <pedronis> and that work only for old style classes
[00:57] <pedronis> that's true for CPython also
[00:57] <hpk> it still has one failure, though :-)
[00:57] <pedronis> well, better than 10 :)
[00:58] <hpk> we only care about dot versus non-dot eventually :-)
----- silence for 19 minutes ----- [01:17] <hpk> pedronis: i committed the oldstyle=True switch
[01:17] <pedronis> ok
[01:18] <pedronis> it seems that test_compare has discovered a real bug
----- silence for 16 minutes ----- [01:34] <hpk> the oldstyle-hack is not completely clean, though
[01:42] Action: hpk is leaving anyway
[01:43] <hpk> the resultdir-thingie is also not completely obvious, but maybe tomorrow it is :-)
[01:49] <pedronis> I'm fixing test_compare
[02:02] Action: hpk -> bed
[02:02] stakkars (yugaot@82.140.29.171) joined #pypy.
----- silence for 33 minutes ----- [02:35] pedronis (~Samuele_P@c-3c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"
----- silence for 2 hr and 23 minutes ----- [04:58] stakkars (yugaot@82.140.29.171) left irc: Read error: 113 (No route to host)
----- silence for 2 hr and 19 minutes ----- [07:17] idnar (mithrandi@idnar.user) left irc: Connection timed out
----- silence for 1 hr and 58 minutes ----- [09:15] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
----- silence for 1 hr and 32 minutes ----- [10:47] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[10:48] ludal (~ludal@logilab.net2.nerim.net) left irc: Remote closed the connection
[10:49] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
----- silence for 25 minutes ----- [11:14] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[11:16] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[11:24] arigo (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
[11:28] <hpk> arigo: morning
[11:28] <arigo> mnorning
[11:30] <hpk> i guess i need to do a radically different approach for compliance testing
[11:31] <hpk> for getting the test results quick
[11:31] <hpk> i am probably just going to write a standalone test runner, that uses conftest.py information but otherwise basically just invokes standard pypy on each test files
[11:32] <arigo> ah?
[11:32] <hpk> this will only give only give us textual output, though
[11:32] <hpk> the thing is that properly extracting all the tests from CPython's test suite is involved
[11:32] <arigo> i.e. the problem is that a majority of the tests cannot be run via py.test at all?
[11:32] <hpk> not a majority but enough for now
[11:33] <arigo> I see
[11:33] <hpk> so i guess i am just going to write a trimmed down traversal->resultdir tool
[11:33] <hpk> and we can record things in conftest.py's testmap
[11:34] <arigo> I uh?
[11:34] <hpk> and i try to catch up so that py.test can properly produce the results we get from running from plain pypy
[11:34] <hpk> arigo: uh what exactly?
[11:34] <arigo> I think the quick tool should dump as much information as possible into a .txt file per test
[11:35] <arigo> not just say "passed" or "failed with XxxError" in testmap
[11:35] <hpk> no, sure
[11:35] <arigo> the purpose being to be able to look at and fix a test without having to re-run it before
[11:35] <hpk> (although per-test: i am not sure)
[11:35] <hpk> arigo: yes
[11:36] <hpk> i am only saying that we record information in conftest.py such as:
[11:36] <hpk> oldstyle=True, modified=True, ...
[11:36] <arigo> ah, "we" = humans, not the tool
[11:36] <hpk> yes, but either way it's a bit unsatisfying :-(
[11:37] <hpk> (forget the "but")
[11:37] <arigo> ?
[11:37] <hpk> ok, we have two strategies:
[11:38] <hpk> 1) hack out all single tests and run them (utest,doctest) via py.test
[11:38] <hpk> 2) run each test file, record its output into a result directory
[11:38] <hpk> are you with me so far?
[11:39] <arigo> yes
[11:39] <hpk> approach nr. 2) is easier but it only gives us textual output, obviously
[11:40] <arigo> well, that's already quite some information (the tests should run in -v mode)
[11:41] <arigo> I think we should do 2) because it's very quickly done, and then e.g. if a test fails and we know py.test can run it, we humans can then develop and check with py.test for this specific test
[11:41] <hpk> of course, it's a lot of information but we need to review all the information as humans
[11:41] <hpk> 2) doesn't give an easy "72% of the tests pass"
[11:41] <arigo> right, I'm missing the output tests, but then
[11:41] <arigo> that shouldn't be too hard
[11:42] <arigo> at worst we run via Python's test driver
[11:42] <hpk> ?
[11:42] <arigo> which I think should give a Unix error code for passed or failed
[11:42] <hpk> oh, so you are even proposing to start a new process for each test, ok
[11:42] <arigo> I'm saying that there is a way in CPython to run a test file and know if it failed or passed
[11:43] <arigo> for example by running a new process
[11:43] <arigo> but also simply by running whatever "make test" does, and looking at the summary
[11:43] <arigo> (don't know if it will take ages or not)
[11:44] <hpk> it will take ages for sure
[11:44] <ludal> hi guys
[11:44] <arigo> hi!
[11:44] <hpk> arigo: also because some tests really loop for half a day
[11:44] <hpk> ludal: hi !
[11:44] <hpk> arigo: or at worst - don't terminate in our lifetime :-)
[11:45] <ludal> just read the report you sent and see you are discussing about testing
[11:45] <ludal> we have a tool we use at logilab to do test reports and qa that might help
[11:45] <arigo> hpk: I see the point
[11:46] <hpk> we probably have to do a timeout of 1 hour and flag those tests somehow
[11:46] <arigo> ludal: for now the difficult problem is more about how to run the tests
[11:46] <hpk> like "slowness=100.0" (measured in hours) :-)
[11:46] <hpk> we probably have to hand-review tests that take longer than 10 minutes IMO
[11:46] <arigo> hpk: we run all the tests in parallel on a supercomputer :-)
[11:47] <hpk> like test_itertools.py just needed a modification of a loop counter to run in reasonable time
[11:47] <arigo> ok
[11:47] <arigo> btw I see the CPython's Makefile a list of tests "known to take time"
[11:47] <arigo> but they are mostly all about testing C extension modules
[11:47] <ludal> oh you mean, material considerations like testing in a finite time period ;)
[11:47] <hpk> so i guess i am aiming at restricting test runs at 30 minutes each
[11:48] <hpk> for starters and to get to results
[11:48] <arigo> yes, makes sense
[11:48] <arigo> ludal: yes :-)
[11:50] <hpk> however, i am probably not going to finish the new runner today because i am otherwise busy this afternoon
[11:50] <arigo> I can help
[11:53] <hpk> ok, give me half an hour to think a bit (and finish off something else test-related)
----- silence for 19 minutes ----- [12:12] <hpk> arigo: i suggest we start in a screen session and see how far we get
[12:12] <hpk> this makes it easier to complete the task
[12:12] <arigo> ok
[12:13] <hpk> -x hpk/hpk
[12:19] <arigo> hpk: what is the directory containing the files you're editing?
[12:19] <hpk> lib-python-2.3.4/test
[12:20] <arigo> the full path I mean
[12:20] <hpk> lib-python-2.3.4/test /conftest.py
[12:20] <arigo> on codespeak
[12:20] <hpk> yes
[12:20] <arigo> the cwd :-)
[12:20] <arigo> thanks :-)
[12:22] <arigo> what do you mean with this hackout option, then?
[12:23] <hpk> "hackout tests" from invoking test_main() and intercepting calls
[12:23] <hpk> to run_unittests/run_doctest/run_suite
[12:24] <arigo> aah, obtain single tests instead of just one global test
[12:24] <hpk> yes, see above ...
[12:24] <hpk> arigo: i guess we should go to a #conftest because our babblings make no sense to anyone here :-)
[12:24] <arigo> I understood this comment as "try harder to run the test, using if necessary the hack of just running it in a subprocess"
----- silence for 40 minutes ----- [13:04] _hannes (iwffqz@82.140.29.171) joined #pypy.
[13:10] yuuh (avvuvv@i528C12C8.versanet.de) joined #pypy.
----- silence for 17 minutes ----- [13:27] _hannes (iwffqz@82.140.29.171) left irc: Read error: 110 (Connection timed out)
[13:36] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[13:36] <cfbolz> hi all!
[13:39] <hpk> hi carl
[13:39] <arigo> hi!
----- silence for 50 minutes ----- [14:29] <cfbolz> I'm running into dicts when trying to get targetpypy1 to compile with genllvm.
[14:29] <cfbolz> so it will probably take a while until I can get it to run
[14:30] <arigo> it's string-keyed dicts only,
[14:31] <arigo> maybe a quick dummy implementation would do
[14:31] <arigo> these dicts are not used for app-level dicts.
[14:32] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[14:32] <arigo> hi
[14:32] <cfbolz> nope, what I see is not string keys only.
[14:33] <cfbolz> it's StdTypeDef instances keys mapping to W_TypeObject
[14:34] <arigo> argh.
[14:34] <arigo> it's a constant dict, then...
[14:34] <arigo> more special cases.
[14:35] <cfbolz> yes
[14:36] <cfbolz> It's constant. I sure could write a quick special case for that...
[14:39] stakkars (~tismer@rosine174.inf.fu-berlin.de) joined #pypy.
[14:40] Nick change: yuuh -> _hannes
[14:41] <cfbolz> hi
[14:42] <stakkars> hi
[14:42] <stakkars> arigo: I have small probs,again
[14:44] <arigo> yes
[14:44] <stakkars> looking into binaryop.py, I realize that
[14:45] <stakkars> add = mul = div = floordiv = mod = or_ = xor = union
[14:45] <stakkars> that means, in order to augment these ops with a raises attribute,
[14:45] <stakkars> I have to build them all. Is this right?
[14:45] <pedronis> stakkars: I read the discussion
[14:45] <arigo> yes, unless they all have the same raises attribute
[14:46] <pedronis> I think given how things are
[14:46] <pedronis> it would be simpler to have separated
[14:46] <stakkars> ok. I just wondered whether this duplication is worth it.
[14:46] <pedronis> add_throws attribute
[14:46] <pedronis> given how things are done now
[14:46] <arigo> add_throws?
[14:47] <stakkars> pedronis: fine to see you
[14:47] <pedronis> because you could put the default in SomeObject
[14:47] <pedronis> if you attach things to the methods
[14:47] <pedronis> unless you change things
[14:47] <pedronis> making inheritance work
[14:47] <pedronis> is subtle
[14:48] <arigo> ?
[14:48] <pedronis> well you need to spell all methods explicitly
[14:48] <pedronis> wich is not something we are doing
[14:48] <stakkars> you ant to put <opname>_throws into the class
[14:48] <pedronis> if I attach throw to add in SomeObject
[14:49] <pedronis> and I redefine add some level down
[14:49] <pedronis> if I don't reattach the info
[14:49] <pedronis> I need to do some lookup myself
[14:49] <pedronis> to get the default
[14:49] <arigo> pedronis: but it's for rare cases anyway
[14:49] <pedronis> but we are defining throws
[14:50] <arigo> pedronis: I don't think any default method in SomeObject should have this attribute
[14:50] <pedronis> that means no throws
[14:50] <pedronis> means the defaults?
[14:50] <arigo> the default is "throws anything", which is anyway the only sensible thing with SomeObjects
[14:51] <pedronis> I see, but is very implicit
[14:52] <arigo> yes and no
[14:52] <arigo> most methods can throw anything and it's fine
[14:52] <arigo> this is just meant as a quick workaround
[14:52] <pedronis> well, the it is going the be expressed in annrpython
[14:55] <pedronis> I mean the default
[14:56] <pedronis> unless you attach them to SomeObject in some way
[14:56] <stakkars> at the moment, the default implicit exceptions are living in objspace/flow/objspace.py
[14:56] <arigo> wait
[14:56] <stakkars> is this the right place, then?
[14:56] <pedronis> yes
[14:56] <arigo> the default behavior is to do exactly what flowin() does already
[14:56] <pedronis> I know
[14:56] <arigo> that seems reasonable
[14:57] <pedronis> I'm just thinking that is very implicit
[14:57] <pedronis> i.e. that seeing .throw = definition in annotation
[14:57] <pedronis> will open questions of what is going on
[14:57] <arigo> why?
[14:58] <pedronis> because for example no throws in jave means no throws
[14:58] <pedronis> OTOH we are not catering for the casual reader anyway
[14:58] <pedronis> so my point is indeed moot
[14:59] <stakkars> a line telling this would do it, yes
[15:00] <stakkars> right now, we have the implicit_exceptions in flow space.
[15:00] <pedronis> well they stay
[15:00] <stakkars> I also could simply add more info to this table, if other things are not handy
[15:00] <stakkars> where is the natural place to stick the info?
[15:00] <pedronis> no, because this info is type specific
[15:01] <pedronis> and we don't want to mix annotation type stuff in flow space
[15:01] <arigo> pedronis: in C++ for example, no throw means throws anything
[15:01] <stakkars> ok, pleaselet's find a decision, this thing blocks me
[15:01] <pedronis> arigo: I just find odd that we are using a property throws
[15:02] <pedronis> to say what we are not trhowing
[15:02] <pedronis> because the point is mostly to attach empty throws to integer operations
[15:02] <arigo> pedronis: what I had in mind was to list the exceptions that we *are* throwing
[15:02] <arigo> ah I see
[15:02] <cfbolz> maybe you could call it throws_only
[15:02] <arigo> indeed
[15:03] <pedronis> but then trhows_only=[]
[15:03] <pedronis> means everything or nothing? <wink>
[15:04] <stakkars> this means nothing.
[15:04] <stakkars> if the attribute exists, the default is ignored.
[15:05] <arigo> can_only_throw = [] ?
[15:05] <cfbolz> even better
[15:05] <pedronis> yes
[15:07] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[15:07] <stakkars> another small prob in binaryop is probably a typo?
[15:07] <stakkars> def and_((int1, int2)):
[15:07] <stakkars> unsigned = int1.unsigned or int2.unsigned
[15:07] <stakkars> return SomeInteger(nonneg = unsigned or int1.nonneg or int1.nonneg,
[15:07] <stakkars> unsigned = unsigned)
[15:08] <stakkars> I wonder if we should have a test that finds such
[15:09] <arigo> where?
[15:09] <stakkars> line 167, Integer,integer
[15:10] <arigo> no I mean, what's wrong with the code you pasted
[15:10] <pedronis> int1. or int1.
[15:10] <stakkars> unsigned or int1.nonneg or int1.nonneg
[15:10] <arigo> ah, ok
[15:10] <stakkars> nicely hard to find :-)
[15:10] cfbolz (~bolz@daq01.physi.uni-heidelberg.de) joined #pypy.
[15:12] <arigo> indeed.
[15:14] <stakkars> what is our current opinion how to continue?
[15:14] <arigo> can_only_throw = []
[15:14] <stakkars> as a method attribute
[15:15] <stakkars> semantics is that by existence of the attribute, all default behavior is gone
[15:15] <stakkars> [] means nothing thowable at all ???
[15:16] <pedronis> well div can still throw a ZeroDivisionError
[15:16] <pedronis> that means a bit of care is needed
[15:17] <_hannes> stakkars Logsystem updated, look @query
[15:17] <stakkars> _hannes:thanks
[15:18] Topic changed on #pypy by _hannes!avvuvv@i528C12C8.versanet.de: PyPy, Python in Python -- http://codespeak.net/pypy/ -- chanlog available for private
[15:18] <arigo> yes
[15:19] <pedronis> stakkars: now #pypy is also private?
[15:20] <cfbolz> how do I get at the logs?
[15:20] <pedronis> cfbolz: you can't
[15:20] <arigo> the #pypy logs shouldn't be hidden
[15:20] <pedronis> but that was the intention
[15:20] <pedronis> was not
[15:22] <stakkars> wait a moment...
[15:24] Topic changed on #pypy by _hannes!avvuvv@i528C12C8.versanet.de: PyPy, Python in Python -- http://codespeak.net/pypy/ -- logsystem updating
[15:28] pyb0t joined #pypy.
[15:28] <_hannes> for 5 seconds
[15:28] <_hannes> .. or less :)
[15:29] Nick change: arigo -> arigo_afk
[15:31] <_hannes> done
[15:31] Topic changed on #pypy by _hannes!avvuvv@i528C12C8.versanet.de: PyPy, Python in Python -- http://codespeak.net/pypy/ -- logsystem for äpy
[15:31] Topic changed on #pypy by _hannes!avvuvv@i528C12C8.versanet.de: PyPy, Python in Python -- http://codespeak.net/pypy/ -- logsystem for #pypy: http://nimrod.terra-link.net/pypy/
[15:34] <pedronis> stakkars: back to the topic
[15:34] <stakkars> yes
[15:34] <_hannes> everything running
[15:34] <_hannes> hf guys
[15:35] <stakkars> thanks, hannes
[15:35] <pedronis> with ovfcheck(x//y) you will still have the original problem
[15:35] <pedronis> _hannes: thanks
[15:35] <pedronis> because of ZeroDivisonError
[15:35] <pedronis> that means the division and the ovfcheck will be in different blocks
[15:35] <stakkars> because this error persists, and I have to handle a chain of blocks.
[15:36] <pedronis> yup
[15:36] <pedronis> and you can have an overflow with division
[15:37] <stakkars> maybe all these cases should be folded into one special operation, each
[15:39] <stakkars> well, if the "try to avoid the dirt" approach doesn't solve everything, then I'm wondering
[15:39] <stakkars> if the approach makes sense at all.
[15:39] <stakkars> and it would be simpler to match the stuff as it it?
[15:41] <pedronis> well, it's a bit different
[15:42] <pedronis> becaue the OverflowError handler is shared by the op and ovfcheck
[15:42] <pedronis> but the ZeroDivision is there only of the op
[15:42] <pedronis> s/of/for
[15:43] <pedronis> no, sorry, it's a call
[15:43] <pedronis> so it will share the ZeroDivision too
[15:44] <stakkars> somehow I don't like that we produce this problem...
[15:45] <stakkars> do I go for the sugested changesor do I not?
[15:47] <cfbolz> bye
[15:47] <pedronis> stakkars: it may kill some code here and there
[15:48] <pedronis> so it probably meanigful anyway
[15:48] cfbolz (~bolz@daq01.physi.uni-heidelberg.de) left irc: "Leaving"
[15:51] <pedronis> stakkars: if you look at the graph of something like
[15:51] <pedronis> def f(x,y):
[15:51] <pedronis> try:
[15:51] <pedronis> return g(x+y)
[15:51] <pedronis> except Exception:
[15:51] <pedronis> h()
[15:51] <pedronis> if x,y are Integer there is some stuff that will go away
[15:51] <pedronis> if you do the change
[15:52] <stakkars> will try it.
[15:54] <stakkars> btw.: do you think we can get rid of classobjinterp, by using the applevel() + caching techniques?
[15:59] <pedronis> stakkars: probably
----- silence for 1 hr and 3 minutes ----- [17:02] <arigo_afk> holger and me worked on generating text reports from running the CPython tests
[17:02] Nick change: arigo_afk -> arigo
[17:03] <arigo> if you log to tismerysoft.de, you can see such reports being dumped in /home/arigo/svn/pypy/dist/lib-python-2.3.4/test/result/
[17:03] <arigo> with a quickreport.py tool to extract one-liner results
[17:03] <arigo> it should be a good way to pick and fix tests.
[17:04] arre (ac@ratthing-b3fa.strakt.com) left irc: Remote closed the connection
[17:15] <pedronis> arigo: I see, I don't have a tismerysoft.de account
[17:15] <pedronis> right now I'm trying to fix the fact that string_to_int can return a Python long
[17:16] <pedronis> and that we have code that depends on that
[17:16] <arigo> I see
[17:16] <stakkars> do I create one?
[17:17] <stakkars> pedronis: ?
[17:17] <pedronis> well,it seems it would make sense
[17:21] <stakkars> pedronis: do you have an ssh key?
[17:22] <stakkars> I mean I would take the public key from codespeak
[17:22] jum (~Miranda@p548D791C.dip.t-dialin.net) joined #pypy.
[17:22] <stakkars> hi
[17:22] <jum> hi all
[17:23] <pedronis> stakkars: I can generate one
[17:23] <jum> hpk: listening?
[17:23] <stakkars> I thinkyou have a .ssh folder on codespeak. can you paste it somewhere? I cannot access it.
[17:24] <jum> the .ssh folder is created automatically for you if the account is created.
[17:24] <stakkars> ah, ok
[17:25] <stakkars> pedronis: please create one. I will give you a temp password, too. You find it in pypy/_cache :-)
[17:27] <pedronis> what is preferred a proto 2 dsa key or rsa key
[17:27] <stakkars> I use dsa I think, no idea. You can log in, now
[17:27] <stakkars> user = pedronis
[17:27] <jum> I would say proto 2, as the other is just for compatibility with old ssh versions
[17:28] <stakkars> password = full name of cached file that is about buffer :-)
[17:32] <arigo> hi jum
[17:33] <stakkars> pedronis: login works, and you have a .ssh folder. Please add your key and change your password to something different.
[17:33] <stakkars> ASAP
[17:33] <pedronis> stakkars: I'm trying to login
[17:33] <stakkars> yes
[17:34] <stakkars> the site is ssh only
[17:34] <stakkars> ssh pedronis@tismerysoft.de
[17:35] <stakkars> I see. the password is too long :-(
[17:38] <arigo> abstract_mro() in typeobject.py is a non-RPythonic gateway.applevel
[17:38] <pedronis> stakkars: yes, I did not manage to login
[17:39] <stakkars> sorry, I see I disabled password logins, need your key
[17:39] <pedronis> I will mail you the key
[17:39] <stakkars> justput it on codespeak
[17:41] <pedronis> ok can do that too
[17:42] <stakkars> and sorry about this mess, I created an account on the wrong machne :-)
[17:44] <pedronis> it's id_dsa.pub in my homedir
[17:45] <stakkars> thanks
[17:54] <stakkars> pedronis: it might work now, please try to ssh in
[17:55] tic (~vision@c-ba6e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Ping timeout: 14400 seconds
[17:55] <pedronis> stakkars: yes it works, thanks
[17:55] <stakkars> ah!
[17:55] jum (~Miranda@p548D791C.dip.t-dialin.net) left irc: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org";
----- silence for 19 minutes ----- [18:14] jum (~Miranda@p548D791C.dip.t-dialin.net) joined #pypy.
----- silence for 20 minutes ----- [18:34] Action: arigo working on test_types.py
[18:35] tic (~vision@s-213-115-110-186.sme.bredbandsbolaget.se) joined #pypy.
[18:38] <arigo> argh argh argh.
[18:38] <arigo> in plain Python_
[18:38] <arigo> >>> u''.__getslice__(0, sys.maxint)
[18:38] <arigo> Traceback (most recent call last):
[18:38] <arigo> File "<stdin>", line 1, in ?
[18:39] <arigo> OverflowError: signed integer is greater than maximum
[18:39] <arigo> on a 64-bit machine
[18:51] <stakkars> I added these new attributes to binaryop
[18:51] <arigo> ok
[18:52] <stakkars> and then tried to find them in the operations in flowin
[18:52] <stakkars> but thst's probably naive. I guess I need to extend the code that generates these
[18:53] <stakkars> functions to respect the extra attribute as well,maybe?
[18:53] <arigo> I don't really see how
[18:53] <stakkars> yow or why?
[18:53] <arigo> my guess is that you need to hack this information manually, with 'if op.opname in BINARY_OPS:...' or something
[18:53] <arigo> how
[18:54] <stakkars> hum, schnueff. I hoped this would show up in the function.
[18:54] <arigo> which function? consider_op_xyz() ?
[18:55] <stakkars> sigh, I searched the wrong thing, again and assumed to find op=simple_call
[18:56] <stakkars> and then the <function mul__Int_Int
[18:56] <arigo> remember, mul__Int_Int is not something that exists
[18:56] <stakkars> but that was a bad idea, because it contains the operation I need toinspect.
[18:56] <stakkars> sorry.
[18:56] <stakkars> yes I see.
[19:01] idnar (mithrandi@idnar.user) joined #pypy.
[19:12] <arigo> ooopsy
[19:12] <arigo> CPython calls __getslice__() for x[2:5] but __getitem__() for x[2:5:]
[19:14] jum (~Miranda@p548D791C.dip.t-dialin.net) left irc: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org";
[19:16] <pedronis> umph
[19:16] <arigo> http://www.python.org/doc/2.3.4/ref/sequence-methods.html
[19:16] <arigo> the problem is this documentation
[19:16] <arigo> which says that a cool way to write backward-compatible programs
[19:16] <arigo> is some example code,
[19:17] <arigo> in which this [x:y:] trick is used to call __getitem__ from __getslice__
[19:21] <pedronis> umph, __getslice__ etc have been deprecated but in practice all the mess is still there and tested
[19:21] <arigo> yes
[19:21] <arigo> note also that the example code from the doc only defines __getslice__ if sys.version < (2,0)
[19:22] <arigo> so someone exactly following the doc will be ok
[19:22] <arigo> otherwise we'll probably have to add a space.getslice(), which by default falls back to space.getitem(space.newslice())
[19:23] <arigo> this would only be called from the [:] syntax, and that's it
[19:23] <pedronis> can we not just workaround in _clsasobj
[19:23] <arigo> it's not specific to old-style classes
[19:23] <pedronis> I know but __getslice__ should not be there in principle
[19:23] <pedronis> umph^3
[19:24] <arigo> I agree in principle :-)
[19:25] <arigo> is the introduction of space.getslice() so awful?
[19:25] <arigo> not as an official operation
[19:25] <arigo> just a convenient method, which descroperation overrides subrepticiously
[19:25] <pedronis> no
[19:26] <pedronis> it's probably saner that put more mess in getitem
[19:26] <arigo> s/that/than
[19:26] <arigo> ?
[19:27] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[19:27] <pedronis> yes, than
[19:31] <stakkars> back in flowin, do I look at the BlockedInference parts at all, or do I just ignore
[19:31] <stakkars> that logic and insert some postprocessing of the exist before the "for link in exits"?
[19:32] <stakkars> exits
[19:32] <stakkars> (I was simplylooking into the wrong things, before)
[19:34] <pedronis> did someone run all the tests recently?
[19:34] <pedronis> test_itertools in lib/test2 seem to take forever
[19:35] <pedronis> it's probably because of the new mode for runnign
[19:37] <arigo> stakkars: I guess you need preprocessing,
[19:37] <arigo> stakkars: but in the 'else:' part of the big try:except:, specifically
[19:37] <stakkars> yes, I understood meanwhile. consider_op is meant to signal something that cannot be reached.
[19:38] <arigo> stakkars: actually, it might go just before the for link in exits loop, too
[19:38] <stakkars> actually, I have to use last_exception again
[19:38] <arigo> it doesn't have to be in that else part.
[19:38] <stakkars> yes, the distinction doesn't make much sense.
[19:38] <arigo> yes, you have to do something only if block.exitswitch == Constant(last_exception)
[19:39] <stakkars> I simplylook at the last op and filter if I find it to have toomuch.
[19:40] <arigo> yes
[19:40] <arigo> pedronis: at the moment I'm veeery confused about whether W_SliceObject.w_start/w_stop can be real Nones or not
[19:43] <stakkars> arigo: ok, now I find my "mul" operation. Now I check the types of the arguments and do some lookup, right?
[19:43] <pedronis> arigo: it seems there is code in pyopcode
[19:44] <pedronis> that creates slices with interp-level None
[19:44] <arigo> stakkars: yes, you have to check if the operation name is in annmodel.BINARY_OPERATIONS
[19:44] <arigo> stakkars: then look for getattr(pairtype(arg1, arg2), op.opname)...
[19:44] <arigo> sorry, getattr(pair(arg1, arg2), op.opname)...
[19:44] <arigo> pedronis: yes, I see real Nones in the interp-level console
[19:45] <stakkars> uhh, such an expensince thing. well, will do
[19:45] <arigo> don't forget then to do the same with UNARY_OPERATIONS
[19:45] <arigo> :-(
[19:45] <stakkars> muuh
[19:45] <arigo> pedronis: we get real Nones, but reading the attribute at app-level works,
[19:46] <arigo> pedronis: because gateway.py ultimately turns the real Nones into w_Nones :-(
[19:46] <arigo> clean up time.
[19:47] <pedronis> arigo: python ../../test_all.py -E in lib/test2 works
[19:47] <pedronis> but specifying the -E option at top level does not work
[19:47] <pedronis> and the tests are tried but in very slow mode :(
[19:49] <arigo> ah
[19:50] <arigo> bad
[19:51] <pedronis> does pypy/module/recparser/test/test_samples.py passes, I get one failure?
[19:51] <arigo> we should force the -E option for lib/test2, I guess
[19:51] <arigo> pedronis: I get 3 or 4 failures depending on the machine I'm on :-(
[19:52] <pedronis> for that test?
[19:52] <arigo> pedronis: you can try adding
[19:52] <arigo> libconftest.option.extracttests = True
[19:52] <arigo> after libconftest = libtestdir.join('conftest.py').getpymodule()
[19:53] <arigo> in lib/test2/conftest.py
[19:53] <pedronis> I will
[19:53] <pedronis> so you get failures with the parser test?
[19:53] <pedronis> I'm trying to get to the point of checking my string_to_* changes
[19:53] <pedronis> (which took longer and were messier than expected)
[19:53] <arigo> pedronis: only one failure in test_samples.py on that other machine...
[19:54] <pedronis> ok, I will ignore that
[19:54] <pedronis> for now
[19:54] <arigo> yes
[19:56] <pedronis> I think I have fixed type issues in descr__new__ for int and long
[19:56] <pedronis> but they will a lot of polishing at some point
[19:56] <pedronis> will need
[19:58] <arigo> I see
[19:59] <arigo> grmuble, we can't override methods from class DescrOperation
[20:00] <arigo> I'm considering making the __getslice__ special case in StdObjSpace
[20:00] <stakkars> yet another dumb question alert:
[20:00] <stakkars> when I get the args of the binary operation, they are variables.
[20:00] <stakkars> is it true that I use self.binding, to get at the SomeXXX representation?
[20:01] <arigo> yes
[20:01] <stakkars> thx
[20:01] <arigo> as in consider_op().
[20:02] <pedronis> arigo: svn seems in need of a kick
[20:02] Action: arigo kicks
[20:03] <arigo> done
[20:04] <pedronis> thanks
[20:04] <pedronis> I have checked in my type-proper varitions on messyness
[20:09] <arigo> interpreter/test/test_gateway.py test_interp2app_unwrap_spec_typechecks
[20:09] <arigo> contains a 2**32 supposed to overflow
[20:09] <arigo> doesn't work on codespeak, of course
[20:09] <pedronis> I can fix that
[20:10] <pedronis> it was noticed a lot of times
[20:14] <pedronis> done
[20:17] <stakkars> arigo: for the unary op case, I do not use pair(x, y), but just look into x?
[20:17] <arigo> yes
[20:23] <stakkars> gack! simple_call is an unary operation :-(
[20:24] <pedronis> arigo: of course the question is whether _classobj itself now needs __getslice__ etc?
[20:24] <arigo> stakkars: why do you worry about simple_call?
[20:25] <stakkars> I don't. I just unpacked the args, assuming that a unary operation has a single argument :-)
[20:25] <arigo> pedronis: I see
[20:25] <pedronis> what test was failing btw?
[20:25] <arigo> :-)
[20:25] <pedronis> test_userlist?
[20:25] <stakkars> :-) was for me?
[20:25] <arigo> stakkars: yes :-)
[20:26] <arigo> pedronis: no, test_userlist fails differently
[20:26] <stakkars> is it safe to blindly unpack the binary args, or should I always use indexing?
[20:26] <arigo> pedronis: let me try to remember why I started on getslice in the first place...
[20:26] <pedronis> of course the general question is which tests need to be run with --oldstyle
[20:26] <arigo> stakkars: always indexing, I guess
[20:27] <pedronis> because if we don't pay attention
[20:27] <arigo> stakkars: e.g. for pow(x,y,z), which is a binary too
[20:27] <pedronis> we may mess up new-styles just to fit tests
[20:27] <pedronis> that make sense only for oldstyle
[20:27] <arigo> that's a point
[20:27] <pedronis> although maybe for just some crazy detail
[20:28] <pedronis> in theory we should run everything with oldstyle
[20:28] <arigo> test_userlist fails strangely
[20:28] <pedronis> put things will get even slower
[20:29] <arigo> indeed
[20:30] <pedronis> well some failure in userlist are about set/getslice
[20:31] <pedronis> although we die inside our own list implementation
[20:31] <arigo> yes
[20:35] <stakkars> arigo: ok
[20:39] <stakkars> ok, I end upwith something like this
[20:39] <stakkars> if can_only_throw is not None:
[20:39] <stakkars> exits = [this
[20:39] <stakkars> if not isinstance(this, Exception)
[20:39] <stakkars> or this in can_only_throw
[20:39] <stakkars> for this in exits]
[20:39] <arigo> exits is a list of Links, not Exceptions
[20:40] <arigo> you need this.exitcase
[20:41] <stakkars> yes, sorry, a typo
[20:48] hpk (~hpk@merlinux.de) left irc: Read error: 145 (Connection timed out)
[20:50] <arigo> the crash is with a statement like lst[:-3] = []. fixed.
[20:51] <arigo> (if lst is empty in the first place, this crashes)
[20:54] hpk (~hpk@merlinux.de) joined #pypy.
[20:55] <stakkars> arigo: ok, this works fine, now.
[20:55] <stakkars> I wonder if I must do something more.
[20:55] <arigo> great
[20:55] <stakkars> with -no-t the single block is still alone, just no exception.
[20:56] <stakkars> without no typer, the flow graph is
[20:56] <stakkars> getattr, getattr, mul, conv:from:obj,
[20:56] <stakkars> then jumps to a new block that does
[20:57] <stakkars> conv_to_obj, then simle_call(ovfcheck)
[20:57] <stakkars> this might be ok if I handle the ovfcheck, in another pass.
[20:57] <stakkars> But do I have to do some merging ov blocks?
[20:59] <arigo> the transformation pass comes before the typer
[20:59] <arigo> if you put it in the correct order in transform.py's transform_graph(),
[20:59] <arigo> then you can assume that the blocks are merged
[21:00] <arigo> hum, wrong
[21:00] <arigo> I guess that transform_graph() needs to call explicitely simplify.join_blocks() after transform_dead_code(), for this kind of case.
[21:02] <stakkars> maybe I can ignore this, since after what Samuele said, I anyway need to match across blocks?
[21:02] <arigo> do you need to match across blocks?
[21:03] <stakkars> yes, because can_only_raise is not empty for truedic,for instance.
[21:03] <stakkars> truediv
[21:03] <stakkars> so in generalI need to look at the last operation if I encounter ovfcheck,
[21:04] <stakkars> regardless if in the same block or in the previoius
[21:04] <stakkars> last op before the ckeck I meant.
[21:04] <stakkars> Then probably emit special operation that handles all of this.
[21:05] <stakkars> oops, sorry, my step parents are at home. More on Friday.
[21:05] <stakkars> will check in what I have.
[21:05] <arigo> ok. (yes I see, makes sense)
[21:06] <arigo> pedronis: I see the point of putting __getslice__ in _classobj
[21:08] <pedronis> arigo: is test_userdict passing?
[21:08] <arigo> no
[21:08] <pedronis> mmh
[21:08] <arigo> instance.__getslice__ is never called
[21:09] <pedronis> arigo: it is passing for me
[21:09] <arigo> oups oups
[21:09] <arigo> I need to regenerate the thing
[21:09] <pedronis> but not with oldstyle
[21:09] <arigo> ah
[21:09] <pedronis> because there's a bug in _classobj
[21:10] <pedronis> it is strange because in result
[21:10] <pedronis> the output is similar as what I get with oldstyle
[21:10] <pedronis> but it should not have been run with oldstyle I think
[21:10] <pedronis> ??
[21:11] <arigo> how did you run it?
[21:11] <pedronis> just with py.py
[21:11] <arigo> ah
[21:12] <pedronis> it's a unittest test
[21:12] <pedronis> without --oldstyle passes
[21:12] <pedronis> with fails
[21:12] <stakkars> checked in - see you
[21:13] <arigo> see you!
[21:16] <arigo> pedronis: it passes now, with __getslice__&co implemented in _classobj.
[21:17] <pedronis> you mean in descroperation?
[21:17] <pedronis> or you mean userlist?
[21:17] <arigo> py.test test_userlist
[21:17] <pedronis> ah
[21:18] <pedronis> I was referring to userdict
[21:18] <arigo> oups
[21:18] <arigo> I missed that completely
[21:19] <pedronis> which passes
[21:19] <pedronis> but I don't understand the file in result
[21:19] <pedronis> because I get that failure only with --oldstyle
[21:19] <pedronis> a bug that I'm going to fix
[21:20] <pedronis> but I'm still puzzled
[21:20] <arigo> __nonzero__ that should call __len__, right?
[21:20] <pedronis> yes
[21:20] <pedronis> it does but there's a typo
[21:20] <arigo> it's called __nonzero__ instead of __len__ the 2nd time :-)
[21:21] <pedronis> yes
[21:21] <pedronis> I have fixed that locally
[21:21] <pedronis> I need to regen
[21:25] <pedronis> ok
[21:27] <pedronis> arigo: yes, it seems that we should regenerate the results
[21:30] <arigo> funny administration
[21:30] <arigo> I've been away with no pay from Southampton for months
[21:31] <arigo> and now I see that my pay slips have no pay, and -107 pounds of tax
[21:31] lypanov (~alex@a80-126-190-213.adsl.xs4all.nl) joined #pypy.
[21:31] <arigo> so I was still getting 107 pounds per month
[21:31] Action: lypanov waaves
[21:31] <arigo> hey, hi!
[21:32] <lypanov> hey arigo :)
[21:32] Action: lypanov is reading pypy-dev and grumbling
[21:32] <lypanov> arigo: maybe you can explain
[21:32] <lypanov> arigo: okay, exactly what are smalltalk vm's and lisp compilers doing to aid dynamic languages?
[21:33] stakkars (~tismer@rosine174.inf.fu-berlin.de) left irc: Read error: 113 (No route to host)
[21:33] <lypanov> arigo: small talk's vm's get dispatch nice and fast, and i understand this is a great boost, but isn't gcc proof enough that static optimisation isn't good enough for even *static* languages?
[21:34] <arigo> I actually didn't look in depth in the links I forwarded so far
[21:34] <arigo> I think the idea was that they may help for the static compilation part
[21:34] <arigo> which is where we are currently working, for PyPy
[21:34] <lypanov> yup
[21:34] <lypanov> but the thing that makes me go ooooooooooooh about pypy
[21:35] <lypanov> is the fact that its designed in a such a way that *real* optimisation can be done :P
[21:35] <arigo> sure :-)
[21:35] <arigo> I guess I should mention that to pypy-dev
[21:35] <arigo> Michele's posting followed the ACCU conference talk, which was essentially only about the static analysis part
[21:36] Action: arigo gets real-mail spams for a Java testing tool
[21:37] <lypanov> hehe
[21:43] Action: pedronis is leaving the office
[21:43] <pedronis> bye
[21:43] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
[21:47] <arigo> lypanov: sure. I think our nose is stuck too close to the current static-code-generation mess
[21:49] <lypanov> arigo: hehe. and mine to the spiderweb code i've created :P
----- silence for 17 minutes ----- [22:06] <arigo> dinner time
[22:06] <arigo> sorry, I was a bit too busy to chat tonight, see you next time
[22:06] Nick change: arigo -> arigo_afk
----- silence for 16 minutes ----- [22:22] Action: lypanov will be back :)
[22:22] <lypanov> night all!
[22:22] lypanov (alex@a80-126-190-213.adsl.xs4all.nl) left #pypy.
----- silence for 27 minutes ----- [22:49] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[23:01] <hpk> pedronis: hi samuele, does the reorg-thing mentioned on pypy-dev make sense to you?
[23:02] jriehl (~jriehl@sidewinder.cs.uchicago.edu) left irc: "Download Gaim [http://gaim.sourceforge.net/]";
[23:04] <pedronis> hpk: probably yes. Honestly I'm just tring to orient myself with the failing tests and infrastructure
[23:05] <hpk> if you have questions, feel free
[23:05] <hpk> test_mutants.py seems to loop forever
[23:05] <hpk> or at least > 1 hour or so
[23:06] <hpk> although i can't see an obvious reason why this is so
[23:06] <hpk> well, not true, i can imagine some :-)
----- silence for 24 minutes ----- [23:30] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) joined #pypy.
[00:00] --- Thu Apr 28 2005