When's it being released?
Been a while since I blogged at all - I've been up to my oxters in getting coPYcat running for presentation to the MSc committee, which brougt up a few "of course" points:
But more interesting than that was the actual transalation. I had a working version of copycat in Java by Scott Bolland and the original in Lisp by Melanie Mitchell. But I couldn't run the original because it depends on an ancient, propietary form of Lisp (Lucid Lisp), so old it is no longer available.
Of the two languages Java is closer to Python (at least syntactically), and I have more experience with it, so the first draft was just above the level of "copy and paste", with optimisation. (Early decision: I did not take over any of the GUI code).
After a few methods I started building vim macros, and by the end it became a much simpler operation: copy fred.java to fred.py, hit <F9>, and 95% of the translation was done. Then review the parts which need translation above lexical level. Then "pythonise" it (e.g. the vast majority of loops in Java could be translated into list comprehensions in Python).
Quick check at that point: the Python code had loadsa dumb errors. Being old and experienced does not always prevent the newbie errors. Ah well, on to debugging, and finding all the dumb errors, "<" for ">", that kind of thing. My commonest dumb mistake was the like of "if someObject.someFunction", instead of "if someObject.someFunction()". And, of course, Python has no problem with the former, but it's always True because the function exists.
Initial debugging was hampered by the stochastic nature of the parallel terraced scan (i.e. it is random), so I had to replace the random function in both versions which one which was non-random, ensuring that both programs followed the same paths in both debuggers. Luckily Scott had already written a pseudo-random function which only changed the seed, so I just copied that and clamped the seed.
Then tried to follow two debuggers down through two different versions of the same program at the same time. Programming doesn't get more fun that that !
And then the badly timed refactoring hit me: one line in the Python program is 10 in Java. And pydb (and idle) step through list comprehensions! You're looking at one line of source, but it gets stepped over 20 times - does your head in till you figure out what's going on.
A few more nights of head-banging and I now have a working version of copycat in Python. Not quite there yet - it is a lot slower (as in doing more work) than the Java version, and (probably related) is not choosing quite the same codelets. So I have a few more bruises on the head to go before I release the results of all this.
The results are two-fold: obviously a Python version of copycat, but much more interesting is the set of vim macros I constructed to help me along. They ain't polished enough to work in your version of vim yet, but I'll hope to find the time for that, and I've started a second collection, which help with refactoring Python code.
Now there's a tail for another post! Refactoring Python code in vim - definitely something to live up to the title of the blog. Vim macros are a good start, but the interpreted nature of Python sure seem to make it a harder problem than JetBrains faced. Guess that's why the macro collection may take a while to release - for every one of them I can think of Python code that means they don't work. "Most of the time" is good enough for me, not you.
And what he said about vim here is a spur to keep thinking about it
(Yes - I am aware of the Bicycle Repair Man, but he didn't fix my bike, YMMV)
- Of course I only got it working in the wee hours of deadline day
- Of course it doesn't actually work fully
- Of course the real horrible bug turned out to be something silly
- Of course they weren't actually interested in the running program
But more interesting than that was the actual transalation. I had a working version of copycat in Java by Scott Bolland and the original in Lisp by Melanie Mitchell. But I couldn't run the original because it depends on an ancient, propietary form of Lisp (Lucid Lisp), so old it is no longer available.
Of the two languages Java is closer to Python (at least syntactically), and I have more experience with it, so the first draft was just above the level of "copy and paste", with optimisation. (Early decision: I did not take over any of the GUI code).
After a few methods I started building vim macros, and by the end it became a much simpler operation: copy fred.java to fred.py, hit <F9>, and 95% of the translation was done. Then review the parts which need translation above lexical level. Then "pythonise" it (e.g. the vast majority of loops in Java could be translated into list comprehensions in Python).
Quick check at that point: the Python code had loadsa dumb errors. Being old and experienced does not always prevent the newbie errors. Ah well, on to debugging, and finding all the dumb errors, "<" for ">", that kind of thing. My commonest dumb mistake was the like of "if someObject.someFunction", instead of "if someObject.someFunction()". And, of course, Python has no problem with the former, but it's always True because the function exists.
Initial debugging was hampered by the stochastic nature of the parallel terraced scan (i.e. it is random), so I had to replace the random function in both versions which one which was non-random, ensuring that both programs followed the same paths in both debuggers. Luckily Scott had already written a pseudo-random function which only changed the seed, so I just copied that and clamped the seed.
Then tried to follow two debuggers down through two different versions of the same program at the same time. Programming doesn't get more fun that that !
And then the badly timed refactoring hit me: one line in the Python program is 10 in Java. And pydb (and idle) step through list comprehensions! You're looking at one line of source, but it gets stepped over 20 times - does your head in till you figure out what's going on.
A few more nights of head-banging and I now have a working version of copycat in Python. Not quite there yet - it is a lot slower (as in doing more work) than the Java version, and (probably related) is not choosing quite the same codelets. So I have a few more bruises on the head to go before I release the results of all this.
The results are two-fold: obviously a Python version of copycat, but much more interesting is the set of vim macros I constructed to help me along. They ain't polished enough to work in your version of vim yet, but I'll hope to find the time for that, and I've started a second collection, which help with refactoring Python code.
Now there's a tail for another post! Refactoring Python code in vim - definitely something to live up to the title of the blog. Vim macros are a good start, but the interpreted nature of Python sure seem to make it a harder problem than JetBrains faced. Guess that's why the macro collection may take a while to release - for every one of them I can think of Python code that means they don't work. "Most of the time" is good enough for me, not you.
And what he said about vim here is a spur to keep thinking about it
(Yes - I am aware of the Bicycle Repair Man, but he didn't fix my bike, YMMV)
posted by Alan at 6:12 p.m.
0 Comments:
Post a Comment
<< Home