Closed GoogleCodeExporter closed 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
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
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
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:
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
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:
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
Original comment by mark.duf...@gmail.com
on 27 Mar 2010 at 10:11
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
Original issue reported on code.google.com by
danbmi...@gmail.com
on 7 Aug 2009 at 2:27Attachments: