[00:29] stakkars (axohrwv@i528C131C.versanet.de) joined #pypy.
[00:33] <stakkars> pedronis: you fixed it? great!
[00:39] <stakkars> remaining problem:
[00:39] <stakkars> flow space's assumptions about sys attributes are just wrong.
[00:40] _hannes (egkyfz@i528C131C.versanet.de) left irc: Read error: 104 (Connection reset by peer)
[00:40] <stakkars> we need to make sure that almost all sys attributes are evaluated late!
[00:40] <stakkars> other problem:
[00:40] <stakkars> for some reason, targetpypy1 does no longer translate.
[00:41] <stakkars> OP_ABS is undefined.
[00:41] <stakkars> I will try to fix this.
----- silence for 22 minutes ----- [01:03] stakkars (axohrwv@i528C131C.versanet.de) left irc:
[01:08] stakkars (ubjbrrbq@i528C131C.versanet.de) joined #pypy.
[01:14] stakkars (ubjbrrbq@i528C131C.versanet.de) left irc: Read error: 131 (Connection reset by peer)
[01:18] stakkars (gxuifx@i528C131C.versanet.de) joined #pypy.
----- silence for 17 minutes ----- [01:35] <stakkars> translate_pypy.py targetpypy1 -text -no-a
[01:35] <stakkars> XXXdoes notwork!!!
[01:36] <stakkars> weend up withsome funny docstringthatcauses
[01:36] <stakkars> AttributeError: 'NoneType' object has no attribute 'lstrip'
[01:36] <stakkars> translate_pypy.py targetpypy1 -text
[01:37] <stakkars> does not work, too. It compiles,but then:
[01:38] <stakkars> Running!
[01:38] <stakkars>
[01:38] <stakkars> Traceback (most recent call last):
[01:38] <stakkars> File "D:\pypy\dist\goal\translate_pypy.py", line 403, in ?
[01:38] <stakkars> targetspec_dic['run'](c_entry_point)
[01:38] <stakkars> File "targetpypy1.py", line 42, in run
[01:38] <stakkars> w_result = c_entry_point()
[01:38] <stakkars> NotImplementedError
[01:38] <stakkars>
[01:38] Last message repeated 1 time(s).
[01:38] <stakkars> > d:\pypy\dist\goal\targetpypy1.py(42)run()
[01:38] <stakkars> -> w_result = c_entry_point()
[01:39] <stakkars> SO! What is that? Should we needtoaddsome tests to goal?
[01:40] <stakkars> how can I test rpystrone,if the basic goal things don't work any longer?
[01:52] wert (~zape@a84-231-97-24.elisa-laajakaista.fi) joined #pypy.
[01:53] wert (zape@a84-231-97-24.elisa-laajakaista.fi) left #pypy.
----- silence for 19 minutes ----- [02:12] <stakkars> hi all, we really need to talk.
[02:12] <stakkars> I think the project is endangered, a bit.
[02:13] <stakkars> We need to make sure that the current goals are always working.
[02:13] <stakkars> And we need to concentrate more people to the next milestone.
[02:14] <stakkars> It is not cleartome, despite of some people of course, who is working on what,
[02:14] <stakkars> and I'm not sure if some participants are working atall,right now.
[02:15] <stakkars> I believe that we need to activate everybody, or we will get into trouble.
[02:15] <stakkars> off for tonite -- chris
[02:15] stakkars (gxuifx@i528C131C.versanet.de) left irc: "'utz"
----- silence for 7 hr and 17 minutes ----- [09:32] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
----- silence for 1 hr ----- [10:32] Gromit (~bear@dialin-212-144-183-088.arcor-ip.net) joined #pypy.
[10:43] arigo (~arigo@stups.cs.uni-duesseldorf.de) joined #pypy.
----- silence for 24 minutes ----- [11:07] Gromit (~bear@dialin-212-144-183-088.arcor-ip.net) left irc: Read error: 110 (Connection timed out)
----- silence for 25 minutes ----- [11:32] Gromit (~bear@B74de.b.pppool.de) joined #pypy.
----- silence for 27 minutes ----- [11:59] Arafat (~bear@213.7.116.196) joined #pypy.
[11:59] Nick change: Arafat -> Gromit_
[12:01] Gromit (~bear@B74de.b.pppool.de) left irc: Nick collision from services.
[12:01] Nick change: Gromit_ -> Gromit
[12:06] Me2 (~Me@cm218-253-45-243.hkcable.com.hk) joined #pypy.
----- silence for 44 minutes ----- [12:50] <hpk> arigo: may i ask a question on #pylib again? :-)
[13:05] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[13:08] <cfbolz> Hi all!
[13:20] <hpk> hi carl
[13:21] Gromit (~bear@213.7.116.196) left irc: Read error: 110 (Connection timed out)
[13:22] jacob22|office (jacob@enzo.strakt.com) left irc: Connection timed out
[13:25] <cfbolz> I nearly managed to compile rpystone yesterday
[13:26] <cfbolz> :-)
[13:26] <cfbolz> the only thing that is missing is an implementation of string comparisons and time.clock. The rest works.
[13:30] tea (~tea@cap002-249.kcn.ne.jp) joined #pypy.
[13:33] stakkars (~tismer@82.144.60.19) joined #pypy.
[13:33] <arigo> hi!
[13:34] <stakkars> hi!
[13:34] <cfbolz> hi!
[13:35] <stakkars> last nite, I tried to compilerpystone. Well, I didn't because before I wanted to run targetpypy1
[13:35] <stakkars> but it doesn't work, neither with or without -no-a
[13:36] <cfbolz> I nearly managed to compile rpystone. I'm still missing an implementation of string comparison and time.clock.
[13:36] <stakkars> something must have changed. With annotation, I get some NonImplementedError
[13:36] <stakkars> cfbolz: whow!
[13:36] <cfbolz> and I had to replace the for loops with whiles, which should be ok.
[13:36] <stakkars> you changed rpystone.py?
[13:37] <cfbolz> didn't check it in.
[13:37] <cfbolz> I just wanted to see whether I got it to run. but at four in the morning I gave up >/)
[13:37] <cfbolz> :-)
[13:37] <stakkars> how comes? is iteration not implemented, yet?
[13:38] <stakkars> ok, same here, 4:00 and no result.
[13:38] <stakkars> I think there is a problem with annotation.
[13:38] <arigo> stakkars: apparently targetpypy1 works again now (odie checked a few missing OP_XXX)
[13:39] <stakkars> and OP_ABS was not implemented in genc's include files.
[13:39] <stakkars> ah, fine.
[13:39] <cfbolz> stakkars: right, iteration doesn't work yet -- I finished exceptions only last weekend and had no time do to iterators
[13:39] <stakkars> I see.
[13:39] <stakkars> ok, I'll svn up and try again.
[13:41] <arigo> as I said in pypy-dev I'm now going to look systematically for operations missing in the .h.
[13:41] <stakkars> I just wondered how something could be missing, because I thought we have tests for genc.
[13:43] <cfbolz> my impression from genllvm is that test are not really systematic, since most of the time only the things in snippets are tested, which is a rather loose collection of code.
[13:44] <stakkars> we should add tests for the things mentioned in goal
[13:45] <arigo> stakkars: please read my mail :-) I explain wyh suddenly there were new missing things.
[13:46] <stakkars> sorry ;;)
[13:49] jacob22|office (jacob@enzo.strakt.com) joined #pypy.
[13:50] <stakkars> ahaaaaaa!
[13:51] <cfbolz> ?
[13:52] <stakkars> arigo: yes, I understand. But targetpypy1 still doesn't work for me
[13:52] <stakkars> let me see why I still get Unimplemented:
[13:53] Action: cfbolz runs of to the next lecture
[13:53] <cfbolz> bye!
[13:54] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[13:56] <stakkars> arigo: one thing that I had tonight and still have is this:
[13:56] <stakkars> gskippedfunc_ovfcheck
[13:57] <stakkars> as I understood it, this ovfcheck function should not be needed if the generated code is correct?
[13:57] <stakkars> all in all, I have the following skipped things:
[13:57] <stakkars> gskippedfunc_ovfcheck
[13:57] <stakkars> gskippedfunc_fake_type
[13:58] <stakkars> gskippedfunc_buildtypeobject
[13:58] <arigo> we need to do something about the skipped ovfcheck
[13:59] <arigo> the problem is that code like
[13:59] <arigo> ovfcheck(a+b)
[13:59] <arigo> if not typed, will be translated to
[13:59] <arigo> PyNumber_Add()
[13:59] <arigo> i.e. do the same as in CPython
[13:59] <arigo> so a priori ovfcheck is needed, too
[14:02] <stakkars> what I did not understand: How does it skip ovfcheck at all?
[14:04] <arigo> I guess it's marked as NOT_RPYTHON
[14:04] <stakkars> no,m it is not!
[14:04] <stakkars> This is why I was wondering. It must take the frozen path, and it was not found in translator.flowgraphs
[14:05] <arigo> ah, that's possible, yes
[14:05] <stakkars> it looks like a phase error, if we have something like phases.
[14:05] <arigo> because the annotator never actually calls it, it special-cases it
[14:05] <arigo> but I guess we need to special-case it a bit in genc too
[14:08] <stakkars> why doesn't the annotator call it?
[14:11] <stakkars> and the other problem, if I run things with -no-a::
[14:12] <stakkars> then genc crashes with
[14:12] <stakkars> > d:\pypy\dist\pypy\translator\genc\pyobjtype.py(309)initclassobj()
[14:12] <stakkars> -> if isinstance(value, classmethod) and value.__get__(cls).__doc__.lstrip().sta
[14:12] <stakkars> rtswith("NOT_RPYTHON"):
[14:12] <stakkars> this is probably the same thing that occoured to me after the changes to properties.
[14:12] <stakkars> Will try to fix this one.
[14:16] <stakkars> ah, no. A simple bug, where __doc__ is None
[14:16] ludal (ludal@logilab.net2.nerim.net) left #pypy.
[14:20] <stakkars> ok. after fixing that, I crash in nameof_object: object is not an object.
[14:21] <stakkars> Exception: nameof(<classmethod object at 0x009F5F50>)
[14:21] <stakkars> weird weird weird
[14:21] <arigo> well there is no direct support for classmethods
[14:21] <arigo> we have to figure out where this one comes from
[14:21] <stakkars> I'm at it.
[14:23] <stakkars> my trick to find such is
[14:23] <stakkars> import __main__
[14:23] <stakkars> __main__.bad = value
[14:24] <stakkars> then it is easy to look at. Should I leave that hack in the code?
[14:26] <stakkars> ah, I see this isn't needed at all.
[14:29] <stakkars> gack! how do I find the class of a classmethod object?
[14:33] <stakkars> smells like gateway's _setup stuff.
[14:34] <arigo> you have to inspect with pdb who's asking for nameof(thisclassmethod)
[14:34] <idnar> method.im_self I think
[14:34] <arigo> I don't suggest you implement classmethods,
[14:35] <arigo> but first that you know which class method we're trying to use...
[14:35] <stakkars> sure, It is most probably something that should not get into the machinery
[14:35] <arigo> yes.
[14:40] <stakkars> got it.
[14:40] <stakkars> it is in fact my
[14:40] <stakkars> pypy.interpreter.gateway.ApplevelInterpClass
[14:41] <stakkars> which should not be seen.
[14:41] <stakkars> but how comes?
[14:41] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[14:42] _hannes (wlxenmcb@i528C131C.versanet.de) joined #pypy.
[14:42] <arigo> well, ApplevelClass is seen
[14:42] <stakkars> yes
[14:42] <arigo> ah I see
[14:43] <stakkars> should it be seen? Then I just need to change the attributes list
[14:43] <arigo> there is a _buildcode classmethod which is NOT_RPYTHON,
[14:43] <stakkars> yes
[14:43] <arigo> but the tag is probably hidden by its being a classmethod
[14:43] <stakkars> exactly
[14:43] <stakkars> the doc is classmethod's doc
[14:43] <arigo> ah
[14:43] <arigo> but it's not a function, so the doc is not inspected I guess
[14:44] <stakkars> it is inspected, this was probably the reason for the former bug.
[14:44] <arigo> ah, I see
[14:44] <arigo> then why doesn't the test not skip this classmethod altogether?
[14:45] <pedronis> arigo, stakkars: yes the generators need to special case the ovf... functions too
[14:45] <stakkars> it doesn't find the NOT_RPYTHON
[14:45] <stakkars> I will say NOT_RPYTHON_ATTRIBUTES = ['_setup']
[14:45] <stakkars> and try if it works
[14:46] _hannes (wlxenmcb@i528C131C.versanet.de) left irc: Read error: 113 (No route to host)
[14:47] <stakkars> pedronis: but I don't understand why the annotator avoids touching the function.
[14:47] <pedronis> because they are not RPython
[14:48] <stakkars> they are not flagged like that
[14:48] <stakkars> arigo: did not help, same bug
[14:48] <pedronis> they could be flagged, they are special cased
[14:49] <stakkars> magic alert. Please let us say that in the code, at the function (or do we?)
[14:49] <pedronis> stakkars: is subtle because the non-annotating translator should/can try to make sense of them
[14:49] <pedronis> so marking them is not the right thing either
[14:50] <pedronis> stakkars: read the checkins as you said once
[14:50] <stakkars> eek :-)
[14:50] <pedronis> ;)
[14:51] _hannes (pxqgza@i528C131C.versanet.de) joined #pypy.
[14:51] <pedronis> basically a non annotating translator should translate them
[14:51] <pedronis> an annoting one should special case them
[14:52] <pedronis> ctyper should do something about them
[14:53] <stakkars> what is wrong if they get generated and later just not called?
[14:55] <stakkars> pedronis: this is hard to read because I don't now what to look for.
[14:55] <pedronis> because they cannot be sensibly annotated
[14:55] <pedronis> isintance( . ,long)
[14:55] <pedronis> does not make that much sense if you have done a C intenger addition
[14:56] <pedronis> basically once you throw types into the mix as they are they are not correct anymore
[14:57] <stakkars> that's true.
[14:58] <pedronis> a translator using types needs to special case them to produce correct results
[15:00] <stakkars> I'm not sure what you are trying to tell me, because I know this.
[15:00] <stakkars> I thought the introduction of typed operations was the way to avoid extra intelligence
[15:01] <stakkars> in the generators, so I just wonder why we get a problem here.
[15:01] <pedronis> yes, but ovfcheck is really a special special case
[15:01] <stakkars> :-D
[15:01] <pedronis> it is about doing ovf checking with low-level arithmetic
[15:01] <pedronis> the generators should emit code that makes sense for them for that
[15:02] <pedronis> the annotator cannot help
[15:02] <stakkars> that means, you get one "special" tag removed, but the other one still remains in genc :)
[15:07] <stakkars> the annotatorcan help a little. Somehow it should pass the info over that the
[15:07] <stakkars> generator needs to implement this.
[15:07] <pedronis> but it does
[15:07] <pedronis> it doesn't produce a graph for them
[15:07] <pedronis> this is a strong hint that there's a problem or something special to do
[15:08] <stakkars> but if the annotator knows that the thing is special, it could emit a graph which has a single special operation
[15:08] <stakkars> in it, which the generator knows to render ?
[15:09] <pedronis> we write such a transformation yes
[15:09] <pedronis> we can
[15:09] <stakkars> maybe this was not well designed what I said...
[15:09] <hpk> arigo: you might want to refactor test_operations() as a generative test (yielding nested test functions, so each op is a single dot and can fail independently)
[15:09] <pedronis> you can write such a transformation
[15:09] <arigo> stakkars: such a transformation is the purpose of typer.py, basically
[15:10] <pedronis> yes
[15:10] <pedronis> the annotator is not doing transformations itself
[15:10] <arigo> hpk: I thought about it, but it would take far longer to run
[15:10] <stakkars> so I fear I have to go understand how that works.. ;-)
[15:11] <hpk> arigo: i am just thinking about factoring the assert statement out
[15:11] <arigo> hpk: and honestly if I make a typo in a .h file I don't want 100 long tracebacks :-)
[15:11] <hpk> arigo: good point :-)
[15:11] <arigo> hpk: ah ok, could be done (if not for the above point)
[15:11] <arigo> the for loop used to be a single assert, but then it's a bit hard to see where's the difference between the two tuples :-)
[15:12] <arigo> something else, at some point, we might think about removing direct references from the flow graphs
[15:13] <arigo> like direct references to built-in functions, or to other user-defined functions
[15:13] <arigo> and replace them with custom instances
[15:13] <pedronis> arigo: yes
[15:13] <arigo> it would avoid some meta-level confusion in our mind
[15:14] <arigo> and also, I had to hack in the new test_operation.py, because
[15:14] <arigo> there is no predefined way to compile a flow graph built manually,
[15:14] <arigo> when no function exist for it
[15:14] <pedronis> yes
[15:15] <pedronis> the translator is assuming heavily func->flowgraph
[15:15] <arigo> indeed
[15:15] <arigo> we could probably move a bit more information into the FunctionGraph class and get rid of the func objects
[15:16] <pedronis> well we need a different way to represent functions in the graphs
[15:16] <pedronis> and then have a mapping repr -> flowgraph
[15:17] <arigo> ok, I was thinking that the FunctionGraph would be the repr itself,
[15:17] <pedronis> but some things don't have flowgraphs
[15:17] <arigo> I see
[15:17] <pedronis> not that you couldn't use degenarate flowgraphs
[15:18] <pedronis> but I don't know whether that would reduce or increase confusion :)
[15:18] <arigo> :-)
[15:19] <pedronis> adding a level of indirection for the repr of some objects in the graphs would be good also because of specialization
[15:20] <stakkars> side question: why do we need to allow objects in gateway to be visible at all?
[15:20] <arigo> yes, if the repr can point to several graphs
[15:20] <pedronis> we probably need specila repr for functions and classes
[15:21] <stakkars> is it ok if I flag the applevel() function as not rpython?
[15:21] <arigo> stakkars: no
[15:21] <arigo> I'm trying to figure it out again, but I remember it was definitely visible
[15:22] <arigo> ah yes
[15:22] <arigo> lazymodule.py:108
[15:22] <stakkars> that would mean that my geninterp crap could be pulled in?
[15:22] <arigo> this function is R-Python
[15:22] <arigo> it sees a constant ApplevelClass instance, and calls its wget() method at run-time
[15:22] <arigo> stakkars: yes
[15:23] <stakkars> ?????
[15:23] <arigo> it means you need careful NOT_RPYTHON tagging on your class.
[15:23] <pedronis> stakkars: btw, all the special casing done by the annotator can be found in annotation/builtin.py or pypy/translator/ann_override.py (more PyPy codebase specific stuff)
[15:23] <stakkars> pedronis: thanks, that was my next question
[15:24] <arigo> stakkars: basically, the _setup classmethod is the one who is missing NOT_RPYTHON and causing all this trouble.
[15:24] <stakkars> arigo: that sound hairy. I need to make sure that my stuff somehow disappears when we compile
[15:25] <pedronis> what stuff?
[15:25] <arigo> yes, but that's easy -- we see it's only missing a NOT_RPYTHON on _setup(), and that's it.
[15:25] <stakkars> arigo: yes,but how do we make sure that the generated code does not try to go this path?
[15:25] <arigo> you can possibly list some attributes in NOT_RPYTHON_ATTRIBUTES, too.
[15:26] <arigo> stakkars: the parent ApplevelClass does to some length to make sure of that
[15:26] <stakkars> ok, I'll try.
[15:26] <arigo> see e.g. wget() which calls getwdict() -- both are RPython -- which uses space.loadfromcache() to continue calling non-rpython code
[15:27] <pedronis> arigo, stakkars: you need to explictily copy the NON_RPYTHON_ATTRIBUTES from the base class
[15:27] <arigo> pedronis: yes, but the derived class doesn't have a 'code' attribute any more in this case
[15:27] <pedronis> because if I remember inheritance is not properly handled
[15:27] <stakkars> oki doki
[15:27] <pedronis> arigo: I see, just a reminder because that can bite too
[15:27] <arigo> ok
[15:28] <stakkars> well I don't think so because I don't initialize the baseclass;-)
[15:29] <arigo> yes, it could be refactored somehow, if needed at some point
[15:30] <arigo> e.g. with a pure RPython class that has a reference to an instance of another, non-RPython class, and which drops the reference once it has been built
[15:30] <stakkars> ok, things are getting better.
[15:30] <stakkars> now we are really stepping into something wrong:
[15:30] <stakkars> Exception: Cannot translate an already-open file: <open file 'f:\tmp\usession-69
[15:30] <stakkars> 4\entry_point_1.c', mode 'w' at 0x00D1B060>
[15:34] <stakkars> walking up the pdb stack, I see that we are trying to build a ginst_GenC :-#
[15:34] <arigo> :-)
[15:35] <stakkars> and this is harder to find out, because I am not really in the machinery, but in some postprocessing:
[15:35] <arigo> please check in your changes to gateway.py (any others?)
[15:35] <stakkars> happens somewhere below self.gen_global_declarations()
[15:36] <stakkars> let me first run a test, then I'll do
[15:36] <arigo> here is the technique to know where some objects come from:
[15:36] <arigo> def nameof() in pyobjtype.py has a 'debug' argument
[15:37] <stakkars> ah yes, I never used it and forgot about it.
[15:37] <arigo> you put a pdb breakpoint in there for the object you want to look for
[15:37] <stakkars> sorry, how do Iput a pdb breakpoint into something?
[15:37] <arigo> then you inspect the debug argument, which contains nested tuples
[15:37] <arigo> import pdb; pdb.set_trace()
[15:37] <stakkars> inside the nameof?
[15:37] <arigo> nested tuples showing a "reference stack" leading to the current object.
[15:37] <arigo> yes
[15:38] <stakkars> okidokithx
[15:38] <arigo> with a condition "if the object is the one I'm looking for:"
[15:39] <pedronis> arigo: it seems we need to annotate xrange, there's code using it
[15:39] <arigo> beuh
[15:40] <arigo> builtin_xrange = builtin_range
[15:40] <pedronis> yes
[15:40] <arigo> :-)
[15:40] <pedronis> but wasn't the idea not to use xrange
[15:40] <arigo> yes
[15:40] <arigo> dunno if it makes sense to hunt them down and replace them all with range,
[15:40] Action: pedronis is working on full annotation for targetpypy
[15:41] <arigo> or just accept the xrange
[15:41] <arigo> good :-)
[15:41] <pedronis> that's the rub
[15:41] <arigo> it's trivial to accept it, so let's do that
[15:41] <pedronis> yes, it's easier than forcing people not to use it
[15:42] <stakkars> make it a synonym for range, yes
[15:43] <pedronis> no, I'm annotating it the same way
[15:43] <pedronis> making a synonim is a graph transformation
[15:44] <stakkars> I thought youwould just set xrange to range in flow space?
[15:45] <stakkars> arigo: checked in
[15:45] <pedronis> we could, but I'm not sure is flowgraph business
[15:45] <stakkars> for me,flow graph was kind of definition of RPython :-]
[15:46] <pedronis> but then you invented geninterplevel and things got more complicated :)
[15:47] <stakkars> you mean stuff like that might have weird consequences for this mixed-level stuff,yes.
[15:47] <pedronis> well, flowgraph has grown flags to do different things for geninterplevel vs. the the low-level generators
[15:50] <stakkars> thinking more about it... actually, xrange in an translatable applevel thing is a different beast.
[15:52] <pedronis> likely
[15:53] <pedronis> btw, I got a new processor and more memory for my office desktop machine, this should help
[15:54] Gromit (~bear@B74c8.b.pppool.de) joined #pypy.
[15:54] <stakkars> if it is 1000 times faster, then really. The real help will be good genc code :-)
[15:56] <arigo> :-)
[15:56] <pedronis> stakkars I'm thinking about annotation right now, which would need to run on a PyPy faster than CPython to help
[15:57] <stakkars> :-)
[15:57] <stakkars> I'm now in the nameof_file
[15:58] <stakkars> but there is no debug argument
[15:59] <stakkars> ah,self.debugstack
[16:00] <arigo> yup
[16:00] <arigo> can you make sense of it?
[16:00] <stakkars> maybe you can make sense of it?
[16:00] <stakkars> (Pdb) self.debugstack
[16:00] <stakkars> ((((), (('Constant in the graph of', <pypy.translator.genc.funcdef.FunctionDef i
[16:00] <stakkars> nstance at 0x0907E9E0>), <pypy.interpreter.miscutils.ThreadLocals instance at 0x
[16:00] <stakkars> 009A8C60>)), <pypy.translator.genc.genc.GenC instance at 0x015DBE40>), <open fil
[16:00] <stakkars> e 'f:\tmp\usession-696\entry_point_1.c', mode 'w' at 0x00D1D8A0>)
[16:00] <arigo> aAArgh
[16:00] <stakkars> somebody hold a reference which is no good
[16:01] <arigo> threadlocals
[16:01] <arigo> see basetype.py
[16:01] <arigo> I'm storing the current genc instance into the thread locals
[16:01] <pedronis> ah yes
[16:01] <arigo> so of course, when the *same* threadlocal object gets pickled by genc.py, it sees the genc instance
[16:02] <arigo> there is potentially the same problem in the annotator, though it usually cleans up threadlocals after use
[16:02] <arigo> I guess we need to use another threadlocal for the tools.
[16:02] <pedronis> yes :)
[16:03] <arigo> self.debugstack is slightly broken, btw, it shows <FunctionDef instance at blabla> instead of the real function object
[16:03] Gromit (~bear@B74c8.b.pppool.de) left irc: Read error: 54 (Connection reset by peer)
[16:06] Action: stakkars reading why threadlocals are needed at all?
[16:07] <pedronis> btw, the tools should probably use real threadlocals if at all
[16:07] <stakkars> at least they should not share their space with the analysed stuff
[16:08] <stakkars> I don't get why genc uses this at all?
[16:12] <arigo> :-)
[16:13] <arigo> stakkars: that's complicated refactoring
[16:13] <arigo> it's the only convenient way to pass an argument down a few nested method calls when most of the time you don't need the damn argument
[16:14] <stakkars> ah, and it is basically the same thing as pystate.c, tstate->dict ?
[16:14] <arigo> yes
[16:14] <arigo> though what we usually need is just dynamically scoped variables
[16:14] <stakkars> I didn't find how it was used in genc
[16:15] <arigo> ?
[16:15] <arigo> just look for getthreadlocals()
[16:16] <stakkars> I did, but not in all files. I see
[16:16] <stakkars> well, let me write a real one.
[16:19] <pedronis> stakkars: we still want a fake one for PyPy
[16:19] <pedronis> itself
[16:21] <stakkars> yes, that's fine with me. I just want to have one that is meant for our meta stuff
[16:21] <arigo> and a real one probably in tool/something.py
[16:21] <arigo> yes.
[16:22] <pedronis> agreed
[16:22] <stakkars> arigo: should I simply do it using the thread local dict, ordo you want just *something*
[16:23] Gromit (~bear@dialin-212-144-179-121.arcor-ip.net) joined #pypy.
[16:23] <arigo> we can't access the thread local dict
[16:23] <arigo> and I certainly don't want a C extension module :-)
[16:24] <stakkars> side note: if you need to stick some extra args somewhere, wy didn't you use some self.whatsoever?
[16:24] <arigo> stakkars: because 'self' is built before the GenC instance
[16:24] <arigo> these CType objects are attached to the graph by typer.py
[16:24] <arigo> this is all done before GenC starts
[16:24] <pedronis> or in you are in a plain function and there's no self
[16:25] <arigo> pedronis: in this case there is one, I think Christian's talking about basetype.py
[16:25] <stakkars> so it's actually the good old global object which is needed somewhere, at some place.
[16:25] <arigo> yes
[16:26] <arigo> with a better module system, we could use a real global object
[16:26] <arigo> and instead of instantiating a GenC(), we would instantiate the whole package just for one usage
[16:26] <stakkars> a very hackish, simple way is to use one instance in __main__ :-)
[16:27] <pedronis> well the global would need to be thread-safe ideally
[16:27] <arigo> stakkars: the problem is not where to store it
[16:27] <stakkars> but?
[16:27] <arigo> but to avoid collisions if there are several GenC instances in the same process
[16:28] <arigo> so using thread-local storage doesn't fundamentally solve the problem, but makes it less likely
[16:28] <stakkars> but that isn't implemented in the current scheme as well.
[16:29] <arigo> the current scheme assumes that the gen_source() method of a GenC instance cannot recursively call another GenC instance
[16:29] <arigo> which is reasonable enough.
[16:29] <arigo> (of course *right* now the threadlocal isn't threadlocal at all so you're right)
[16:30] <stakkars> sure, what I meant is that this is just hiw genc handles
[16:30] <stakkars> sorry, how genc handles it, but the shared object itself is a very dumb single instance
[16:30] <arigo> yup
[16:31] <arigo> that's why we should replace it, in this case and in the annotator's case, with a real thread-storage instance
[16:31] <stakkars> so what I meant is why shouldn't I just make a copy ofthat little thing and make genc and all descendants use it in the same way?
[16:31] <arigo> we want real thread protection, ultimately
[16:31] <arigo> so now is a good time to do that
[16:31] <arigo> otherwise we could just have a dumb global variable and be done with it
[16:32] <stakkars> sure. I want to get my task done for today and translate rpystone.
[16:32] <arigo> the current usages of getthreadlocals() are meant, if you wish, as a reminer that "here's global stuff to make safer"
[16:32] <stakkars> Instead I'm fixing bugs all days which are unrealted, formyPOV.
[16:32] <stakkars> Sure, it has to be done, anyway.
[16:32] <arigo> I can do it if you like
[16:34] <stakkars> before that, let me ask:
[16:34] <stakkars> the threadlocal stuff is going to be translated and it will go into C somehow?
[16:34] <arigo> no
[16:34] <stakkars> I mean the stuff where we interfere with.
[16:35] <arigo> ?
[16:35] <arigo> pypy.interpreter uses threadlocals from miscutils, which are dumb, and which we are not changing for now
[16:35] <arigo> and this is easy to translate, has been done already
[16:36] <arigo> right now, we need another "real" unrelated thread-locals for the translator's internal purposes
[16:36] <arigo> something that will never be seen or translated.
[16:36] <stakkars> yes, that's fine. I just wondered if this gets translated.
[16:36] <arigo> ok
[16:36] <stakkars> and if we could avoid the problem by not pickling that thing.
[16:36] <stakkars> the point is: applications put their info there, under a name.
[16:37] <arigo> that's not visible for app-level applications
[16:37] <stakkars> But they don't want to share that info to other apps which don't know the name.
[16:37] <stakkars> I wouldprobably make access to this anonymous
[16:37] <arigo> not sure I follow. We could design a full-blown, name-collision-avoiding thread-local thingy, but we don't really need that, I think
[16:38] <arigo> not now
[16:38] <stakkars> sure.
[16:38] <arigo> you're getting far too far off your way :-)
[16:38] <stakkars> assume you have two apps, somehow sharing the same (no I'm not) thread local storage.
[16:39] <arigo> (sure you are)
[16:39] <stakkars> You are translating the one of them, but you don't want to pull the other app in, just because it has
[16:39] <stakkars> access to it.
[16:40] <arigo> that's related to threads in general
[16:40] <arigo> we haven't decided how to translate multithreaded R-Python source
[16:41] <arigo> and that's definitely not related to making a general threadlocal in tool and use it in translator/ and annotator/ :-)
[16:41] <stakkars> in short: an alternative to a new TLS implementation, we also could avoid to pickle that inst dict.
[16:42] <stakkars> and don'tpull anything in that we don't spell.
[16:42] <arigo> but first we'd have to resolve a few real problems.
[16:42] <arigo> this inst exists as a prebuilt instance only because we don't really support threads, and have a single prebuilt instance
[16:43] <arigo> if we really supported threads, there wouldn't be such an instance in the first place
[16:43] <stakkars> I really really understand your point. (but not vice versa)
[16:44] <arigo> indeed
[16:44] <stakkars> at some point, we need real TLS, that's true. I just wanted to avoid having to think about
[16:44] <stakkars> this right now. Instead I wanted to solve it by making siblings invisible to each other, and done.
[16:45] <stakkars> ok I give up.
[16:46] <arigo> ok, that's one way, but I still think it's less confusing to separate the R-Python fake TLS and the real TLS used by the tools.
[16:52] <stakkars> then I ignore this and focus on the ovf special handling.
[16:53] <arigo> do you want me to quick-fix it or did you already?
[16:54] idnar (mithy@idnar.user) left irc: "leaving"
[17:00] <stakkars> if you can do it, it would probably be more in your sense, so I'd prefer it.
----- silence for 22 minutes ----- [17:22] <arigo> done
[17:29] <pedronis> I'm adding interpreter.typedef.instantiate to the list of things special cased
[17:29] <arigo> I see
[17:34] <pedronis> I also need to do something about the code that wrap exceptions in StdObjSpace.wrap
[17:40] Gromit (~bear@dialin-212-144-179-121.arcor-ip.net) left irc: Read error: 113 (No route to host)
[17:40] Gromit (~bear@B749c.b.pppool.de) joined #pypy.
----- silence for 34 minutes ----- [18:14] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
----- silence for 16 minutes ----- [18:30] <stakkars> woha, I now get very very far with -no-a
[18:31] <stakkars> but then I stepon a bug in error.py
[18:31] <stakkars> easy to fix, it is fow space's inability to deduce about variable lifetime
----- silence for 16 minutes ----- [18:47] <cfbolz> pedronis: To answer your question in the checkin: Do you think 0L should be represented as digits = [r_uint(0)], sign = 0 or digits = [], sign = 0?
[18:47] <cfbolz> It doesn't make sense to have both representations
[18:52] <pedronis> cfbolz: now that I think [] now would make space.int do the wrong thing
[18:52] <pedronis> cfbolz: one way or the other should be picked and used consistently
[18:53] <stakkars> error in pyparser!
[18:53] <stakkars> found by the great, great flow space :-D
[18:54] <cfbolz> pedronis: then I pick the first one and try to enforce it consistently. thanks.
[18:56] <pedronis> stakkars: interesting, yes sometimes the flow space finds bugs, right now I'm working on annotating all of PyPy but I have disabled the parser
[18:57] <stakkars> pyparser does "for child in children", and after the loop,
[18:57] <stakkars> some error condition is checked, and child is used.
[18:57] <stakkars> But this needs not to exist.
[18:57] <stakkars> I'll see how much of these I can find, or I disable it, too :)
[18:58] <pedronis> well, I have disabled it because it was not written thinking about RPython so there are surely problems and I have enough shallow and more deep issues to play with
[18:58] <pedronis> with the rest of PyPy
[18:59] <stakkars> how do I disable it? (btw., this was a real bug, because if children was empty, child doesn't exist)
[19:00] <pedronis> you need to remove a line in baseobjspace and put one back in sys2/state.py
[19:00] <stakkars> ok, thanks
[19:02] <stakkars> it is really nice to observe my cache file being compiled. Makes some sense for debuging.
[19:13] arigo (~arigo@stups.cs.uni-duesseldorf.de) left irc: "[x]chat"
[19:15] arigo (~arigo@134.99.112.244) joined #pypy.
[19:19] <stakkars> for some reason, it takes minutes to flow the dir() function
[19:21] <stakkars> pedronis: yes, it needs to be disabled. Did you check this in?
[19:21] <stakkars> I guess we should.
[19:22] <pedronis> I can check it in
[19:22] <stakkars> please
[19:22] <stakkars> I needtoget some things fixed before I leave to my parents, where I have no internet.
[19:23] <stakkars> So I'mtrying to getall things set that I can solve problems without your help.
[19:23] <pedronis> done
[19:26] Gromit (~bear@B749c.b.pppool.de) left irc: Read error: 104 (Connection reset by peer)
[19:34] <cfbolz> bye
[19:35] <hpk> bye
[19:35] <arigo> bye
[19:35] <stakkars> bye
[19:35] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[19:36] <stakkars> ok, flowing targetpypy1 with -no-a seems to work, again. I just have no idea whether it C-compiles because this takes so long on windows. Maybe I do the final test on tismerysoft.de
[19:42] <pedronis> arigo, stakkars: should the should_translate_attr method logic go in gensupp?
[19:42] <arigo> fine by me
[19:43] <pedronis> I probably need some logic to skip NOT_RPYTHON stuff in the annotator
[19:43] <pedronis> so I would like a place to put that together with related things
[19:43] <stakkars> yes
[19:43] <arigo> why does the annotator see them at all?
[19:43] Gromit (~bear@B74a4.b.pppool.de) joined #pypy.
[19:44] <pedronis> arigo: the problem are for example instances of mutable constants with NOT_RPYTHON __init__
[19:44] <arigo> but __init__ shouldn't be called unless the class is really called?
[19:45] <pedronis> no they end up in __init__ attrdef of the supeclass
[19:45] <arigo> as SomeImpossibleValue, though
[19:45] <pedronis> which is instantiated and RPython
[19:45] <arigo> no?
[19:45] <pedronis> it seems not
[19:46] <pedronis> Module.__init__ tries LazyModule.__init__
[19:46] <arigo> uh?
[19:46] <arigo> that's wrong
[19:46] <arigo> calls to a class should go to the exact __init__
[19:47] <arigo> super calls should be static too
[19:47] <pedronis> but this an explicit inst.__init__ in the call
[19:47] <arigo> ah
[19:48] <pedronis> is not an __init__ call triggered by a construction call
[19:48] <arigo> maybe that's the non-RPython bit then?
[19:48] <pedronis> in the code
[19:48] <arigo> argh, I see
[19:48] <pedronis> well, __init__ is a function
[19:48] <arigo> hum, ok
[19:49] <pedronis> I mean the idiom of calling __init__ on constructed thing is fine in itself
[19:49] <pedronis> it can be translated
[19:50] <arigo> well, yes, but then it's this usage which is slightly strange
[19:50] <pedronis> part of descr__new__ have such code
[19:50] <arigo> it looks like a "virtual method call" but the __init__ of a subclass has a different signature
[19:50] <arigo> so it can only really mean a static call
[19:51] <arigo> I mean, in a translated world
[19:51] <pedronis> well __init__ is normal method so it could be a virtual call in principle if the signature are ok
[19:52] <arigo> yes
[19:52] <arigo> so this source code is somehow not translatable
[19:52] <pedronis> why?
[19:53] <arigo> because it is not safe:
[19:53] <arigo> it's a call to a method which may arrive in a method with incompatible signature
[19:53] <pedronis> no
[19:54] <arigo> I mean, in practice it cannot crash like this, but the annotator cannot prove it
[19:54] <pedronis> the annotator would throw an exception if the signature number dont much
[19:54] <pedronis> but that's true in general of virtual calls
[19:54] <arigo> ah, right
[19:54] <arigo> in this case the signatures match
[19:55] <pedronis> yes, but some of the __init__ are NOT_RPYTHON
[19:55] <arigo> unless you say that NOT_RPYTHON makes the signature different :-)
[19:55] <arigo> precisely
[19:55] <arigo> I mean, in this case, we don't *mean* a virtual dispatch, but a call to a specific known method
[19:55] <arigo> so we could use the same idiom as for super calls, i.e. Module.__init__(self, ...)
[19:56] <stakkars> whow, now targetpypy1 -no-a produces a syntax error!
[19:57] <arigo> if possible, I'd rather have the annotator keep complaining about unforeseen ways to enter NOT_RPython functions
[19:57] <arigo> stakkars: :-(
[19:57] <pedronis> yes, but just because for now User_ classes don't have a special __init__
[19:57] <pedronis> then you would want a virtual dispatch
[19:58] <arigo> hum
[19:58] <arigo> no, because you can't put an __init__ there, you need *args
[19:58] <arigo> there is user_setup() instead, in the User_ classes
[19:59] <pedronis> I try with Module.__init__
[20:05] <stakkars> hrrmpf. /tmp/usession-104/entry_point_1.c:326636: identifier expected
[20:06] <stakkars> here the +-1lines:
[20:06] <stakkars> pyobj w_name_6; pyobj w_bases_6; pyobj w_dict_6; pyobj w_winner_6;
[20:06] <stakkars> pyobj newfunc; pyobj v51; pyobj v52; pyobj v53; pyobj v54;
[20:06] <stakkars> pyobj space_7; pyobj w_typetype_5; pyobj w_name_7; pyobj w_dict_7;
[20:06] <stakkars> this looks like a tcc bug. ?
[20:07] <arigo> strange, indeed
[20:07] <stakkars> I'll let it run again without -tcc
[20:16] Gromit (~bear@B74a4.b.pppool.de) left irc: Read error: 110 (Connection timed out)
[20:16] Nick change: pedronis -> pedronis_afk
[20:20] idnar (mithrandi@idnar.user) joined #pypy.
[20:24] Gromit (~bear@dialin-212-144-175-153.arcor-ip.net) joined #pypy.
[20:24] <arigo> stakkars: tcc doesn't like the identifier 'newfunc'
[20:25] <arigo> hum, no
[20:27] <stakkars> huh! Yes, I just saw gcc succeed.
[20:28] <stakkars> either I disable my naming stuff, or I add that one to the predefined things.
[20:29] <arigo> I'm not sure why it complains, in smaller examples it works
[20:30] <stakkars> ahahaha such a tinycompiler with such sbtle bugs
[20:30] <arigo> no, wait
[20:30] <arigo> it's related to include files, I'm wondering if someone if #defining newfunc?
[20:30] idnar (mithrandi@idnar.user) left irc: Operation timed out
[20:31] <stakkars> even if so, why did it work with gcc
[20:31] <arigo> no clue
[20:31] <stakkars> let me see...
[20:32] <arigo> basically, if you #include <Python.h>, then you can't use newfunc as an ident
[20:32] <arigo> ah ha
[20:32] <stakkars> ouch
[20:32] <arigo> newfunc is a typedef in Python.h
[20:32] <arigo> in object.h, precisely
[20:32] <stakkars> thanks. I'll put it into reserved words.
[20:32] <arigo> no
[20:33] <arigo> there are thousands of typedefs!
[20:33] <stakkars> I see.
[20:33] <arigo> it shows that gcc isn't happy with local vars named after types...
[20:33] <arigo> hum, looks like a real bug
[20:34] <arigo> int newfunc is fine
[20:34] <stakkars> you meant tcc
[20:34] <arigo> PyObject *newfunc is fine
[20:34] <arigo> yes
[20:34] <arigo> but "pyobj newfunc" is not fine
[20:34] <arigo> where "typedef PyObject *pyobj"
[20:34] <stakkars> and newfunc is a typedef, too
[20:35] <arigo> yes
[20:35] <arigo> pyobj a, b, newfunc; is fine
[20:35] <stakkars> nightingale, I hear your footsteps
[20:35] <arigo> parser error, I guess
[20:35] <arigo> :-)
[20:36] <stakkars> so what to do. Generally avoiding plain names, i.e. I disable something you didn'tlike, anyway?
[20:36] <arigo> dunno, it looks dumb
[20:36] <arigo> "pyobj newfunc x" works!
[20:37] <stakkars> parser brubbel
[20:37] <arigo> yup
[20:38] <arigo> argh.
[20:38] <stakkars> replacing the typedef by a macro would probably not help, too
[20:38] <arigo> the typedef of PyObject *pyobj ?
[20:38] <stakkars> yes
[20:38] <arigo> I guess it would help, but well, only in this case
[20:38] <arigo> I suppose that there is no way, for now, short of adding a systematic prefix to variable names
[20:39] <arigo> and hope we don't get collisions with the prefix :-)
[20:39] <stakkars> well, then let me do it with a suffix
[20:39] <arigo> if you like
[20:39] <arigo> that's more fragile, from my point of view
[20:40] <stakkars> I don't like it, but if it helps.
[20:40] <arigo> all the rest of the code is using prefixes, so you could theoretically have a collision
[20:40] <stakkars> do you really expect a typedef like newfunc_1 ?
[20:40] <arigo> there could be a class newfunc, which then produces a typedef like newfunc_1 in the generated code
[20:41] <arigo> although it would be more a class newfunc producing a typedef Kls_newfunc_1, but this could collision with a local variable called Kls_newfunc.
[20:41] <arigo> you never know :-)
[20:41] <stakkars> I don't get you. I'm talking about disabling my naming tricks, which are the causeof this.
[20:42] <arigo> ah, I'm talking about keeping them but adding a prefix to all local variables afterwards
[20:42] <arigo> afterwards or at some point
[20:43] <arigo> so that we can rely on local variables getting names starting with some known prefix, but still readable names...
[20:44] <stakkars> whatever, I need to run. Maybe I can read logs before I leave,so please just decide and tell.
[20:44] <stakkars> later - bye
[20:44] <stakkars> (mom's birthday)
[20:44] <arigo> bye!
[20:44] <arigo> happy birthday :-)
[20:44] <stakkars> :)
[20:45] stakkars (~tismer@82.144.60.19) left irc: "vroooom"
[20:46] Nick change: pedronis_afk -> pedronis
[20:47] <arigo> stakkars: in gensupp._LocalScope.localname(), you add a 'w_' prefix for wrapped objects
[20:47] <arigo> stakkars: I was suggesting that you add, say, a 'l_' prefix for other objects.
[20:48] <arigo> stakkars: this will produce local vars called l_xxx in genc, but no one hopefully has got a typedef l_xxx.
[20:48] <arigo> stakkars: the typedefs produced by genc itself are never called l_xxx, because they use other prefixes.
[20:53] Gromit (~bear@dialin-212-144-175-153.arcor-ip.net) left irc: Read error: 110 (Connection timed out)
[20:57] Gromit (~bear@port1129.fra.ginko.net) joined #pypy.
[21:05] Action: arigo checked in the above 'l_' prefix hack, which makes tcc happy on targetpypy1 -no-a
[21:06] <arigo> stakkars: feel free to do it differently, though -- although we need some kind of workaround for now.
[21:06] arigo (~arigo@134.99.112.244) left irc: Remote closed the connection
[21:17] Gromit (~bear@port1129.fra.ginko.net) left irc: Read error: 110 (Connection timed out)
[21:17] Gromit (~bear@B7499.b.pppool.de) joined #pypy.
[21:26] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) joined #pypy.
[21:38] tea (~tea@cap002-249.kcn.ne.jp) left irc: Remote closed the connection
[21:42] Gromit (~bear@B7499.b.pppool.de) left irc: "hust, rotz & schnarch"
----- silence for 46 minutes ----- [22:28] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
----- silence for 54 minutes ----- [23:22] CLI (opera@86.125.128.38) joined #pypy.
[23:30] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: "Leaving"
[23:32] CLI (opera@86.125.128.38) left irc: Read error: 54 (Connection reset by peer)
[23:32] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[00:00] --- Fri Apr 15 2005