Thread: [Pydev-code] PyDev 0.9.8.2 released
Brought to you by:
fabioz
From: Fabio Z. <fa...@es...> - 2005-09-26 17:19:48
|
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.2 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.2 Major highlights: ------------------------ * Content assistants reviewed (and better documented on the homepage -- I really reccomend checking it) * Timeout parsing options added (this is available in the builder preferences page) * Auto-dedent added Others that are new and noteworthy: ----------------------------------------------------- * .pyc is removed when the corresponding .py file is removed. * Debugger has been changed so that it becomes faster (still not as fast as I would like, but still... faster) -- looking for people with expertise on this to help me, as I'm kind of lost on which should be the 'recommended' way to speed it more. * Some escaped quotes problems fixed when formatting code * Navigation with Ctrl+Shift+ (up or down) has been slightly improved, so that it goes to the start or the end of the file when no other class or method declaration is found * Other bug-fixes (as ususal) Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com |
From: Aleks T. <a...@to...> - 2005-09-27 23:03:57
|
Fabio Zadrozny wrote: > Hi All, > > PyDev - Python IDE (Python Development Enviroment for Eclipse) version > 0.9.8.2 has been released. > * .pyc is removed when the corresponding .py file is removed. > * Debugger has been changed so that it becomes faster (still not as > fast as I would like, but still... faster) -- looking for people with > expertise on this to help me, as I'm kind of lost on which should be the > 'recommended' way to speed it more. Not sure what are you doing with the debugger right now. The major cause of slowness used to be transfer of variables. This was particularly painful when a file imported many packages. Since everything in Python is global, we'd transfer 1000s of variables encoded as XML. This can be speeded up a lot by loading only "local" variables. Once the breakpoint is hit, use the editor model to figure out what the local variables are, and transfer only those values initially. Cheers, Aleks |
From: Fabio Z. <fa...@gm...> - 2005-09-27 23:26:17
|
Hi Aleks, nice to hear from you :-) Actually, after checking it more, the xml is not actually the slowest part as it seems at first... mainly because it is executed only on breakpoints..= . The bad part is the way the global tracing function is set, analyzing contexts that it should not even know about (that's the trace_dispatch function)... it almost always return itself to debug on other contexts, whe= n it should return almost always 'None' and just return itself on valid contexts... (you can actually 'feel' that when you put a large program to run... it could take a lot of time just to get at the first breakpoint.) I think that actually making an asynchronous debbuging, so that the communication would be on a non profiled thread and making the breaks just where needed would do the trick, but I'm unsure of how should this work if the user sets some breakpoint after we returned None in the trace_dispatch... Also, that would probably require heavy changes in the structure being used, so, I want to be sure that this is the right way to d= o it, before jumping at it... jython is also a concern, since I'm not sure if it works exactly as python on that... The xml part could also be improved as you said, but I don't think it is th= e slowest part right now :-) Cheers, Fabio On 9/27/05, Aleks Totic <a...@to...> wrote: > > Fabio Zadrozny wrote: > > Hi All, > > > > PyDev - Python IDE (Python Development Enviroment for Eclipse) version > > 0.9.8.2 <http://0.9.8.2> has been released. > > * .pyc is removed when the corresponding .py file is removed. > > * Debugger has been changed so that it becomes faster (still not as > > fast as I would like, but still... faster) -- looking for people with > > expertise on this to help me, as I'm kind of lost on which should be th= e > > 'recommended' way to speed it more. > > Not sure what are you doing with the debugger right now. The > major cause of slowness used to be transfer of variables. This > was particularly painful when a file imported many packages. > Since everything in Python is global, we'd transfer 1000s of > variables encoded as XML. > > This can be speeded up a lot by loading only "local" variables. > Once the breakpoint is hit, use the editor model to figure out > what the local variables are, and transfer only those values > initially. > > Cheers, > > Aleks > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Pydev-code mailing list > Pyd...@li... > https://lists.sourceforge.net/lists/listinfo/pydev-code > |
From: Rocky B. <ro...@se...> - 2005-10-09 13:35:46
|
I've been trying to run (without modifying any pydev) Zope2.8 in the debugger. The slowness of the debugger renders this a useless task (I waited 15min for Zope to stop initializing and then gave up... although I did see that it was making some progress it was just too slow). So separately from this I decided to run my zope unit tests through the debugger (doesn't actually have to load up zope and the tons of packages) but even that was horribly, painfully slow. Bottom-line right now is that if I really really need to, I'll launch the debugger to run a unit test... otherwise I steer far away from the debugger. Here's a question, have any of you considered integrating rpdb2 (http://www.digitalpeers.com/pythondebugger/) with PyDev? From my experience with using it locally it was very very fast (didn't notice much of a speed difference between running in debug mode versus not in debug mode). - Rocky Fabio Zadrozny wrote: > Hi Aleks, nice to hear from you :-) > > Actually, after checking it more, the xml is not actually the slowest > part as it seems at first... mainly because it is executed only on > breakpoints... The bad part is the way the global tracing function is > set, analyzing contexts that it should not even know about (that's the > trace_dispatch function)... it almost always return itself to debug on > other contexts, when it should return almost always 'None' and just > return itself on valid contexts... (you can actually 'feel' that when > you put a large program to run... it could take a lot of time just to > get at the first breakpoint.) > > I think that actually making an asynchronous debbuging, so that the > communication would be on a non profiled thread and making the breaks > just where needed would do the trick, but I'm unsure of how should this > work if the user sets some breakpoint after we returned None in the > trace_dispatch... Also, that would probably require heavy changes in the > structure being used, so, I want to be sure that this is the right way > to do it, before jumping at it... jython is also a concern, since I'm > not sure if it works exactly as python on that... > > The xml part could also be improved as you said, but I don't think it is > the slowest part right now :-) > > Cheers, > > Fabio > > On 9/27/05, *Aleks Totic* <a...@to... <mailto:a...@to...>> wrote: > > Fabio Zadrozny wrote: > > Hi All, > > > > PyDev - Python IDE (Python Development Enviroment for Eclipse) > version > > 0.9.8.2 <http://0.9.8.2> has been released. > > * .pyc is removed when the corresponding .py file is removed. > > * Debugger has been changed so that it becomes faster (still > not as > > fast as I would like, but still... faster) -- looking for people with > > expertise on this to help me, as I'm kind of lost on which should > be the > > 'recommended' way to speed it more. > > Not sure what are you doing with the debugger right now. The > major cause of slowness used to be transfer of variables. This > was particularly painful when a file imported many packages. > Since everything in Python is global, we'd transfer 1000s of > variables encoded as XML. > > This can be speeded up a lot by loading only "local" variables. > Once the breakpoint is hit, use the editor model to figure out > what the local variables are, and transfer only those values > initially. > > Cheers, > > Aleks > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Pydev-code mailing list > Pyd...@li... > <mailto:Pyd...@li...> > https://lists.sourceforge.net/lists/listinfo/pydev-code > > -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://serverzen.net |
From: Fabio Z. <fa...@gm...> - 2005-10-10 11:19:51
|
Hi Rocky, well, you can take a look at my blog ( http://pydev.blogspot.com/2005/10/high-speed-debugger.html) for some comments on the debugger... please, test it after the new release to see if it suits your needs... And also, yes, I have considered integrating rpdb2, but its license is not compatible to the pydev license (it is gpl, and pydev is cpl... I would not like to change its license just to integrate another debugger, especially considering that the debugger will already be much faster in the next release). Cheers, Fabio On 10/9/05, Rocky Burt <ro...@se...> wrote: > > > I've been trying to run (without modifying any pydev) Zope2.8 in the > debugger. The slowness of the debugger renders this a useless task (I > waited 15min for Zope to stop initializing and then gave up... although > I did see that it was making some progress it was just too slow). > > So separately from this I decided to run my zope unit tests through the > debugger (doesn't actually have to load up zope and the tons of > packages) but even that was horribly, painfully slow. > > Bottom-line right now is that if I really really need to, I'll launch > the debugger to run a unit test... otherwise I steer far away from the > debugger. > > Here's a question, have any of you considered integrating rpdb2 > (http://www.digitalpeers.com/pythondebugger/) with PyDev? From my > experience with using it locally it was very very fast (didn't notice > much of a speed difference between running in debug mode versus not in > debug mode). > > > - Rocky > > > > Fabio Zadrozny wrote: > > Hi Aleks, nice to hear from you :-) > > > > Actually, after checking it more, the xml is not actually the slowest > > part as it seems at first... mainly because it is executed only on > > breakpoints... The bad part is the way the global tracing function is > > set, analyzing contexts that it should not even know about (that's the > > trace_dispatch function)... it almost always return itself to debug on > > other contexts, when it should return almost always 'None' and just > > return itself on valid contexts... (you can actually 'feel' that when > > you put a large program to run... it could take a lot of time just to > > get at the first breakpoint.) > > > > I think that actually making an asynchronous debbuging, so that the > > communication would be on a non profiled thread and making the breaks > > just where needed would do the trick, but I'm unsure of how should this > > work if the user sets some breakpoint after we returned None in the > > trace_dispatch... Also, that would probably require heavy changes in th= e > > structure being used, so, I want to be sure that this is the right way > > to do it, before jumping at it... jython is also a concern, since I'm > > not sure if it works exactly as python on that... > > > > The xml part could also be improved as you said, but I don't think it i= s > > the slowest part right now :-) > > > > Cheers, > > > > Fabio > > > > On 9/27/05, *Aleks Totic* <a...@to... <mailto:a...@to...>> wrote: > > > > Fabio Zadrozny wrote: > > > Hi All, > > > > > > PyDev - Python IDE (Python Development Enviroment for Eclipse) > > version > > > 0.9.8.2 <http://0.9.8.2> <http://0.9.8.2> has been released. > > > * .pyc is removed when the corresponding .py file is removed. > > > * Debugger has been changed so that it becomes faster (still > > not as > > > fast as I would like, but still... faster) -- looking for people with > > > expertise on this to help me, as I'm kind of lost on which should > > be the > > > 'recommended' way to speed it more. > > > > Not sure what are you doing with the debugger right now. The > > major cause of slowness used to be transfer of variables. This > > was particularly painful when a file imported many packages. > > Since everything in Python is global, we'd transfer 1000s of > > variables encoded as XML. > > > > This can be speeded up a lot by loading only "local" variables. > > Once the breakpoint is hit, use the editor model to figure out > > what the local variables are, and transfer only those values > > initially. > > > > Cheers, > > > > Aleks > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: > > Power Architecture Resource Center: Free content, downloads, > > discussions, > > and more. http://solutions.newsforge.com/ibmarch.tmpl > > _______________________________________________ > > Pydev-code mailing list > > Pyd...@li... > > <mailto:Pyd...@li...> > > https://lists.sourceforge.net/lists/listinfo/pydev-code > > > > > > > -- > Rocky Burt > ServerZen Software -- http://www.serverzen.com > ServerZen Hosting -- http://www.serverzenhosting.net > News About The Server -- http://serverzen.net > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Pydev-code mailing list > Pyd...@li... > https://lists.sourceforge.net/lists/listinfo/pydev-code > |
From: Fabio Z. <fa...@es...> - 2005-10-13 15:39:31
|
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.3 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.3 Major highlights: ------------------------ * Debugger was improved to be faster (more info about it at my blog <http://pydev.blogspot.com/2005/10/high-speed-debugger.html> -- http://pydev.blogspot.com/2005/10/high-speed-debugger.html) * The debugger is now getting info correctly on java classes when debugging jython * Add watch added to the editor popup menu * Added syntax highlighting to the 'self' token * Code folding added for 'glued' imports * Fixed some outline problems Others that are new and noteworthy: ----------------------------------------------------- * Debugger does not try to get breakpoints on closed projects anymore * Some refreshing issues regarding the outline and colors when reusing the editor were fixed * Code completion for relative imports has changed a lot (there were some pretty hard-to-find bugs in this area...) * Some move imports problems fixed * The auto-add '(self):' now works with tabs too Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com |
From: Fabio Z. <fa...@es...> - 2005-11-03 16:46:01
|
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.4 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.4 Major highlights: ------------------------ * The license was changed to EPL. It can be found at: http://www.opensource.org/licenses/eclipse-1.0.php * Code-completion information is now saved in deltas instead of "saving only at shutdown" (being so, it does not loose information if it does not have a regular shut-down). Others that are new and noteworthy: ----------------------------------------------------- * Added option for not using the smart-indent after opening brackets * Some step-by-step instructions of how to get started with pydev have been contributed by Jack Trainor. * Many bugfixes Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com |
From: Fabio Z. <fa...@es...> - 2005-11-17 15:42:05
|
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.5 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.5 Major highlights: ------------------- * Removed the dependency on packages 'sun.xxxx.Base64', so that other VMs can be targetted * Some code-completion problems in the 'resolution order' regarding tokens in __init__ were solved * Added option so that the user can choose whether to automatically add 'self' or not in method declarations Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com |
From: Fabio Z. <fa...@es...> - 2006-01-10 11:11:49
|
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.6 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.6: Major highlights: ------------------- * Added a new 'Pydev project' wizard (Mikko Ohtamaa contribution) -- it is named as Pydev Project instead of Python project because it creates Python and Jython projects. * Added a new 'Pydev module' wizard (Mikko Ohtamaa contribution) -- NOTE: it still needs some work. * Changes in the shell spawning were done, and no hangs should appear when trying to do code-completion anymore (if it still hapens, please report it as a bug -- NOTE: a little delay on the first time code-completion is executed is expected, as this is the time the shell is started). * Other bugfixes (as usual) Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com |
From: Fabio Z. <fa...@es...> - 2006-01-17 15:56:23
|
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.7 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.7: Major highlights: * The debugger tracing was turned off (this was a bug in 0.9.8.6 and could make debugging much slower) * Fixed jython shell (and extended it to get better information on code-completion). * Changed the interpreter configuration so that it is backwards-compatible from now on...(but the current interpreters will be lost and will need to be configured) * Breakpoints can have conditionals(this was contributed by Achim Nierbeck, and was actually provided in release 0.9.8.6, but I forgot to put it in the release notes) * Some other bugfixes are also in this build. Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com |
From: Fabio Z. <fa...@es...> - 2006-02-06 17:41:12
|
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 1.0 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 1.0 Yeap, that's right, Pydev has reached its 'adulthood', so... enjoy it! Major highlights: ----------------------- * High-speed Debugger (on par with the best debuggers available) * Debugger now gets the variables 'on-demand' * The variables returned for jython are much more complete * Wizard to create new project has option for creating a default 'src' folder (and add it to the pythonpath). * The create new python module and new python package have been reviewed (you can still use the regular ones, but the new ones are really reccommended -- also it will help in making sure you have your pythonpath correctly configured!). * Create new source folder option added. * Pylint can now give the output to the console (configurable). * Pylint 0.9.0 tested * Pylint errors now show in the hover * The Pydev perspective was changed (so, please, close the current and ro-open it) * Templates were added for the keywords * Keybindings were added to run the current editor as python (F9) or as jython (Ctrl+F9). Those are customizable in the 'keys' preferences * And many other bug-fixes as usual Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com |
From: Fabio Z. <fa...@es...> - 2006-02-06 17:54:00
|
Hi All, Pydev Extensions 1.0 has been released Check the homepage (http://www.fabioz.com/pydev/) for more details. Pydev Extensions is a commercial product, and works with Eclipse and the Pydev "Open Source" version, and has features such as: * Code completion with auto-import * Code analysis (PyLint replacement, but much faster) * Quick-Fix for problems found in code analysis * Go to definition (Bycicle Repair Man replacement, but much more reliable) * Debug server (allows debugging scripts not lauched from within Eclipse) * Keywords presented as auto-completions as you type * Quick-outline Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com |
From: Fabio Z. <fa...@es...> - 2006-02-07 10:02:55
|
Hi All, Pydev Extensions version 1.0.1 has been released More details at http://www.fabioz.com/pydev Pydev - Python IDE (Python Development Enviroment for Eclipse) version 1.0.1 has been released. More details at http://pydev.sf.net Details for Release: 1.0 .1: This was a 'single bug' release (it fixes an out-of-memory error when restoring the interpreter). Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br Pydev Extensions http://www.fabioz.com/pydev PyDev - Python Development Enviroment for Eclipse http://pydev.sf.net http://pydev.blogspot.com |
From: Fabio Z. <fa...@es...> - 2006-02-16 16:30:36
|
Hi All, Pydev and Pydev Extensions 1.0.2 have been released Check http://www.fabioz.com/pydev for details on Pydev Extensions and http://pydev.sf.net has for details on Pydev Highlights in Pydev Extensions: ------------------------------- - New feature in the debugger: the console is available for probing when in 'suspendend mode' - New feature in code analysis: Provided a way to consider tokens that should be in the globals - Halt fix when too many matches where found in the go to definition. - Code analysis minor bugs fixed. - Error when opening browser fixed. Highlights in Pydev: ----------------------- - Jython debugging now working. - Code coverage does not report docstrings as not being executed. - Freeze when making a 'step-in' fixed in the debugger. - Grammar generated with javacc version 4.0 Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br Pydev Extensions http://www.fabioz.com/pydev PyDev - Python Development Enviroment for Eclipse http://pydev.sf.net http://pydev.blogspot.com |
From: Bill B. <wb...@gm...> - 2006-02-17 01:02:26
|
Hi there, On 2/17/06, Fabio Zadrozny <fa...@es...> wrote: > > > - New feature in the debugger: the console is available for probing when > in 'suspendend mode' > > This is a pretty great addition. How hard would it be to make it act mor= e like a full-featured shell? I.e., - have a promt so you can tell tell that it's waiting for your input, - respond after just one 'enter' instead of two, - print out the value of variables by just typing the variable name (instea= d of having to type "print variable_name") - cycle through your command history with keys like up/down-arrow or ctrl-up/down-arrow - auto-completion of symbols Ideally it would be nice to just have something like pycrust right there in a tab instead of "Console". Stani's Python Editor has pycrust built-in lik= e that, but unfortunately it's not connected in any way to your executing program, so it's not so useful. The ultimate debugger, based on debuggers I'm familiar with, would be a hybrid of that in VisualStudio crossed with Matlab. VisualStudio does variable and watches nicely. It's got a list (several lists actually) like Eclipse's 'Expressions', but you can double click to add a new expression o= r edit an expression. Eclipse is pretty close there, just needs a more efficient way to edit the expressions. The Matlab debugger, on the other hand, completely lacks an expression list, but its best feature is that whe= n you hit a breakpoint, you just have your normal interactive shell prompt there with all it's features, plus all your program's state loaded in memory. This is an excellent debugging model for a dynamic programming language in my opinion. If there's some error on the current line, you can quickly try out a bunch of variations to figure out what the proper expression is to get the result you want, using the actual data from your program, without having to cook up a stand-alone test case that creates dat= a similar to what's in your program. Regards, Bill Baxter |
From: Fabio Z. <fa...@gm...> - 2006-02-17 09:56:48
|
On 2/16/06, Bill Baxter <wb...@gm...> wrote: > > Hi there, Hi Bill, On 2/17/06, Fabio Zadrozny <fa...@es...> wrote: > > > > > > - New feature in the debugger: the console is available for probing whe= n > > in 'suspendend mode' > > > > This is a pretty great addition. How hard would it be to make it act > more like a full-featured shell? I.e., > - have a promt so you can tell tell that it's waiting for your input, Should not be so hard... - respond after just one 'enter' instead of two, The problem is that I have to pass the complete thing to the debugger because it will do an exec in your code, so, if you want to define somethin= g as: def method1(): print 'foo' You could not do, because the exec would pass right on the 'def method1():'= , and you need it only after you defined the whole method... That's so that you can do things like the below in the debugger: class D: def m1(self): print 'here' d =3D D() print d <__main__.D instance at 0x0A6D0E90> I could still make an option to respond after a single-line, but then you'd not be able to do multi-line statements... Anyway, I could do some more research to see if there's someway that can make multi-line statements and keep the simplicity of single line statements... Something as a buffer, that determines when it should evaluat= e the whole thing... maybe as the real console, that detects when it is a multiline and only then passes to the 'eval on new line' approach. - print out the value of variables by just typing the variable name (instea= d > of having to type "print variable_name") Probably doable - cycle through your command history with keys like up/down-arrow or > ctrl-up/down-arrow I'll need to check if I can override the default Eclipse console used for run... Probably hard though (I had to hack my way into Eclipse just to be able to grab the input)... - auto-completion of symbols Same as the one before Ideally it would be nice to just have something like pycrust right there in > a tab instead of "Console". Stani's Python Editor has pycrust built-in l= ike > that, but unfortunately it's not connected in any way to your executing > program, so it's not so useful. Well, I'll soon have a replacement for pycrust, to help you do 'quick-scripts' in a scrap-page... something as the java scrap-page, but I'll have to see how to connect it to the debugger shell. The ultimate debugger, based on debuggers I'm familiar with, would be a > hybrid of that in VisualStudio crossed with Matlab. VisualStudio does > variable and watches nicely. It's got a list (several lists actually) li= ke > Eclipse's 'Expressions', but you can double click to add a new expression= or > edit an expression. Eclipse is pretty close there, just needs a more > efficient way to edit the expressions. The Matlab debugger, on the other > hand, completely lacks an expression list, but its best feature is that w= hen > you hit a breakpoint, you just have your normal interactive shell prompt > there with all it's features, plus all your program's state loaded in > memory. Well, I hope I'll get to there ;-) This is an excellent debugging model for a dynamic programming language in > my opinion. If there's some error on the current line, you can quickly t= ry > out a bunch of variations to figure out what the proper expression is to = get > the result you want, using the actual data from your program, without hav= ing > to cook up a stand-alone test case that creates data similar to what's in > your program. Agreed... but I'd probably do the stand-alone test-cases anyway ;-) Regards, > Bill Baxter > Regards, Fabio Zadrozny |
From: Bill B. <wb...@gm...> - 2006-02-20 00:13:41
|
Howdy, - respond after just one 'enter' instead of two, > > > The problem is that I have to pass the complete thing to the debugger > because it will do an exec in your code, so, if you want to define someth= ing > as: > > def method1(): > print 'foo' > > You could not do, because the exec would pass right on the 'def > method1():', and you need it only after you defined the whole method... > That's so that you can do things like the below in the debugger: > class D: > def m1(self): > print 'here' > > d =3D D() > print d > > <__main__.D instance at 0x0A6D0E90> > > I could still make an option to respond after a single-line, but then > you'd not be able to do multi-line statements... > Anyway, I could do some more research to see if there's someway that can > make multi-line statements and keep the simplicity of single line > statements... Something as a buffer, that determines when it should evalu= ate > the whole thing... maybe as the real console, that detects when it is a > multiline and only then passes to the 'eval on new line' approach. > What's wrong with how most shells do it (IDLE, pycrust, standard command line interactive shell) ? I'm not sure how it's implemented, but basically if the line you type is a complete statement all by itself, then it's executed, otherwise you get a different "continuation" prompt and indented lines to type the rest of the function. Maybe there's a special exception thrown to indicate an incomplete statement? - cycle through your command history with keys like up/down-arrow or > > ctrl-up/down-arrow > > > I'll need to check if I can override the default Eclipse console used for > run... Probably hard though (I had to hack my way into Eclipse just to be > able to grab the input)... > Maybe there's a way to make it a completely separate panel type rather than piggy-backing on the console? (Of course, I don't know anything about Eclipse internals so that may just be impossible). Keep up the good work! --Bill Baxter |
From: Fabio Z. <fa...@gm...> - 2006-02-20 00:55:09
|
> > > > I'll need to check if I can override the default Eclipse console used > > for run... Probably hard though (I had to hack my way into Eclipse just= to > > be able to grab the input)... > > > > Maybe there's a way to make it a completely separate panel type rather > than piggy-backing on the console? (Of course, I don't know anything abo= ut > Eclipse internals so that may just be impossible). > Yeap... probably making my own shell instead of the one Eclipse uses would make it easier... it's api still does not make it possible (and I wonder if it ever will). Keep up the good work! > > --Bill Baxter > > Cheers, Fabio |
From: Bill B. <wb...@gm...> - 2006-02-20 01:31:23
|
On 2/20/06, Fabio Zadrozny <fa...@gm...> wrote: > > > > Yeap... probably making my own shell instead of the one Eclipse uses woul= d > make it easier... it's api still does not make it possible (and I wonder = if > it ever will). > I don't know much about Eclipse (I just downloaded it to try out pydev), bu= t I thought it was supposed to be a pretty generic IDE backbone. If that's the case then you'd think they'd be interested in providing good core support for the many dynamic interpreted languages that are out there. The features you want (and we users are asking for) are the same ones one would want in a debugger for any interpreted language, perl, ruby, python, etc. = I can't imagine that the Eclipse developers would refuse to add a few API hooks here and there if it makes support for those languages better. Or is it more like a generic backbone in theory, but in practice all the developers are mostly Java users, so that's all any of them care about supporting? --bb |
From: Fabio Z. <fa...@gm...> - 2006-02-20 01:55:17
|
Actually, I think they'll probably add support, but the problem is 'when'..= . Also, in the eclipse development, they start with java, and extend as requests come... in my case, the request was deffered for the next release = ( 3.2), but they gave no mention on when would it be implemented... Also, there's a generic core, but it is not so generic as one would expect... I mean for basic stuff, it really gives a good support, but after you want things that where not initially thought of, it might be kind of tricky to get it... So, you'll usually end up with a lot of code, just trying to get rid of some indirection layers they put in the way ;-) In the end, I think they do have interest in making those APIs, the problem seems to be that the 'process' they have to keep things in order slows it down much more than it should... I mean, I had a request, implemented the code to do what I asked, submitted it, and they didn't add it to the core API because it was the last day for API changes in the 3.2 release... so, that makes that request frozen for a some months until they do consider it again ;-( Unfortunatelly, what keeps happening over and over again is that I really have to 'hack' Eclipse to get what I want from it... on the other way, fortunatelly, the code is all there so that I *can* hack it ;-) Cheers, Fabio On 2/19/06, Bill Baxter <wb...@gm...> wrote: > > On 2/20/06, Fabio Zadrozny <fa...@gm...> wrote: > > > > > > > > Yeap... probably making my own shell instead of the one Eclipse uses > > would make it easier... it's api still does not make it possible (and I > > wonder if it ever will). > > > > I don't know much about Eclipse (I just downloaded it to try out pydev), > but I thought it was supposed to be a pretty generic IDE backbone. If > that's the case then you'd think they'd be interested in providing good c= ore > support for the many dynamic interpreted languages that are out there. T= he > features you want (and we users are asking for) are the same ones one wou= ld > want in a debugger for any interpreted language, perl, ruby, python, etc.= I > can't imagine that the Eclipse developers would refuse to add a few API > hooks here and there if it makes support for those languages better. > > Or is it more like a generic backbone in theory, but in practice all the > developers are mostly Java users, so that's all any of them care about > supporting? > > --bb > > |