I’ve made quite some progress the last days in the parser work for KDevelop4’s python support. That means the plugin itself doesn’t compile at all anymore :)
Thats quite ok, given that I’ve exchanged the parser generator (switched to the kdev-pg-qt) and that created a new AST from hand based on the Python 2.6 language reference. That new AST is closer to the actual structure of the code, whereas the generated AST is closer to how the language can be parsed. I’ve already started a AST builder that creates the new AST structure from the existing AST and also integrated that into the parser driver.
The result is sthat now the parser and its structures can be discarded as soon as the new AST structure is built. That should reduce memory overhead quite a bit as all the strings for tokens that are not used in the AST (like keywords, operators and such) are not held onto.
One hard small stumbling block was that kdev-pg and kdev-pg-qt didn’t initialize the token members in the generated AST. This results in them being initialized to 0. Obviously thats a proper token index in the token stream and you get a valid token and thus token text for that index. Unfortunately this means that whenever you have a rule like this: ( name=IDENTIFIER | 0 ) you need an extra boolean to store wether the member name actually was parsed or not.
The solution: Let kdev-pg-qt create proper initialization code. First attempt, done late last night (2-4 am) was obviously stupid and didn’t even get close to it. The right way was of course creating a new Generate-class that uses the visitor pattern to let the default visitor do the hard work of walking the kdev-pg-internal model and only hook into the variable declarations. In that part you have access to the member variable information and can print something like (*yynode)->name = -1;. This Generator put right after creating a new AST node solved my problem. Thats my 3rd feature contribution to kdev-pg(-qt), YAY :)
To close this post just a short note regarding the bashing going on on the dot: KDE4.0 is for enthusiasts, developers and eventually power users. Not for average joe who’s accustomed to kde3’s desktop and hesitant to change his habits. And quite frankly I don’t see that much of a difference between plasma and kde3 desktop from the users pov, its a taskbar with applets (or plasmoids, whatever), a desktop where you can put things (things being not only icons but also cool widgets) and a menu. And Aaron, before you get passionate again ;), I know the underlying technology is completely different and the abilities of plasma are way beyond what kicker and Co could ever deliver – but it really doesn’t look all that different at first glance.