Class processing error

[GoogleCodeExporter]

What steps will reproduce the problem?
Unknown, just compiling a huge .py with many classes. 

What is the expected output? What do you see instead?
I added a print lcp to display the [ ... ] in the log.
    if len(lcp) > 1:
+        print lcp
in /usr/lib/python2.7/dist-packages/shedskin/typestr.py:~190

[class none, class int_, class str_]
[class none, class str_, class int_]
Traceback (most recent call last):
  File "/usr/bin/shedskin", line 3, in <module>
    shedskin.main()
  File "/usr/lib/python2.7/dist-packages/shedskin/__init__.py", line 138, in main
    start(gx, main_module_name)
  File "/usr/lib/python2.7/dist-packages/shedskin/__init__.py", line 128, in start
    generate_code(gx)
  File "/usr/lib/python2.7/dist-packages/shedskin/cpp.py", line 2715, in generate_code
    gv.header_file()
  File "/usr/lib/python2.7/dist-packages/shedskin/cpp.py", line 248, in header_file
    self.visit(self.module.ast, True)
  File "/usr/lib/python2.7/compiler/visitor.py", line 57, in dispatch
    return meth(node, *args)
  File "/usr/lib/python2.7/dist-packages/shedskin/cpp.py", line 570, in visitModule
    self.module_hpp(node)
  File "/usr/lib/python2.7/dist-packages/shedskin/cpp.py", line 348, in module_hpp
    self.class_hpp(child)
  File "/usr/lib/python2.7/dist-packages/shedskin/cpp.py", line 711, in class_hpp
    self.class_variables(cl)
  File "/usr/lib/python2.7/dist-packages/shedskin/cpp.py", line 807, in class_variables
    self.output(nodetypestr(self.gx, var, cl, mv=self.mv) + self.cpp_name(var) + ';')
  File "/usr/lib/python2.7/dist-packages/shedskin/typestr.py", line 119, in nodetypestr
    return typestr(gx, types, None, cplusplus, node, check_extmod, 0, check_ret, var, mv=mv)
  File "/usr/lib/python2.7/dist-packages/shedskin/typestr.py", line 124, in typestr
    ts = typestrnew(gx, types, cplusplus, node, check_extmod, depth, check_ret, var, tuple_check, mv=mv)
  File "/usr/lib/python2.7/dist-packages/shedskin/typestr.py", line 194, in typestrnew
    elif not node or infer.inode(gx, node).mv.module.builtin:
AttributeError: 'NoneType' object has no attribute 'module'

So basically, what I understand is that processing a certain string/int is 
incorrect in my code, I'll try to dive more in printing node incriminated.

What version of the product are you using? On what operating system?
shedskin 0.9.4, python 2.7.6

Cheers,
Olivier

Original issue reported on code.google.com by laetitia...@gmail.com on 6 Mar 2014 at 10:02

[GoogleCodeExporter]

thanks for reporting. could you please send me the sourcecode, possibly in 
private, so it's much easier to have a look? :-)

Original comment by mark.duf...@gmail.com on 6 Mar 2014 at 10:09

[GoogleCodeExporter]

Ok so the fix here is: 
/usr/lib/python2.7/dist-packages/shedskin/typestr.py:191
        if set(lcp) == set([python.def_class(gx, 'int_'), python.def_class(gx, 'float_')]):
            return conv['float_']
        elif not node or not infer.inode(gx, node).mv or infer.inode(gx, node).mv.module.builtin:

Afterwards I get a list of types that are marked as "expression has dynamic"
I'll fix my code with displayed warnings and keep you updated.

I get that it's easier to have a look with the python sourcecode. My problem is 
that his code is developed under a NDA with a thirdparty company. So I can't 
provide it until you sign the NDA as well :)
Legals will definitely lead us to a sad end !

Cheers,
Olivier

Original comment by laetitia...@gmail.com on 6 Mar 2014 at 10:52

[GoogleCodeExporter]

the real problem is not here, but I guess not crashing here is a definite 
improvement ^^ will have a look at your patch and probably commit it later 
today.

btw how many lines of code is your program, and how long does it take to 
analyze?

Original comment by mark.duf...@gmail.com on 6 Mar 2014 at 10:55

[GoogleCodeExporter]

The program is composed of 2 files, one of 700 lines, the other of 2500 lines.
It takes approx 10-15 minutes to get to the warning list (Core2 L9400)
The type analysis is very long. But well it definitely performs as I required 
and the execution time gain later is tremendeous (even compared to pypy).
Basically the program I write performs optimizations in assembly code for an 
embedded platform before the final link pass.
Cheers,
Olivier

Original comment by laetitia...@gmail.com on 6 Mar 2014 at 11:00

[GoogleCodeExporter]

Well I just saw I used my wife's google acocunt to post that. I've already 
reported a bug sometimes ago.

Original comment by akato...@gmail.com on 6 Mar 2014 at 11:02

[GoogleCodeExporter]

sounds like an interesting tool. please let me know when you run into other 
problems or if I can help optimize the result. you've probably already seen the 
standard optimization tips in the wiki documentation.

Original comment by mark.duf...@gmail.com on 6 Mar 2014 at 11:08

[GoogleCodeExporter]

I'm afraid I hadn't checked out how to optimize the conversion process as it's 
definitely not a show stopper !

Original comment by akato...@gmail.com on 6 Mar 2014 at 11:36

[GoogleCodeExporter]

Ok, I finally have a valid conversion, so basically, the unsupported thing is 
this:

map = {}
def function(self,arg1,arg2):
  map["somestring"] = ["string1","string2",int(arg1),int(arg2),"string3"]

function(3,4)
map["somestring"][2] += map["somestring"][3]

or something alike. The unsupported part is the array of mixed type. when 
replaced by a class, it works like a charm.

Cheers,
Olivier

Original comment by akato...@gmail.com on 6 Mar 2014 at 1:06

[GoogleCodeExporter]

once you applied above fix, did shedskin give you useful warnings that pointed 
you to the problem..?

Original comment by mark.duf...@gmail.com on 6 Mar 2014 at 1:56

[GoogleCodeExporter]

oh sorry you already said you got 'dynamic type' warnings. 

Original comment by mark.duf...@gmail.com on 6 Mar 2014 at 1:57

[GoogleCodeExporter]

No problem,
Yes after the fix, warnings were relevant. So I was able to find a solution, 
the only tricky stuff was the array with mixed item type.

Original comment by akato...@gmail.com on 6 Mar 2014 at 3:15

[GoogleCodeExporter]

this line was already fixed in GIT, good.. :-)

https://gitorious.org/shedskin/mainline/commit/78b4ef969f3b321dcf7a0a43a4d86d114
de005b2

did the analysis get much faster after fixing the dynamic types?

Original comment by mark.duf...@gmail.com on 7 Mar 2014 at 10:24