[00:36] pedronis (~Samuele_P@c-3c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050317]"
----- silence for 3 hr and 5 minutes ----- [03:41] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 60 (Operation timed out)
----- silence for 3 hr and 33 minutes ----- [07:14] idnar (mithrandi@idnar.user) left irc: Read error: 110 (Connection timed out)
----- silence for 41 minutes ----- [07:55] sanxiyn (~tinuviel@211.104.100.115) joined #pypy.
[07:55] Gerald (~bear@dialin-212-144-180-010.arcor-ip.net) joined #pypy.
[07:56] Nick change: Gerald -> Gromit_
[07:57] Nick change: Gromit_ -> Gromit
----- silence for 49 minutes ----- [08:46] sanxiyn (~tinuviel@211.104.100.115) left irc: "Bye"
----- silence for 40 minutes ----- [09:26] idnar (mithy@idnar.user) joined #pypy.
----- silence for 58 minutes ----- [10:24] arigo (~arigo@stups.cs.uni-duesseldorf.de) joined #pypy.
----- silence for 28 minutes ----- [10:52] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
----- silence for 27 minutes ----- [11:19] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
----- silence for 45 minutes ----- [12:04] Gromit (~bear@dialin-212-144-180-010.arcor-ip.net) left irc: Read error: 110 (Connection timed out)
[12:18] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 1 hr and 7 minutes ----- [13:25] aadi (~aditya@202.153.40.2) joined #pypy.
[13:25] aadi (aditya@202.153.40.2) left #pypy.
----- silence for 1 hr and 3 minutes ----- [14:28] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
----- silence for 44 minutes ----- [15:12] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[15:14] <pedronis> arigo: hi
[15:15] <arigo> hi
[15:15] <cfbolz> hi
[15:15] <pedronis> I'm looking at my idea of producing a set of small snippets showing how we expect arithmetic to work
[15:15] <arigo> ok
[15:16] <pedronis> I'm looking at test_ctrans.test_int_overflow
[15:16] <pedronis> that code will not overflow if not translated
[15:17] arre (ac@ratthing-b3fa.strakt.com) left irc: "using sirc version 2.211+KSIRC/1.3.11"
[15:17] <arigo> yes, well, that test is more an internal test for genc
[15:17] <arigo> the input argument is a long that is too long
[15:18] <pedronis> I see
[15:18] <pedronis> what is expected if we pass just sys.maxint
[15:19] <arigo> that's a more interesting question
[15:19] <pedronis> yes
[15:19] <arigo> i don't know
[15:19] <pedronis> we know that we expect:
[15:19] <pedronis> def f(n):
[15:20] <pedronis> n = r_int(n)
[15:20] <pedronis> try:
[15:20] <pedronis> n+r_int(1)
[15:20] <pedronis> except OverflowError:
[15:20] <pedronis> return 'overflow'
[15:20] <pedronis> return 'overflow' # indented
[15:21] <pedronis> to return 'overflow'
[15:21] <pedronis> both with translation and without
[15:21] <arigo> yes
[15:23] <pedronis> it is sane that unguarded operation and operations not r_int, should not overflow or the behavior is undefined
[15:23] <pedronis> not using
[15:24] <arigo> it's at least what we had in mind -- now is it sane?
[15:25] <pedronis> yes
[15:26] <arigo> ok :-)
[15:26] <pedronis> I mean, yes, it's what we had in mind
[15:26] <arigo> aaaah
[15:27] <arigo> anyway, what about unsigned integer arithmetic?
[15:28] <pedronis> well, the issue is not only what is sane but what we can make work similarly before and after translation
[15:28] <arigo> ok
[15:31] <pedronis> for example, what about the new hash_String
[15:32] <arigo> ok we can be more precise then
[15:32] <pedronis> it is assuming that with masking you can do overflow-free signed arithmetic wich is ok
[15:32] <pedronis> unless you mix r_int in the mix
[15:33] <pedronis> wich would make things explode
[15:33] <arigo> yes, we can say that unguarded arithmetic guarantees that the last int-sized bits are correct
[15:33] <arigo> we can't use r_int here,
[15:33] <arigo> if we wanted to use something it would be an explicitely wrap-around class
[15:34] <pedronis> I know but are we sure that r_int will not propagate in strange ways and bite us
[15:34] <arigo> hum, the question is about the r_int semantics after translation
[15:35] <pedronis> well, it's a question also about them before
[15:35] <pedronis> translation
[15:35] <arigo> are r_int operations guaranteed to throw OverflowErrors, or do they have to be guarded just like int operations?
[15:35] <pedronis> ideally they would have to be guarded but it is hard to get that behavior before translation
[15:35] <arigo> for before translation, it's easier: just make sure your code is sane, and test it thouroughly
[15:36] <pedronis> that's a possible approach, but we need to be more careful that we have been so far
[15:37] <pedronis> that's means r_int means signed and is basically erased at translation
[15:37] <arigo> yes
[15:38] <arigo> I agree it's a bit difficult to have a behavior that is exactly the same before and after translatiotn
[15:38] <pedronis> yes, but having fragments that show what to expect should be useful
[15:39] <arigo> we "might" consider hacking around the warnings module
[15:39] <arigo> to throw a real OverflowError if we see in sys._getframe() that there is a handler... hum.
[15:39] <pedronis> the there's an handler is possible but not trivial
[15:39] <arigo> I know, I'm more wondering if it's sane or not
[15:40] <pedronis> well, if we have this difference it just means that we have to be careful
[15:40] <pedronis> especially not to propaget r_int around without knowing
[15:41] <arigo> alternatively, we could use some more explicit code
[15:42] <arigo> e.g. instead of try: z=x+y except OverflowError:
[15:42] <arigo> use z=x+y; if overflowed(z):
[15:42] <arigo> with overflowed = lambda x: isinstance(x, long)
[15:43] <arigo> or some intermediate solution like
[15:43] <arigo> try: z=overflowing(x+y) except OverflowError:
[15:43] <pedronis> yes
[15:44] <pedronis> it would help getting similar behavior before and after translation
[15:44] <arigo> definitely
[15:44] <pedronis> so we would not need r_int anymore
[15:45] <pedronis> but use that or masking
[15:45] <pedronis> depending on what we want
[15:45] <arigo> yes
[15:45] <pedronis> Ok
[15:45] <pedronis> what about unsigned arithmetic
[15:45] <arigo> what about unsigned arithmetic
[15:46] <pedronis> :)
[15:47] <arigo> we could try to do the same and get rid of r_uint
[15:47] <arigo> I don't think we need overflow detection in this case
[15:47] <arigo> only masking.
[15:47] <arigo> that's what r_uint is doing, at least.
[15:48] <pedronis> yes
[15:48] <pedronis> but what should be a marker for unsigned number
[15:48] <pedronis> long?
[15:48] <arigo> hum
[15:49] <arigo> if we translate to C, it doesn't matter, but in general it does matter
[15:50] <arigo> well no, even in C it's unclear
[15:50] <pedronis> yes, it probably matters also were have to do conversions
[15:51] <arigo> maybe we keep r_uint then
[15:52] <pedronis> given that a signed "overflowing" operation would give a long, it seems we cannot just use that
[15:52] <pedronis> so yes, it seems we need some other marker
[15:54] <arigo> so we have to be careful that r_uint doesn't propagate too much
[15:54] <arigo> but that's ok
[15:55] <pedronis> is less of an issue because it does not raise exceptions
[15:55] <pedronis> but indeed what should signed+unsigned do
[15:55] <arigo> -> unsigned
[15:55] <arigo> r_uint is a marker that should propagate, I think
[15:56] <pedronis> ok
[15:57] <arigo> it would be nice if int(r_uint(-1)) == -1
[15:58] <pedronis> yes
[15:59] <pedronis> I see that the annotator already has unsigned = unsigned1 or unsigned2
[15:59] <arigo> yes.
[16:00] <arigo> I just wrote a def __int__() for class r_uint, it seems to be called when we do int(r_uint(-1))
[16:00] <arigo> so we can officialize this behavior both before and after translation
[16:01] <pedronis> yes
[16:03] <arigo> ok so we get rid of r_int and replace it with a pair of functions:
[16:03] <arigo> intmask(n) (already there)
[16:03] <arigo> ovfchecking(n) ?
[16:03] <pedronis> yes
[16:04] <pedronis> I would go for the throwing exception route
[16:04] <arigo> def ovfchecking(n):
[16:05] <arigo> n = int(n)
[16:05] <arigo> if isinstance(n, long):
[16:05] <arigo> raise OverflowError, "you loose"
[16:05] <arigo> return n
[16:05] <pedronis> yes
[16:05] <arigo> IOW exactly the previous behavior of int()
[16:05] <pedronis> what about an unexpected ovfnchecking of a r_uint
[16:06] <arigo> er
[16:06] <arigo> AssertionError?
[16:06] <pedronis> I think so
[16:06] <arigo> intmask() should work, though, ok?
[16:06] <pedronis> yes
[16:07] <arigo> it's even cleaner than doing int() to get back an int from a r_uint
[16:08] <arigo> I'd even say that using int() is confusing, given that the numeric value might change on CPython
[16:08] <pedronis> yes
[16:09] <arigo> we (= I) should write a few lines to pypy-dev before we do that, as Christian is not reading right now :-)
[16:09] <arigo> it's also a good habit to write a few lines after IRC discussions in general
[16:10] <pedronis> ok
[16:25] <arigo> wait a minute
[16:26] <arigo> should ovfchecked(x+y) only be used directly within an OverflowError handled?
[16:26] <arigo> handler?
[16:26] <pedronis> probably yes
[16:27] <arigo> would it be a no-op for the translator, then?
[16:27] <pedronis> basically yes, but the translator could check the graphs to see that the rule is respected
[16:28] <arigo> my concern is if the try: except OverflowError also contains another arithmetic operation by error
[16:29] <pedronis> it will not be protected?
[16:29] <pedronis> but we have the same issue now
[16:29] <arigo> well, yes
[16:30] <arigo> the safest solution would be to have the rule that only ovfchecked itself can raise OverflowError,
[16:30] <arigo> and that it should be syntactically ovfchecked(x <op> y)
[16:30] <arigo> i.e. protect exactly one operation
[16:30] <pedronis> well that the pattern I had in minde
[16:30] <pedronis> but can we check that it is respected?
[16:30] <arigo> if we enforce this as a rule, we don't need to use implicit exceptions in the flow graph
[16:31] <arigo> it's probably easy to check it, yes
[16:31] <pedronis> in the flow graph?
[16:31] <arigo> yes, look at the block operations, simple_call(ovfchecked, z) should always follow "z = <op>(x,y)"
[16:32] <pedronis> yes but if you had more operations inside the call?
[16:32] <arigo> I thought about enforcing ovfchecked(variable op variable)
[16:33] <arigo> a bit of a hack, but more convenient than a family of functions ovf_add() ovf_sub() etc.
[16:34] <arigo> er, actually, no
[16:34] <arigo> ovfchecked(expr op expr) would also work
[16:34] <pedronis> yes, that was my point
[16:34] <arigo> because it would end in "z=op(x,y)" "simple_call(ovfchecked, z)"
[16:34] <arigo> that's fine, then
[16:35] <arigo> it's meant to check only that operation, not the other ones
[16:35] <arigo> ah I see your point: ovfchecked(x+y+z) would not do the same thing before and after translation
[16:35] <pedronis> but is the overflow flag preserved
[16:36] <pedronis> yes, in the graph you don't see what expression the call was really guarding
[16:36] <pedronis> unless you look at the names of variables (very hackish)
[16:36] <arigo> ok
[16:38] <arigo> the name ovfchecked() is misleading
[16:38] <arigo> it should be int_or_crash(x) or something
[16:39] <arigo> well the point is that ovfchecked(x+y+z) still behaves differently before and after translation
[16:40] <pedronis> yes
[16:40] <arigo> before translation it checks that the result is within bounds
[16:40] <arigo> after translation you can get an OverflowError for the intermediate result
[16:41] <arigo> ovf(operator.add, x, y)
[16:41] <arigo> ?
[16:41] <pedronis> well, we still want to write more or less natural code
[16:42] <hpk> ovf("x+y") :-)
[16:42] <arigo> hpk: go away :-)
[16:43] <arigo> ovf+(x,y)
[16:43] <arigo> hack hack hack
[16:43] <pedronis> yes, there a way to preserve where a try block starts into the graph
[16:44] <hpk> well, regarding hacks one could do:
[16:44] <pedronis> oops, isn't there a way ...
[16:44] <hpk> ovf(x+y)
[16:44] <hpk> and apply py.test assertion tricks while running on PyPy and doing nothing for translation
[16:44] <hpk> (sorry, running on Python i meant)
[16:45] <arigo> hpk: actually on Python just checking if the result is a long is enough
[16:45] <arigo> pedronis: for our goal, what about
[16:45] <arigo> z = x+y
[16:45] <arigo> if ovf(z): ...
[16:46] <arigo> it's more natural to ask "what operation is that enclosing then"
[16:46] <arigo> and find the answer "the last one" in the doc
[16:46] <arigo> rather than writing ovf(x+y+z) and having surprizes
[16:47] <pedronis> but our try except are all about only the last operation after translation?
[16:47] <arigo> yes
[16:47] <arigo> I think so
[16:47] <pedronis> so it's a general problem
[16:47] <arigo> they are mainly in intobject.py, no?
[16:47] <pedronis> yes
[16:47] <pedronis> but what about
[16:47] <pedronis> try:
[16:47] <pedronis> f()
[16:47] <pedronis> g()
[16:47] <pedronis> except ...:
[16:49] <pedronis> I think we are assuming a model where we can know that there was an exception
[16:49] <pedronis> but many translato will only guard the g call?
[16:49] <arigo> no
[16:50] <arigo> the abstract interpretation approach forces us to raise exceptions around just in case, while flow-objspace-ing
[16:50] <arigo> but all simple_call operations do that
[16:50] <pedronis> I see, I'm having one of those, confused by moving parts moments
[16:51] <arigo> it's always been this way about that, but I see what you mean :-)
[16:53] Action: hpk pokes arigo to write some documentation about exceptions handling for flow/annotation/backends
[16:54] <arigo> this point is actually documented in controlflow.txt
[16:54] <arigo> but not the full story, I agree
[16:54] <pedronis> I see
[16:55] <pedronis> try:
[16:55] <pedronis> x+y
[16:55] <pedronis> x+z
[16:55] <pedronis> except OverflowError:
[16:55] <pedronis> ...
[16:55] <pedronis> produces something sensible
[16:55] <arigo> yes
[16:55] <pedronis> the problem is making it behave the same way before and after translation
[16:55] <arigo> precisely
[16:56] <arigo> we can say that the above code snippet is no longer valid Python code,
[16:56] <arigo> given that OverflowError shouldn't be generated any more,
[16:56] <arigo> and then really use something else than exceptions for overflow detection
[16:57] <pedronis> yes
[16:58] <arigo> in this case, the sensible way to write it is
[16:58] <arigo> z = x+y
[16:58] <arigo> if ovf(z):
[16:58] <arigo> or if you prefer
[16:58] <arigo> try:
[16:59] <arigo> z = x+y
[16:59] <arigo> check(z)
[16:59] <arigo> except OverflowError:
[16:59] <pedronis> but is harder to translate
[16:59] <arigo> no, that's easy
[17:00] <pedronis> you ignore the check and use ther curent semantics?
[17:00] <arigo> we should probably even write something like
[17:00] <arigo> z = x+y; check(z)
[17:00] <arigo> and say that check() only guarantees checking the last operation
[17:00] <hpk> would be nice if we could say: z=x+y ; check()
[17:00] <hpk> to make it more obvious
[17:00] <arigo> no, the check() can raise OverflowError, but the x+y doesn't raise implicitely
[17:01] <arigo> hpk: :-)
[17:01] <hpk> i's a bit like checking the overflow bit on some machine register
[17:01] <arigo> how do you make it reasonably work on CPython?
[17:01] <pedronis> well, it's easy to translate if you have an overflow flag, no?
[17:02] <pedronis> but not without
[17:02] <arigo> no:
[17:02] <arigo> the block operations will be exactly z = op(x,y); simple_call(check, z)
[17:02] <arigo> or in the hpk proposal
[17:02] <arigo> the block operations will be exactly z = op(x,y); simple_call(check)
[17:03] <arigo> you can figure this out and replace it with a single operation, z = ovf_add(x,y) for example
[17:03] <pedronis> I see
[17:04] <pedronis> but thinking you can check for ovf(x+y+z)
[17:04] <arigo> that's why check() with no arg would be better (even if more magic)
[17:05] <hpk> hum, i think that doing: z = ovfchecked(x+y)
[17:05] <pedronis> but is more complicated
[17:05] <hpk> should be able to check that it's argument came from a reasonable simple operation
[17:05] <hpk> and for translation it can be easily special cased
[17:05] <arigo> hpk: do you have an inspect.getsource() hack in mind?
[17:05] <pedronis> we thought that we cannot distinguish ovf(x+y+z) from z1 = y+z; ovf(y+z1)
[17:06] <hpk> arigo: yes, nothing too hard, it shoudl fit on one screen
[17:06] <arigo> :-)
[17:06] <arigo> I'm fine with that, I guess :-)
[17:07] <hpk> no at python runtime, ovfchecked would indeed get the caller frame, get the source, find the argument, parse it to an AST and do some assertions
[17:07] <hpk> (that was to samuele)
[17:07] <arigo> or simply say that the line must match a basic re
[17:07] <hpk> i am doing similar things with rlcompleter2 :-)
[17:08] <arigo> ident = ovfchecked(ident op ident)
[17:08] <hpk> well, what about "ovfchecked(f(....x+y+z))" ?
[17:08] <arigo> no no
[17:08] <arigo> because it's ambiguous then, if the + inside are also ovfchecked or not
[17:08] <pedronis> hpk: no, is not that we want to support those
[17:08] <pedronis> but we want a way to be sure they are not used
[17:08] <hpk> ah ok, well, whatever, there should be a resonable sane nicely-testable solution
[17:08] <arigo> I guess so
[17:09] <hpk> it's not that everybody tries hard all the time to abuse ovfchecked
[17:09] <arigo> it's probably enough to check that wherever "ovfchecked(" appears, it's followed by "ident op ident)"
[17:10] <arigo> hpk: maybe it could lead to hard-to-debug surprizes later
[17:10] <hpk> yes, ident op ident sounds reasonable
[17:10] <arigo> use the tokenizer, maybe (inspect.py uses it too for similar things)
[17:11] <pedronis> but in this model + alone would not generate an implicit OverflowError anymore, right?
[17:12] <hpk> right
[17:12] <pedronis> only the combination + & check
[17:12] <hpk> do you fear proliferation of ovfchecks everywhere?
[17:12] <arigo> pedronis: yes.
[17:13] <arigo> hpk: I don't think that's a problem indeed
[17:13] <pedronis> no, just trying to be on the same page
[17:13] <pedronis> I'm just thinking that we could keep the old model because once there's a try we could distringuish the various cases we don't want
[17:14] <pedronis> but it is indeed more complicated
[17:15] <hpk> i like the new model much more, i think
[17:15] <arigo> it's more explicit
[17:16] <hpk> and it is easier to see how it relates to translation, actually
[17:17] <pedronis> well, it matches better the fact that now CPython does not raise OverflowExceptions anymore
[17:17] <arigo> yes
[17:19] <arigo> last question
[17:19] <arigo> space.uint_w() ?
[17:20] <pedronis> it would return a r_uint
[17:20] <arigo> would that be a new space operation that we need?
[17:20] <pedronis> I think so
[17:20] <pedronis> has CPython something like that?
[17:21] <arigo> yes, it has tons of stuff
[17:21] <arigo> also returning long long, unsigned long long, etc.
[17:21] <pedronis> the ParseArg string specifier etc
[17:21] <hpk> hey, that would probably resolve the 're' related unsingned int issues nicely
[17:22] <arigo> yes, that's what I have in mind
[17:22] <pedronis> yup
[17:22] <pedronis> well, what should it do with an int
[17:23] <arigo> couldn't we have a more generic way to get a look at the content of a long
[17:24] <pedronis> ?
[17:24] <arigo> space.integral_numeric_value_w()
[17:24] <arigo> returns a sign and a list of r_uint, or something like that
[17:25] <pedronis> I see a canonical form
[17:25] <arigo> yes
[17:25] <arigo> or else
[17:25] <arigo> space.peek_at_integer_w(w_obj, offset) -> int
[17:26] <arigo> or rather -> r_uint
[17:26] <arigo> I guess we can do the same with a combination of space.rshift() and space.and_() and space.int_w()
[17:27] <pedronis> yes, but such an interface is useful too
[17:27] <pedronis> do you propose to have that and no uint_w?
[17:27] <pedronis> or both?
[17:27] <arigo> only that, but then maybe uint_w() can be added in BaseObjSpace generically
[17:28] <pedronis> is uint_w on an int meaningful?
[17:28] <arigo> only if it is >= 0
[17:29] <pedronis> ok
[17:29] <arigo> I think
[17:29] <arigo> yes
[17:30] <pedronis> well, I expect all of this to become more concretely relevant when you interface with C libraries
[17:30] <arigo> yes
[17:30] <arigo> ...let's do the primitive uint_w for now
[17:30] <arigo> easily changed
[17:30] <pedronis> yep
[17:34] <arigo> ...there is a Complex.py somewhere in CPython?
[17:35] <arigo> Demo/classes/Complex.py, indeed.
[17:41] <cfbolz> hi! I'm trying to get somewhere with targetpypy1. What are all those SomeImpossibleValue(benign=False) attributes of W_Root? Can I ignore these?
[17:42] <arigo> impossible attributes :-)
[17:42] <arigo> yes they should be ignored
[17:42] <cfbolz> good.
[17:43] <arigo> they are methods, actually :-(
[17:44] <cfbolz> yes, I saw that.
[17:44] <arigo> but never called in targetpypy1
[17:44] <cfbolz> ah
[17:44] <arigo> I'm a bit afraid about the full targetpypy, where the methods will be all needed
[17:44] <cfbolz> why?
[17:44] <arigo> it's the multimethod dispatch mecanism
[17:45] <arigo> it creates (and needs) lots of methods
[17:45] <cfbolz> I haven't looked into that, yet.
[17:46] <cfbolz> the implementation of multimethods, I mean.
[17:47] <cfbolz> the rest of targetpypy1 seems actually doable with a few hacks. There are relatively few SomeObjects
[17:47] <cfbolz> in llvm I mean
[17:49] <pedronis> len(dir(W_StringObject)) ~ 560
[17:49] <cfbolz> ouch. and most of it are methods?
[17:49] <pedronis> well, yes, but it could be worse
[17:50] <cfbolz> right. Any ideas what I could do about longs?
[17:51] <cfbolz> I guess I could just use ints for now and hope that the result always fits.
[17:51] <pedronis> dir considers all parent classes, some Gui toolkits, I think, are also in the hundreds of methods
[17:52] <hpk> zope2 has >1000 methods on some of its objects
[17:52] <cfbolz> yes, but they don't want to translate it :-)
[17:53] <hpk> who knows
[17:53] <hpk> :-)
[17:53] <cfbolz> Some c++ frameworks are even more horrible.
[17:55] <pedronis> as I said, it's still not totally unreasonable
[17:56] <cfbolz> I didn't say so :-)
[18:01] <arigo> :-)
[18:03] <cfbolz> ouch. my long substitute has to support type, right?
[18:03] <cfbolz> i mean the function type of course
[18:05] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[18:05] <pedronis> well it somehow a bug if we have code that tries uses type unless it is can be statically inferred or is about some of our own classes
[18:07] <pedronis> OTOH I'm pretty sure we have code like that
[18:07] <cfbolz> yes, but long using long *is* kind of a bug anyway, isn't it?
[18:07] <cfbolz> long --> code
[18:07] CLI (opera@86.125.128.38) joined #pypy.
[18:07] <CLI> This is the Batroom?
[18:08] <pedronis> yes long using long is cheating
[18:08] <arigo> CLI: I guess not
[18:08] <pedronis> and wrap(SomeObject) has that problem too
[18:09] <CLI> Why not? is called pypy
[18:09] <pedronis> that means the places where wrap cannot be specialized for a precise type
[18:09] <cfbolz> pedronis: so someone has to write a long subsitute in Python at some point?
[18:09] <pedronis> yes
[18:10] <cfbolz> using lists of ints or something like that
[18:10] CLI (opera@86.125.128.38) left irc: Read error: 54 (Connection reset by peer)
[18:18] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Read error: 113 (No route to host)
[18:20] <cfbolz> ok, I'm going home now. See you
[18:20] <arigo> see you
[18:22] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[18:24] <pedronis> arigo: is it up to the typer do detect the op ovfchecked pattern? erasing it is not that meanigful with PyObjects around
[18:26] <arigo> probably
[18:26] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
[18:38] <pedronis> arigo: after removing the lines that setup OverflowError as an implicit exception, all tests still pass
[18:38] <arigo> meaning that no test checked that
[18:39] <pedronis> yes
[18:39] <pedronis> but also that nothing depends on that so far
[18:39] <arigo> I see
[18:40] <pedronis> well, I don't know about llvm stuff
[18:40] <pedronis> anyway we need new tests about the behaviors we want in any case
[18:41] <arigo> indeed
[18:42] <arigo> did I mention everything in the mail to pypy-dev?
[18:42] <pedronis> I think so
[18:42] <arigo> should be a good base for tests
[18:42] <pedronis> yes
[18:44] <pedronis> btw should we move restricted_int outside of std?
[18:44] <arigo> I think so
[18:45] <pedronis> maybe rename it rarith or something like that?
[18:45] <pedronis> that's not so important
[18:45] <arigo> maybe but it took me time to parse 'rarith' :-)
[18:46] <pedronis> :)
[18:46] <pedronis> to tool?
[18:46] <arigo> ok
[18:47] <pedronis> although I notice that tool is a bit of a mess
[18:47] <pedronis> (umph)
[18:47] <arigo> :-)
[18:48] <pedronis> at some point we need to clean up there
[18:48] <pedronis> and maybe hava a util vs tool directory
[18:49] <pedronis> the other place would be interpreter
[18:50] <arigo> argh
[18:50] <pedronis> what's up?
[18:50] <arigo> there should be a place for top-level scripts like py.py
[18:50] <arigo> "argh" was about stuffing rarith into interpreter
[18:51] <pedronis> well, that was just the other option
[18:51] <pedronis> sofar things like it are in tool
[18:51] <pedronis> but tool is a bit of a mess becaue there are tools (some broken) there
[18:51] <pedronis> and utility libraries
[18:52] <arigo> yes
[18:52] <arigo> tool vs util would be nice
[18:52] <pedronis> yes
[19:01] idnar (mithy@idnar.user) left irc: Nick collision from services.
[19:01] idnar_ (mithrandi@idnar.user) joined #pypy.
[19:01] idnar (mithy@idnar.user) joined #pypy.
----- silence for 42 minutes ----- [19:43] Gromit (~bear@dialin-212-144-177-093.arcor-ip.net) joined #pypy.
[19:44] idnar (mithy@idnar.user) left irc: Nick collision from services.
[19:44] idnar (mithy@idnar.user) joined #pypy.
[19:44] idnar (mithy@idnar.user) left irc: Nick collision from services.
[19:54] Nick change: idnar_ -> idnar
----- silence for 35 minutes ----- [20:29] Gromit (~bear@dialin-212-144-177-093.arcor-ip.net) left irc: "Client Exiting"
----- silence for 1 hr and 7 minutes ----- [21:36] Action: pedronis leaving
[21:40] pedronis (pedronis@ratthing-b246.strakt.com) left irc: Remote closed the connection
----- silence for 49 minutes ----- [22:29] pedronis (~Samuele_P@c-0c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 41 minutes ----- [23:10] <arigo> pedronis: the tests look good
[23:10] <pedronis> ok
[23:11] <pedronis> we may want to extract them also as functions such that we can reuse them
[23:11] <pedronis> to check translation
[23:11] <arigo> I see
----- silence for 29 minutes ----- [23:40] _hannes (hxptid@i528C1099.versanet.de) joined #pypy.
[23:41] Nick change: dialtone -> papa
[23:42] Nick change: papa -> pope
[23:42] Nick change: pope -> dialtone
[00:00] --- Sat Apr 9 2005