see inline...
On Fri, Sep 19, 2008 at 11:37 AM, William Cook
<william@xxxxxxxxx> wrote:
Dear DLTKers,
I am struggling to get a first release of my Scheme plugin done. It is going ok and I think it is almost done. But I am starting to feel very old... the level of complexity and indirection that is inherent in the Eclipse programming model is more than I have dealt with before (except perhaps when working with Smalltalk.. which is no surprise given where Eclipse came from). I tend to spend about 3 to 5 hours hunting around for the right spot to make a change, then I write 5 lines of code. Fortunately I am slowly getting faster as I learn the overall architecture. The last time I felt so stupid was when I learned COM.
Despite all the indirection, I find that it is very difficult to get the DLTK to do what I want. Here are some things I've tried to do. I've given up on the first three:
* Remove the concept of "debug engines". I think of debug engine setup as being part of an interpreter, not a separate concept. I wanted to remove the debug engine parts of the UI, but this seems difficult because it is burned into the core of DLTK.
the 'debug engine' is actually independent of the interpreter that is used. any debugging engine should be able to be used by any interpreter as long as the engine for that language implements the dbgp protocol.
if you don't want to offer debug support, just don't create any debug launch configurations and don't include any of the debugging preference pages.
* Get rid of the "system libraries" idea, which I don't think I want to mess with in my extension. I think this is impossible.
if you don't want to have any system libraries, you should be able to override the protected String retrivePaths(...) method in your AbstractInterpreterInstallType implementation to just return an empty string, and it should be treated as if no system libraries are installed (which i believe is a valid use case regardless).
* Add a field to the "new interpeter" setup dialog. This looks to be impossible without copying and replacing a large number of classes.
could you elaborate on this further? you have to add an implementation of AddScriptInterpreterDialog to your project anyway, so you should be able to override the createDialogFields() method to add a field to the wizard.
if that is not sufficent, i'm sure something could be done to accomidate you.
* Create a default interpreter setup, because I am going to include some interpreters inside my Scheme plugin update site. This lets the system be more easy to install. The setup needs to be created with code. It was a struggle, but I finally managed to make it work.
have you looked at the _javascript_ plugin? it comes bundled w/ the rhino interpreter already configured (although you do need to 'check' it in the preferences to enable, not sure if that is by design or a bug).
feel free to refactor the code into something more generic and submit a patch.
COMMENTS: One big source of problems it that many of the "new" calls within DLTK are hard-coded. Thus you cannot override classes very easily. A good dependency injection or factory model is sorely needed! On the one hand I think that DLTK could be much easier to use if it was more generic and allowed plugging in a few things for parsing (even the interpreter setup could be pretty much generic, i think). On the other hand, I want to disable features and this seems impossible.
could you elaborate further on this? there's no reason that these things can not be changed and/or made more flexible.
QUESTIONS: I have a few questions...
* How are we actually supposed to rely on DLTK? I see that DLTK is installed with Eclipse now, so that means we are not supposed to make changes to it when developing our plugins? That was always my assumption. But I am concerned about the versioning nightmare that will likely ensue as DLTK changes and all the languages try to stay in sync.
that depends - i currently do not have dltk installed into my main eclipse installation, instead i have the sources checked out and they are loaded into pde environment.
if you want to actively use dltk in your 'main' install, you can still develop new features against the head, you just need to make sure that when you launch the pde environment, you aren't including the dltk plugins that come bundled w/ eclipse and instead use those of the checked out source.
* I like DBGP but I'm unhappy about the (recent?) change to use its console interfaces rather than Eclipse standard consoles when debugging. I understand that this allows for remote debugging, which is neat. But I its going to cause more pain in my debug engine to try to get Scheme to use an alternative console. How hard would it be to have an option, as someone suggested?
i'm not familiar enough w/ the console interfaces to comment on this. i know that i haven't hooked into any dltk specific console classes, so unless something is happening under the hood, it seems that the regular eclipse consoles are used, even w/ remote debugging.
SUMMARY: I think DLTK is a great thing and hope that all dynamic language IDEs for Eclipse would use it. I would never have been able to make a Scheme debugger without the DLTK to handle the debugging stuff. I also find it very frustrating, but I don't have a broad enough perspective to really tell you how to do things differently.
William
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
