[00:27] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[00:41] stakkars_ (fibbxb@dsl-62-220-10-27.berlikomm.net) joined #pypy.
[00:41] stakkars (epsvpe@dsl-62-220-10-27.berlikomm.net) left irc: Connection reset by peer
[00:44] Nick change: stakkars_ -> stakkars
[00:44] stakkars (fibbxb@dsl-62-220-10-27.berlikomm.net) left irc: Client Quit
[00:45] stakkars (harhmjr@dsl-62-220-10-27.berlikomm.net) joined #pypy.
[00:46] <stakkars> pedronis: hehe, it seems to be armin's code,not mine :-))
[00:46] <pedronis> the problem?
[00:46] <stakkars> yes
[00:46] <pedronis> you mean some other simplification
[00:47] <pedronis> or check_graph itself
[00:47] <stakkars> my flowing workscompletely through, passes the checks. Then genc is activated and gives the crash
[00:47] <stakkars> no simplification that I did, I think.
[00:47] <pedronis> you mean the check_graph assertion or something else?
[00:47] <stakkars> if checkgraph is normative and a graph is valid ifff checkgraph works, then I'm fine.
[00:48] <stakkars> the assertion happens in a context where my simplifications are done and already checked.
[00:48] <pedronis> the one about last_exc
[00:48] <stakkars> I will look into it, anyway
[00:48] <stakkars> yehes
[00:48] <pedronis> the annotator
[00:48] <pedronis> ?
[00:48] <pedronis> it has assertions about that
[00:49] <stakkars> it happens when armin inserts a conv_to_obj
[00:49] <pedronis> what assertion do you exactly get and from which line?
[00:50] <stakkars> the assertion is from line 365 (# of days per year that's why I remembered after my system crash)
[00:51] <stakkars> last_exc_value
[00:51] <stakkars> the function is Executioncontext.call_tracing
[00:51] <stakkars> I'm trying to reproduce that, but I need to figure out what initial state I must provide, to cause the specialization.
[00:52] <pedronis> I see, it some change to the flowgraph taht happen later
[00:52] <stakkars> I'm indirectly the cause of this since I produce such tight graphs, now
[00:52] <pedronis> something is propagating the constants
[00:53] <stakkars> but this is an advantage
[00:53] <stakkars> since we find out this way.
[00:53] <pedronis> but as we discussed that should be really changed
[00:54] <stakkars> yes. I'm just happy that not I broke the axioms but their inventors ;-)
----- silence for 1 hr and 57 minutes ----- [02:51] <pedronis> stakkars: test_geninterp is completely failing right now!
[02:53] <stakkars> nanu, I thought it ran through test_all. But you are right!
[02:54] yuuh (xqacjlpv@dsl-62-220-10-27.berlikomm.net) left irc: "utz utz utz"
----- silence for 29 minutes ----- [03:23] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"
[03:37] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) left irc: "http://fredrikj.net";
----- silence for 2 hr and 31 minutes ----- [06:08] tea (~tea@cap010-137.kcn.ne.jp) joined #pypy.
[06:13] tea (~tea@cap010-137.kcn.ne.jp) left irc: Remote closed the connection
[06:27] stakkars (harhmjr@dsl-62-220-10-27.berlikomm.net) left irc: Read error: 113 (No route to host)
----- silence for 2 hr and 8 minutes ----- [08:35] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
----- silence for 35 minutes ----- [09:10] sanxiyn_ (~tinuviel@211.104.100.115) joined #pypy.
[09:10] <sanxiyn_> r12102: test_pickle now passes
[09:11] <sanxiyn_> Well, I haven't done anything except running the test. :-)
[09:11] <sanxiyn_> Must be related to disabling of _codecs.
[09:15] aleale (~root@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.
----- silence for 43 minutes ----- [09:58] adim (~adim@logilab.net2.nerim.net) joined #pypy.
[10:07] cfbolz (~cfbolz@edv01.physi.uni-heidelberg.de) joined #pypy.
[10:07] <cfbolz> hi all!
----- silence for 42 minutes ----- [10:49] cfbolz (cfbolz@edv01.physi.uni-heidelberg.de) left #pypy ("Leaving").
[10:55] <aleale> hi
[10:58] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[11:03] <sanxiyn_> hi
[11:05] <arigo> hi!
[11:06] <sanxiyn_> Now having fun with Selenium.
[11:07] <sanxiyn_> (Automated web testing)
[11:07] <aleale> I have some questions on windows specific codecs
[11:07] <aleale> (MBCS codec)
[11:08] <aleale> In CPython those codecs are implemented using windows systemcalls
[11:08] <arigo> aleale: I see
[11:09] <aleale> Could PyPy use ctypes for this (adding an extra external dependence)?
[11:10] <aleale> I'd prefer that to implement the codecs from scratch
[11:10] <arigo> it's a difficult question
[11:10] <arigo> definitely, I understand. We need something similar in other cases too, anyway.
[11:10] <sanxiyn_> Using ctypes will allow running it on CPython.
[11:10] <sanxiyn_> How it will be translated... I don't sure.
[11:11] <arigo> aleale: can you point me to a few examples in the CPython source?
[11:12] <aleale> in unicodeobject.c line 2673 onwards
[11:12] <aleale> function PyUnicode_DecodeMBCS it says :
[11:12] <aleale> DWORD usize = MultiByteToWideChar(CP_ACP, 0, s, size, NULL, 0);
[11:13] <arigo> yup, I see
[11:13] <aleale> as an example
[11:13] <aleale> with ctypes it would look like :
[11:13] <aleale> WideCharToMultiByte = windll.kernel32.WideCharToMultiByte
[11:14] <aleale> mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size, s, 0, None, None)
[11:15] <arigo> aleale: for now, you should probably go the simpler way of "cheating"
[11:16] <arigo> i.e. use in this case t = s.decode('msbc') directly
[11:17] <arigo> or, if you'd like to be more explicit,
[11:17] <aleale> sorry I dont understand (using the faked unicode object ? )
[11:17] <arigo> ah right. first, your unicode objects are implemented how? (sorry I didn't look)
[11:18] <arigo> lists of integers?
[11:18] <arigo> (sorry if I'm lost, I just don't know unicode that much and I'm not sure how codecs fit in that picture)
[11:19] <aleale> I dont implement unicode objects, only different codecs
[11:19] <arigo> ok
[11:19] <aleale> So I am counting on arre to implement the objects.
[11:20] <arigo> ah, fine.
[11:20] <arigo> so yes, maybe you really have to do t = s.decode('msbc')
[11:20] <aleale> He can then hopefully use my implementations of the codecs when he need to grow the encode/decode and translate methods
[11:21] <arigo> I see
[11:21] <arigo> thinking about the levels, it seems that only arre is doing interp-level coding, so he'll have to do something explicit about decoding with argument 'msbc' in the unicode object implementation...
[11:21] <arigo> well it's a bit strange if both codecs and unicode.decode call each other
[11:22] <arigo> ok, I'm starting to be confusing. start again...
[11:22] <aleale> in CPython s.decode('mbcs') means: lookup the encoding 'mbcs' in the codec registry, to find the implementattion of the codec
[11:22] <arigo> ok
[11:22] <aleale> Yes it is strange
[11:23] <arigo> so it seems that you have a situation where you need to call some built-in function to help you.
[11:23] <sanxiyn_> (And 'mbcs' codec is in _codecs, which is built-in module.)
[11:24] <arigo> aleale: what is unicodecodec.py ?
[11:24] <aleale> the actual implementation is then found via the _codecsmodule (which is a thin wrapper to the implementation in unicodeobject.c)
[11:25] <sanxiyn_> I guess unicodecodec.py is a port of codec part of unicodeobject.c.
[11:25] <aleale> unicodecodec is the module holding the reimplementation of the codecs in unicodeobject.c, codecs.c and stringobject.c
[11:25] <arigo> ok
[11:26] <aleale> so _codecs.py is looking much like _codecsmodule.c (thin wrapper)
[11:27] <arigo> I'm wondering what source code it would make sense to have at app- or interp-level
[11:27] <aleale> and unicodecodec is a ugly monster (like unicodeobject.c and friends)
[11:27] <aleale> I have wondered to
[11:28] <arigo> unicodecodec seems to be directly adapted from C code, so it might make sense to keep that at interp-level
[11:28] <aleale> because of the size of the code base I thought in best to have it in applevel (I might be wrong)
[11:28] <sanxiyn_> And _codecs.py at app-level makes sense, I think.
[11:29] <arigo> It's never clear what is best... app-level can be more compact or less compact than interp-level (depending on compiling modes), and it's quite slower in both cases
[11:29] <aleale> hopefully we can use geninterplevel on unicodecodec.py then
[11:29] <arigo> precisely, geninterplevel will make the translated unicodecodec enormous...
[11:30] <arigo> (unless we work more quite a bit more on geninterplevel)
[11:30] <aleale> sure but then again it is adapted from several thousand lines of c code
[11:30] <arigo> yup. for now it actually looks very much RPythonic
[11:31] <aleale> It is copied from the c code and then delete most of the c code again
[11:31] <arigo> :-)
[11:31] <sanxiyn_> I think I noticed it doesn't do buffer-length calculation.
[11:32] <sanxiyn_> (And do ''.join instead.)
[11:32] <arigo> sanxiyn_: I see
[11:32] <arigo> (that's great, it's much less strange code around :-)
[11:32] <aleale> I thought that was the easiest
[11:33] <arigo> sure
[11:34] <arigo> I'm a bit confused, though
[11:34] <arigo> e.g. in PyUnicode_DecodeUTF7
[11:34] <arigo> is 'p' a list through all the function?
[11:35] <arigo> or a unicode object?
[11:35] <aleale> the intention is that 'p' is list
[11:36] <arigo> you never tests that code, then?
[11:36] <arigo> p += '-'
[11:36] <arigo> also, "p, ... = DECODE(p, ...)" but DECODE returns a unicode object as p
[11:37] <aleale> test_codecscallback has utf7 test - but I see the problem in DECODE
[11:37] <arigo> "outpos = p-PyUnicode_AS_UNICODE(unicode)" ? is that just a remaining piece of C code, work in progress?
[11:38] <aleale> I am having trouble locating tests for the _codecs module do you have a hint
[11:39] <aleale> work in progress. I've been focussed onn making test_codecscallback.py pass
[11:40] <arigo> ok
[11:41] <arigo> that makes sense, yes.
[11:42] <sanxiyn_> assert re.compile('foo').pattern == 'foo'
[11:42] <sanxiyn_> What would be needed to pass this on PyPy?
[11:43] <arigo> sanxiyn_: we should re-activate the _sre_pypy wrapper module, in pypy/module/
[11:43] <arigo> then it's the kind of thing that we can implement cleanly
[11:43] <sanxiyn_> I see... should look at it.
[11:45] <arigo> aleale: I think that you need more synchronization with arre about unicodecodec.py
[11:46] <arigo> Samuele tell me that the idea of unicodeobject.py is to use lists of unicode characters internally
[11:46] <arigo> "unicode characters" being one-character unicode strings, internally
[11:46] <arigo> so from this point of view, the work of functions like PyUnicode_DecodeUTF7 is
[11:47] <arigo> to build a list of unicode characters
[11:47] <arigo> i.e. p would be a list, and you use p.append(ch) or p.extend(other_list) or whatever,
[11:47] <arigo> and at the end you can return W_UnicodeObject(space, p)
[11:47] <arigo> (in the model where unicodecodec.py is at interp-level)
[11:50] <arigo> then for MBCS, as PyUnicode_DecodeMBCS would be written at interp-level, it's clearer that you can cheat like this:
[11:51] <arigo> list(u''.join(input_unicode_obj.ob_chars).decode('mbcs'))
[11:51] <arigo> because this is an interp-level call to decode()
[11:51] <arigo> i.e. to CPython's decode()
[11:52] <aleale> so the u''.join(p) is deferred to _codecs
[11:52] <arigo> no:
[11:52] <arigo> a W_UnicodeObject contains internally a list of chars
[11:52] <arigo> and appears to be a single app-level unicode string
[11:52] <arigo> no-one ever joins the characters, essentially
[11:53] <arigo> that's why it's important to distinguish the two levels
[11:53] <aleale> ok
[11:54] <arigo> for mbcs we have some mecanism to say that a specific interp-level helper function needs to be considered and translated in a special way,
[11:55] <arigo> for example:
[11:55] <arigo> def MultiByteToWideChar(mode, input_list_of_chars):
[11:55] <arigo> return list(u''.join(input_list_of_chars).decode('mbcs'))
[11:56] <arigo> writing this at interp-level is a clean encapsulation of what the function of the same name does in C
[11:56] <arigo> then we can really say "by the way, this function corresponds directly to the C function MultiByteToWideChar"
[11:56] <arigo> this is said somewhere else, in a GenC-specific list of special cases.
[11:58] <aleale> ok It sounds like I'll ahve to rewrite the unicodecodecs.py at interplevel
[11:58] <arigo> it shouldn't too much a change, though
[11:58] <arigo> shouldn't be
[11:58] <aleale> and move it to modules?
[11:59] <arigo> yes
[11:59] <arigo> hum.
[12:00] <aleale> The string specific codecs should go into modules/stringcodecs.py
[12:00] <aleale> ?
[12:00] <arigo> from another point of view, unicodecodec.py is a nice PyPy-independent implementation of codecs
[12:00] <aleale> well I dont think it is nice ( not yet anyway )
[12:01] <aleale> to c-ish
[12:02] <arigo> we can think about finding a nice place for unicodecodec.py
[12:02] <arigo> suppose that it'd take lists of characters as input, and produce lists of characters as output, with nothing specific to PyPy
[12:03] <aleale> for now I will go for lunch and then change it into the list of characters after lunch
[12:03] <arigo> then we could wrap it in objspace/std/unicodeobject.py, and objspace/std/stringobject.py, by decomposing and composing W_UnicodeObject around the lists of characters
[12:04] <arigo> or, alternatively, if someone unrelated to PyPy wants (you never know!) unicodes for Python 1.5.2
[12:04] <arigo> then he can define a class UnicodeCharacter and use your module :-)
[12:04] <aleale> Sounds like a plan. Talk to you later
[12:04] <arigo> :-)
[12:05] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "[x]chat"
[12:06] sanxiyn_ (~tinuviel@211.104.100.115) left irc: "Bye"
----- silence for 25 minutes ----- [12:31] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[12:40] mwh2 (~user@modem-27.erendis.dialup.pol.co.uk) joined #pypy.
[12:45] yuuh (wwhuawyk@dsl-62-220-10-27.berlikomm.net) joined #pypy.
[12:50] cfbolz (~cfbolz@edv01.physi.uni-heidelberg.de) joined #pypy.
[12:50] <cfbolz> hi all!
----- silence for 23 minutes ----- [13:13] <aleale> hi
----- silence for 16 minutes ----- [13:29] yuuh (wwhuawyk@dsl-62-220-10-27.berlikomm.net) left irc: Read error: 110 (Connection timed out)
----- silence for 16 minutes ----- [13:45] arigo (~arigo@ratthing-b407.strakt.com) joined #pypy.
[13:47] <cfbolz> hi
[13:51] <arigo> hi!
[13:55] lac (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.
[13:55] <arigo> hi Laura!
[13:59] lac2 (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.
[13:59] <arigo> hi again Laura :-)
[14:05] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[14:06] <ludal> hi
[14:06] <arigo> hi!
[14:06] <cfbolz> hi!
[14:06] <cfbolz> and bye :-)
[14:06] cfbolz (~cfbolz@edv01.physi.uni-heidelberg.de) left irc: "Leaving"
[14:06] <ludal> I had a question on Rpython and modules
[14:07] <ludal> presently I do a getattr(symbol, name) to get the mapping between grammar symbol name and symbol value as defined by the cpython parser
[14:07] <ludal> this could be easily changed to be symbol.__dict__.get(...) and my question is is this enough ?
[14:08] <ludal> note1: symbol is a module
[14:10] <arigo> ludal: where is the symbol module? is that CPython's built-in one?
[14:11] <ludal> yes, but it's a .py module not C
[14:11] <arigo> oh
[14:11] <ludal> I think it's generated at build time
[14:12] <arigo> ok, but symbol.__dict__.get(...) is only better than getattr() if the dict in question is "well-typed"
[14:12] <arigo> which is not the case, as it contains values of various types in addition to the ints you're looking for
[14:12] <ludal> remember that's how we discovered that python on codespeak is a modified version
[14:12] <ludal> ok
[14:12] <arigo> ah, yes
[14:13] <arigo> so you probably need to build a custom dict out of symbol.sym_name, which contains only {'name': integer} entries.
[14:13] <ludal> building it during bootstrapping ?
[14:13] <arigo> yes, at global level.
[14:14] <ludal> I asked this by email but... is __init__.py from module/recparser ok for such things ?
[14:14] mwh2 (~user@modem-27.erendis.dialup.pol.co.uk) left irc: "bye"
[14:14] <arigo> (didn't get to read your e-mail yet)
[14:15] <arigo> but you can put there wherever you like, basically
[14:15] <ludal> no pb
[14:15] <arigo> for example in syntaxtree.py, where it's used
[14:15] <ludal> the question is where to put stuff that needs to be run at bootstrap time
[14:15] <arigo> anywhere global. the modules are fully imported as usual before any compilation is done.
[14:16] <arigo> you can even have bootstrap-time functions; if they are not called after bootstrap, they won't be seen by the translator.
[14:16] <ludal> sorry I don't get it, you need to compile the module to import it
[14:17] <arigo> no, we import it first :-) then we translate (i.e. compile to C) the module directly from what has been loaded in memory
[14:17] <arigo> the translator never reads the Python source code.
[14:17] <ludal> ok get it now
[14:17] <arigo> we're doing veeery strange things at bootstrap time at some places :-)
[14:18] <ludal> I was thinking in the context of executing pypy as a regular interpreter...
[14:19] <arigo> a regular, CPython-like interpreter compiled from C?
[14:20] <arigo> the C is generated by the above trick of "dumping" C code corresponding to code and data in memory, after the whole PyPy has been imported and bootstrapped. (i.e. freezing the state to C)
[14:22] <ludal> ok; I had a fuzzy definition of what bootstrap meant
[14:22] <ludal> ie when does bootstrapping stop?
[14:25] <ludal> so about the visitor used in the code it shouldn't be a problem as, as stated in my mail, it's only used at bootstrap
[14:29] <arigo> (sorry, back)
[14:32] lac2 (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Remote closed the connection
[14:35] <arigo> "bootstrap" can be described as importing everything, and creating an object space
[14:35] <arigo> see for example .../dist/goal/targetpypymain.py
[14:35] <arigo> def target()
[14:36] <arigo> it creates a 'space = StdObjSpace()'
[14:36] <arigo> it does a few extra initialization things
[14:36] <arigo> until it got a reference to a function that basically handles what py.py does.
[14:38] <arigo> at this point, it doesn't actually call the function (doing so would start executing the user program and/or display an interactive prompt)
[14:38] <arigo> this function is what we translate -- and recursively everything that this function calls, which means basically the whole of PyPy, as already loaded in memory and preinitialized.
[14:38] <ludal> ok
[14:39] <arigo> so you can really do a lot of things during this long bootstrap phase. creating classes dynamically etc.
[14:43] <ludal> totally different subject: I see file is still faked, is there a reimplementation yet or ongoing ?
[14:43] <arigo> (now reading your e-mail) similarly, the EBNFParser with the visitor pattern code can really be called at module import time; it will disappear from the C translation because no one calls it later.
[14:44] <ludal> and indeed it is called from recparser/__init__.py
[14:44] <arigo> files: we have our own implementation, but it's rather slow to import at start-up, so not enabled by default
[14:44] <arigo> __init__.py: here again you can call it from anywhere you like.
[14:45] <arigo> any global module-level.
[14:45] <ludal> file: that's what I thought but I couldn't find with a quick look
[14:45] <arigo> py.py --file
[14:45] <arigo> (a flag recently added to enable it from the command line)
[14:45] <arigo> it's in pypy/lib/_file.py
[14:45] <ludal> ok, actually I'll probably move the call somewhere more appropriate
[14:47] <arigo> the basic bootstrapping rule is easy to follow if you consider 'class' statements as, well statements: they are disallowed after bootstrapping. so any place that uses a class statement can also do any other strange things :-)
[14:49] <ludal> my original idea of bootstrapping was 'everything that got executed directly by cpython *before* pypy starts interpreting stuff'
[14:54] <arigo> yes, it's similar. importing the submodules of recparser is done before PyPy starts interpreting user code. (there is some laziness in importing them, actually, but it's only to speed up the start-up of py.py, and the laziness is forced away if needed by the translator)
----- silence for 17 minutes ----- [15:11] yuuh (kxronqxe@dsl-62-220-8-154.berlikomm.net) joined #pypy.
----- silence for 23 minutes ----- [15:34] mwh2 (~user@modem-122.erendis.dialup.pol.co.uk) joined #pypy.
[15:36] mwh2 (~user@modem-122.erendis.dialup.pol.co.uk) left irc: Remote closed the connection
----- silence for 1 hr and 1 minute ----- [16:37] <aleale> hi
[16:37] <arigo> hi
[16:38] <aleale> Is it ok if I make UnicodeDecodeError/UnicodEncodeError/UnicodeTranslateError __init__ methods check their arguments
[16:39] <aleale> test_codeccallbacks.py test for that (thus the tests fails)
[16:39] <arigo> I guess so, yes
[16:40] <arigo> you know that you should not change that in lib/_exceptions.py directly, though? (see pypy-dev messages of the last couple of days)
[16:40] <aleale> That was the next question
[16:41] <arigo> you should ask Christian or see if it's clear how to change it in the tool/...py file, I'm not sure how it's changed
[16:42] <arigo> ask to pypy-dev, I guess
[16:43] <aleale> Ok will do, thanks
----- silence for 29 minutes ----- [17:12] sanxiyn (tinuviel@222.233.187.44) left #pypy ("Bye").
----- silence for 43 minutes ----- [17:55] arigo (~arigo@ratthing-b407.strakt.com) left irc: "[x]chat"
----- silence for 40 minutes ----- [18:35] adim (adim@logilab.net2.nerim.net) left #pypy.
----- silence for 19 minutes ----- [18:54] arre (ac@ratthing-b3fa.strakt.com) left irc: "using sirc version 2.211+KSIRC/1.3.11"
[19:04] arigo (~arigo@ratthing-b407.strakt.com) joined #pypy.
[19:05] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
----- silence for 53 minutes ----- [19:58] cfbolz (~cfbolz@edv01.physi.uni-heidelberg.de) joined #pypy.
[19:58] <cfbolz> hi!
[20:00] <pedronis> hi
[20:01] <arigo> hi!
[20:01] <cfbolz> cool, 87.41%!
[20:01] <pedronis> cfbolz: we broke llvm with changes today
[20:02] <cfbolz> what did you do?
[20:02] <pedronis> we changed how exception handling propagates exception values
[20:02] <pedronis> there are not constants last_exception and last_exc_value anymore
[20:03] <pedronis> but the links out of an exception exitcase
[20:03] <pedronis> introduce variables
[20:03] <pedronis> they are indetified as link.last_exception and link.last_exc_value
[20:03] <cfbolz> identified how?
[20:03] <pedronis> link.last_exception is a new var
[20:04] <cfbolz> ah
[20:04] <pedronis> that corresponds to what last_exception was before
[20:04] <pedronis> same for last_exc_value
[20:04] <pedronis> basically instead of passing constant to the next block
[20:04] <pedronis> the args of the link contain this variables
[20:05] <pedronis> wich are distinguished
[20:05] <pedronis> by being also attached through the last_* attributes of the link
[20:05] <pedronis> normal link have the attributes set to None
[20:05] <pedronis> fixing the other generatos would relatively easy
[20:05] <pedronis> but genllvm is doing quite a lot of things and special casing about exceptions
[20:06] <pedronis> the reason for the change is that
[20:06] <cfbolz> yes, exceptions are a bit hackish in genllvm
[20:06] <pedronis> in some corner cases the old constants could get propagegate at a distant
[20:06] <cfbolz> I'll look into it (though I won't have time for it before friday)
[20:07] <pedronis> that means show up as inputargs of some later block
[20:07] <pedronis> and then it gets hard to attach type to them
[20:07] <pedronis> because the origin is unclear
[20:07] <pedronis> also naively substituing them in the generators may do the wrong thing
[20:08] <pedronis> using variables instead it means that normal progation (not at a distance) happens
[20:08] <pedronis> wich is saner
[20:08] <cfbolz> ok
[20:10] <pedronis> the change was best done as soon as possible because ther more graph transformation we add the better it is if the graph model is sane and stable
[20:10] <pedronis> otherwise we get to change even more places at a later point in the future
[20:11] <cfbolz> makes sense
[20:12] <cfbolz> it doesn't affect genllvm too much since the exception implementation has to be refined anyway
[20:14] <pedronis> yes, I run the tests before doing the change and one that seemed related to exceptions was failing
[20:14] <cfbolz> do you still know which one?
[20:15] <cfbolz> a recent change must have broken that, it worked last week
[20:15] <pedronis> well, Christian has also been working on things and changing stuff
[20:15] <pedronis> so that's possible
[20:16] <cfbolz> ok. I'm a bit short on time at the moment (another exam), so I can't track it all.
[20:16] <pedronis> test_catch_instance
[20:17] <pedronis> was already failing before the changes
[20:17] <cfbolz> thanks.
[20:18] <cfbolz> I'll try to find some time to fix it.
[20:25] <pedronis> cfbolz: FYI, I'm about to check some tweaks such at least tests unrelated to exceptions pass again using some dummy objects for last_exception and last_exc_value
[20:26] <pedronis> that are not there anymore
[20:27] <pedronis> well last_exception is still there but is used only to mark the exitswitch
[20:28] <cfbolz> ah, it fails in some get because it can't find last_exception and last_exc_value anymore
[20:29] <pedronis> ok, I have checked in
[20:29] <cfbolz> thanks
[20:29] <pedronis> failure is a less bit dramatic now
[20:30] <cfbolz> how much is failing (I have no llvm here)?
[20:32] <pedronis> 2 tests
[20:32] <pedronis> now
[20:32] <pedronis> test_catch_instance (which was already failing for different reasons)
[20:32] <pedronis> and
[20:33] <pedronis> test_try_raise_choose
[20:33] <pedronis> as I said fixing the other generatros was not much work as you can see from my checkin
[20:33] <pedronis> but in genllvm exception handling is more spread out
[20:34] <cfbolz> yes. It still needs a lot of tweaking.
----- silence for 19 minutes ----- [20:53] <cfbolz> I have to go. See you!
[20:56] cfbolz (~cfbolz@edv01.physi.uni-heidelberg.de) left irc: "Leaving"
----- silence for 57 minutes ----- [21:53] aleale (~root@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) left irc: "Eject! Eject! Eject!"
[22:06] arigo (~arigo@ratthing-b407.strakt.com) left irc: Remote closed the connection
[22:08] pedronis (pedronis@ratthing-b246.strakt.com) left irc: Remote closed the connection
----- silence for 16 minutes ----- [22:24] ericvrp (~a@ericvrp.demon.nl) joined #pypy.
[22:27] ericvrp (~a@ericvrp.demon.nl) left irc:
----- silence for 44 minutes ----- [23:11] aleale (~chatzilla@0x535ca5a5.hrnxx9.adsl-dhcp.tele.dk) joined #pypy.
----- silence for 38 minutes ----- [23:49] aleale (~chatzilla@0x535ca5a5.hrnxx9.adsl-dhcp.tele.dk) left irc: "Chatzilla 0.9.68a [Firefox 1.0.3/20050414]"
[00:00] --- Tue May 10 2005