Debugging support and more...
Steve
addressed with regards to debugging in 2.2. Will there be a break
point widget? Execution Stack widget? What will debugging look like
when 2.2 is done?
I was looking through some spyder code the other day and saw the
function open_in_spyder() that extracts the __file__ variable from a
module. Is there any chance that under some circumstances __file__
could be all lower case? Maybe that's somehow the cause of issues
#612 and #634? Just a random idea I thought I would throw out there.
Pierre Raybaut
> I'd like to get some clarification on what specific issues will be
Me too ;)
Actually this matter has not yet been discussed within the "development team".
Regarding v2.2, the next step is to freeze the v2.1 repository and
really switch to maintenance mode (we have introduced more features
than we should have done since v2.1.0: this is not improving
stability...). Then we may begin to work on v2.2. So we will have to
discuss the priorities depending on what we can do
(availability/skills) and on what we want to do. Anyway, I think that
our motivation is always a combination of what we like to do and of
what we need individually. So we'll see if someone will take care of
debugging features or not.
> addressed with regards to debugging in 2.2. Will there be a break
> point widget? Execution Stack widget? What will debugging look like
> when 2.2 is done?
>
> I was looking through some spyder code the other day and saw the
> function open_in_spyder() that extracts the __file__ variable from a
> module. Is there any chance that under some circumstances __file__
> could be all lower case? Maybe that's somehow the cause of issues
> #612 and #634? Just a random idea I thought I would throw out there.
No, this function is only used for a Spyder console (InternalShell)
embedded into a Qt application:. Thanks to this function, we can link
the console to the Spyder main window from which it was executed. More
precisely, when clicking on a traceback link within an embedded
Spyder's console, it opens the corresponding file at the right line
number within Spyder's editor.
-Pierre
> --
> You received this message because you are subscribed to the Google Groups "spyder" group.
> To post to this group, send email to spyd...@googlegroups.com.
> To unsubscribe from this group, send email to spyderlib+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/spyderlib?hl=en.
>
Carlos Córdoba
El 17/01/12 17:18, Pierre Raybaut escribió:
> 2012/1/17 Steve<steve.f....@gmail.com>:
>> I'd like to get some clarification on what specific issues will be
> Me too ;)
>
> Actually this matter has not yet been discussed within the "development team".
> Regarding v2.2, the next step is to freeze the v2.1 repository and
> really switch to maintenance mode (we have introduced more features
> than we should have done since v2.1.0: this is not improving
> stability...).
That's been me :-) Sorry for that... Since we have not discussed about
2.2 I thought I could add simple features to 2.1 (well, automatic quotes
have proven to be not so simple!).
Anyway, we could really freeze 2.1 whenever you feel is the right time
Pierre. I have in the making or as ideas a lot of things I would like to
see for 2.2:
1. Ipdb support for Ipython console
2. Add numpydoc and latex extensions to the Object Inspector
3. Add tabs and a homepage to the Object Inspector
4. Completely integrate ipython qtconsole in Spyder. For this we would
need to create a config page, add tabs to the plugin, send code from
the Editor and connect it to the Object Inspector and Variable Explorer
(I know this last one is working but kind of as a hack...)
5. Add a matlab-cell like feature.
6. Improve Rope introspection features (to avoid things like the bug
reported by Steve, where the Editor almost freezes during code completion)
> Then we may begin to work on v2.2. So we will have to
> discuss the priorities depending on what we can do
> (availability/skills) and on what we want to do. Anyway, I think that
> our motivation is always a combination of what we like to do and of
> what we need individually. So we'll see if someone will take care of
> debugging features or not.
Although I almost never use debugging (old school guy, who uses print's
all over the place) I think we could take a look at Pudb
(https://github.com/inducer/pudb) for ideas on how to create a good and
robust Debugging plugin.
Cheers,
Carlos
Carlos Córdoba
Before starting 2.2 we should really have to decide if we stay in
googlecode or switch to github, but let's discuss that in the other
thread we have about it
El 19/01/12 07:52, Carlos Córdoba escribió:
Steve
-Steve
On Thursday, January 19, 2012 6:56:24 AM UTC-6, Carlos Córdoba wrote:
Another thing I was forgetting:Before starting 2.2 we should really have to decide if we stay in
googlecode or switch to github, but let's discuss that in the other
thread we have about it
El 19/01/12 07:52, Carlos Córdoba escribió:
> Hi,
>
> El 17/01/12 17:18, Pierre Raybaut escribió:
>> 2012/1/17 Steve<>:
anatoly techtonik
Jed Ludlow
On Monday, April 30, 2012 1:01:08 AM UTC-6, anatoly techtonik wrote:
As far as I can tell this task is free to take. I've updated Roadmap page with a correct link to all the issues we currently have at http://code.google.com/p/spyderlib/issues/list?q=MS=v2.2
Carlos Córdoba
Cheers,
Carlos
El 26/04/12 10:14, Steve escribió:
To view this discussion on the web visit https://groups.google.com/d/msg/spyderlib/-/Yf2cNYQlIrUJ.
To post to this group, send email to spyd...@googlegroups.com.
To unsubscribe from this group, send email to spyderlib+...@googlegroups.com.
Carlos Córdoba
I can help you with reviews and testing. Please publish a bookmark and we can start to work from there. It'll be a great addition to the project because I think right now our weakest point is debugging.
Cheers,
Carlos
El 30/04/12 12:24, Jed Ludlow escribió:
On Monday, April 30, 2012 1:01:08 AM UTC-6, anatoly techtonik wrote:As far as I can tell this task is free to take. I've updated Roadmap page with a correct link to all the issues we currently have at http://code.google.com/p/spyderlib/issues/list?q=MS=v2.2
I have started work on a plugin to list breakpoints as suggested by issue 318 since having such a list would make troubleshooting work on issues 845, 955, 634, and 609 much easier. The first goal would be something very simple that simply provides a listing of the breakpoint dictionary straight from .spyder.ini. But I"ll be honest my time is very limited, and my progress will be probably be slow. If there is a willing collaborator that might speed things along. Anyone interested in pitching in?
--
You received this message because you are subscribed to the Google Groups "spyder" group.
To view this discussion on the web visit https://groups.google.com/d/msg/spyderlib/-/-OfCZXZLFQAJ.
To post to this group, send email to spyd...@googlegroups.com.
To unsubscribe from this group, send email to spyderlib+...@googlegroups.com.
anatoly techtonik
flow, threads/widgets creation and signal processing. I occasionally
get segfaults on the start, probably due to some race condition during
this phase.
It is very interesting to reverse Spyder bit by bit, but sometimes the
documentation is that I really want to see. Especially interprocess
socket communication protocol, which can easily deadlock on attempt to
reverse it by using print statements. My ideal long term wannabes to
speed up development are:
1. interactive debug <canvas> that visualizes Spyder start up
procedure and signals (processingjs in Qt HTML5 window, which receives
'pings' from probes scattered over the Spyder's body)
2. centralized debug panel for all signals (registration, processing, errors)
3. docs for communication protocol - with components, threads and examples
That will help A LOT. =) In exchange I will try to complete my draft
blog post for a better plugin API.
--
anatoly t.
Carlos Córdoba
seen segfaults because of it in a long time. At some point in the future
(maybe for 2.3?) I think it should be replaced with the IPython protocol
(when we totally integrate IPython qtconsole and notebook)
What will be the advantage of knowing in so much detail Spyder signals
and communication flow? Maybe to develop new plugins?
Cheers,
Carlos
El 30/04/12 21:29, anatoly techtonik escribió:
anatoly techtonik
debugging conflicts between plugins as well.
What protocol does IPython use? From
http://ipython.org/ipython-doc/dev/development/messaging.html it seems
they are using 0mq, which is an additional compiled extension.
--
anatoly t.
Carlos Córdoba
proper plugins, we need to add it (and also pyzmq) as deps. But as
everything in Spyder, I'm sure we could make it an optional dep.
Cheers,
Carlos
El 30/04/12 23:07, anatoly techtonik escribió:
Jed Ludlow
Ok, I've implemented a very simple breakpoint plugin. There are certainly some shortcomings to its current implementation, but it's getting the job done for today. It can be pulled from my clone at bookmark jedludlow-issue-318 here:
http://code.google.com/r/jedludlow-spyderlib-default/source/browse/?name=jedludlow-issue-318
I welcome any testing or code review. Additional notes on the implementation can be found in the discussion of Issue 318 here:
http://code.google.com/p/spyderlib/issues/detail?id=318
Feel free to clone my clone if you want to make any contributions.