AeroEng43 / shedskin

Automatically exported from code.google.com/p/shedskin
0 stars 0 forks source link

KeyError during compile #37

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. shedskin ftplib.py

What is the expected output? What do you see instead?
expected success, saw:

dbm@zareason /home/dbm/bench/uploadSirikata> shedskin ftplib.py
*** SHED SKIN Python-to-C++ Compiler 0.2 ***
Copyright 2005-2009 Mark Dufour; License GNU GPL version 3 (See LICENSE)

[iterative type analysis..]
******
iterations: 6 templates: 2098
[generating c++ code..]
Traceback (most recent call last):
  File "/usr/lib/shedskin/bin/ss.py", line 433, in <module>
    main()
  File "/usr/lib/shedskin/bin/ss.py", line 428, in main
    analysis(name)
  File "/usr/lib/shedskin/bin/ss.py", line 149, in analysis
    generate_code()
  File "/usr/lib/shedskin/bin/ss.py", line 285, in generate_code
    walk(module.ast, gv)
  File "/usr/lib/python2.5/compiler/visitor.py", line 106, in walk
    walker.preorder(tree, visitor)
  File "/usr/lib/python2.5/compiler/visitor.py", line 63, in preorder
    self.dispatch(tree, *args) # XXX *args make sense?
  File "/usr/lib/python2.5/compiler/visitor.py", line 57, in dispatch
    return meth(node, *args)
  File "/usr/lib/shedskin/bin/cpp.py", line 500, in visitModule
    self.module_cpp(node)
  File "/usr/lib/shedskin/bin/cpp.py", line 411, in module_cpp
    self.class_cpp(child)
  File "/usr/lib/shedskin/bin/cpp.py", line 663, in class_cpp
    if getgx().merged_inh[var]:
KeyError: (static class Error, '__eq__')
dbm@zareason /home/dbm/bench/uploadSirikata> 

What version of the product are you using? On what operating system?
0.2, ubuntu 8.04

Please provide any additional information below.
this is a modified version of Python2.5 ftplib.py -- it works in pure python

Original issue reported on code.google.com by danbmi...@gmail.com on 7 Aug 2009 at 2:27

Attachments:

GoogleCodeExporter commented 8 years ago
thanks for reporting! I'm on vacation at the moment, but I will have a look 
after I
get back. in the meantime, it would help if you or anyone could minimize 
ftplib.py to
demonstrate this and possibly other problems..

Original comment by mark.duf...@gmail.com on 7 Aug 2009 at 12:46

GoogleCodeExporter commented 8 years ago
okay, I'm back and had a first quick look. I will try to hammer on this further,
until the generated C++ compiles..

I fixed the crash in SVN. shedskin then complained about socket.getaddrinfo 
being
absent. this is correct, because it currently cannot be supported (because of 
its
return type). after adding a stub, it then complained about 
socket.Socket.makefile
being absent. not sure why this one is missing (I didn't implement socket), but
stubbing this too allowed shedskin to finally generate C++ code. it still 
complained
about many functions not being called, but I guess this is because test() does 
not
(indirectly) call these, so that is probably fine. 

here's how I stubbed these functions:

(ftplib.py:)

def getaddrinfo(host, port, a, b, c=0, d=0):
    return [((0,0,0), ('', ('host', 0)))]
...
        for res in getaddrinfo(self.host, self.port, 0, socket.SOCK_STREAM):
            (af, socktype, proto), (canonname, sa) = res

(lib/socket.py:)

class Socket
...
        def makefile(self, flags=None):
            return file('', flags)

Original comment by mark.duf...@gmail.com on 15 Aug 2009 at 9:23

GoogleCodeExporter commented 8 years ago
btw, the final return element of getaddrinfo has a different type, depending on 
ipv4
or 6.. so even if shedskin supports longer tuples with mixed elements later on, 
this
still won't work correctly.

Original comment by mark.duf...@gmail.com on 15 Aug 2009 at 9:28

GoogleCodeExporter commented 8 years ago
the attached ftplib.py compiles to machine language, after applying the attached
socket.patch to shedskin SVN. it's probably not very useful with the two stubs, 
but I
guess you could call it progress.. :)

some changes are minor workarounds for found bugs, others for unsupported 
constructs
such as mixing int/None. you might want to diff with the original ftplib.py to 
see
the exact changes.

I will close this issue after fixing the found bugs (thanks for triggering 
this!),
and someone implements socket.Socket.makefile. thanks again for reporting!

Original comment by mark.duf...@gmail.com on 15 Aug 2009 at 11:48

Attachments:

GoogleCodeExporter commented 8 years ago
after some further investigation, I was able to minimize all (two) bugs.. I 
added the
following to the test set (unit.py). I will fix the real problems later (both 
look
like silly bugs that should be easy to fix).

# void *constant caused by unused function 
def parse150():
    a = '150'
def ftpcp():
    'ah' in ('150',)
parse150()

# callbacks
class FTP:
    def retrbinary(self, callback):
        callback('hoi')
    def retrlines(self):
        callback = print_line
        callback('hoi2')
def print_line(line):
    print line
ftp = FTP()
ftp.retrbinary(print_line)

Original comment by mark.duf...@gmail.com on 16 Aug 2009 at 10:57

GoogleCodeExporter commented 8 years ago
here's the final version of ftplib.py for now. it compiles fine with shedskin 
SVN,
although it still won't be very useful without a getaddrinfo implementation (and
socket.makefile) of course.

the first of the two bugs is fixed in SVN, and the second is not a real bug, or 
at
least a known problem: it uses 'print_line' above its definition. this can be
supported in most cases by looking ahead a bit, and I might look into this 
before the
next release (there were actually two cases of this in ftplib.py, so it might 
be a
useful thing to look into!)

so I'll keep this issue open until I decide what to do with the second bug and
possibly fix it, and there's a socket.makefile implementation. 

Original comment by mark.duf...@gmail.com on 23 Aug 2009 at 7:59

Attachments:

GoogleCodeExporter commented 8 years ago
the 'print-line' bug should work since 0.3. so we just need a socket.makefile
implementation to close this issue.

Original comment by mark.duf...@gmail.com on 17 Mar 2010 at 8:42

GoogleCodeExporter commented 8 years ago

Original comment by mark.duf...@gmail.com on 27 Mar 2010 at 10:11

GoogleCodeExporter commented 8 years ago
on second thought, nobody is going to add this based on the issue. let's just 
wait
until someone runs into the warning caused by this, and decides to do something 
about
it..

Original comment by mark.duf...@gmail.com on 16 May 2010 at 5:47