Posted
5 days
ago
by
martinkonicek
Hi,
my name is Martin Konicek and starting this summer, I will be trying to make your debugging experience in SharpDevelop even better. This blog will be about my project for Google summer of code 2009 - Debugger visualizers. The exciting
... [More]
part is that I'll be working on features that are not present in any IDE today.
Motivation
The idea is to introduce new ways to let you observe the state of the program during debugging. For me, by far the most used debugger feature are the tooltips. The problem with tooltips is they never show you the data structure "as a whole". Here we have two objects having a reference to each other:
As we can see, the tooltips can be expanded forever, even if we have only two objects forming a loop - there is no easy was to tell this information just from the tooltips. Long ago, I was thinking how gain more insight - what about displaying the objects in memory and references between them as an oriented graph, updating live when stepping in the debugger? I wrote it as a hobby project, which gave me important lessons how not to do that.
Object graph visualizer
I found out that SharpDevelop team had similar idea for Google summer of code, great! I applied, researched and wrote a prototype, which I sent to David Srbecky, the author of SharpDevelop debugger and my mentor. The prototype looked like this:
In the picture, the visualizer (right) shows all objects that can be reached from variable "a" in the program being debugged (left).
There is one more visualizer that is totally missing in today's
IDEs in my opinion, and will be implemented. About that, next time.
Bio
I'm 23, from the Czech Republic, currently studying CS at Charles University in the beautiful city of Prague. I think .NET is great, I have used it as my primary platform for a couple of years now. I'm teaching basics of programming to freshmen at our university - I recommend this to everyone, it's a great experience. I have a personal programming blog here.
Stay tuned for updates.. [Less]
Posted
about 1 month
ago
by
MattWard
With
SharpDevelop 3.1 you can now debug IronPython code with the
IronPython Interpreter (ipy.exe).
Before you start make sure the debugger is set to use the
Just My Code feature. From the Tools menu select Options
... [More]
and
then click the Debugging category.
Ensure that the Just My Code feature is checked and that
the Step over code without symbols is not checked. If the
Step over code without symbols option is selected then stepping
will not work properly and lines of code will be skipped over.
There are two ways to debug your code. You can use the Python
menu or modify the project options. We will look at both of these
alternatives. First open your IronPython project into SharpDevelop.
Open your main file and make sure it is the active text editor
window. Set a breakpoint somewhere in your code. Then from the
Python menu select Run.
This will start ipy.exe which will run your code and the
debugger should stop the execution at the breakpoint.
From this point you can do the usual debugging activities such
as stepping through your code, viewing the callstack, adding items
to the watch window, etc.
If you want to use a different ipy.exe then this can be
specified in the Python Options dialog (Tools menu | Options).
To enable debugging when you press F5 or select the Debug Run
menu option you can modify the project options. From the Projects
menu select Project Options and then open the Debug tab. Here you
should change the Start Action to Start external program and
use the browse button to locate ipy.exe. In the Start Options add
the following command line arguments, changing the name of your
main file as required.
-D ${ProjectDir}\Program.py
Once these changes are saved you can then press F5 and ipy.exe
will be run under the debugger instead of running the compiled
executable.3
Issues
No support for debugging the executable produced by the
IronPython compiler since it does not produce debug symbols (i.e.
.pdb files).
When using ipy.exe you need to add references to .NET
assemblies explicitly in your code except for System which is
included by default. For example:
import clr
clr.AddReference("System.Windows.Forms")
Thanks
Thanks to
David
Srbecky, SharpDevelop's debugger expert and maintainer,
for reviewing the code changes I wanted to make to the debugger and
making sure nothing was broken. Adding support for debugging
IronPython was straightforward and required 10-15 lines of new code
thanks to the code already written by David.
Thanks also to Harry Pierson
(IronPython Program Manager at Microsoft) who has written a great
set of blog posts on
creating an IronPython debugger in IronPython which gave me the
reason why SharpDevelop's debugger was not working when
debugging IronPython code. [Less]
Posted
about 1 month
ago
by
MattWard
Support for designing Windows Forms in IronPython is now
available in SharpDevelop 3.1. The
original IronPython forms designer was removed when
SharpDevelop 3.0 began supporting
IronPython 2.0
which
... [More]
had removed support for generating IronPython code from
Microsoft's CodeDOM. The forms designer has now been
re-implemented to use the IronPython
abstract syntax tree (AST) and no longer relies on the
CodeDOM.
Creating a Windows Application
To create a Windows Application open up the new project dialog
by selecting New then Solution from the File
menu. Select the Python category to show the available project
templates. Select the Windows Application project template, enter a
name and location and click the Create button.
Designing Windows Forms
The Windows Forms designer is not yet complete so be warned that
it could generate form code that will no longer compile.
The designer can be opened by opening a form in the text editor
and selecting the Design tab at the bottom of the editor.
Once open in the designer you can add controls to the form by
dragging the controls from the Tools window. In the screenshot
below a label, text box and a button have been added.
Click the Source tab at the bottom of the editor to view the
generated code in the InitializeComponents method.
Limitations
The IronPython forms designer is not yet complete and the
following are some of the known limitations.
No support for project or local form resources.
No support for icons.
Incomplete support for ToolStripItems and menu strips.
Incomplete support for ListViewItems.
No support for TreeViewItems.
Incomplete support for non-visual components (e.g.
Timers).
Controls needed to be fully namespace qualified.
Forms Designer Internals
For those interested in how the forms designer actually works at
a high level we will now look at what the IronPython forms designer
does when loading and then generating code for a form.
To show the form in the designer the following steps are
executed.
The form's code is parsed and an IronPython AST
(PythonAst object) is created.
The AST is then visited and each control is added to the
forms designer and the control's properties are set.
The form's properties are set in the designer and the
form is displayed.
To generate the code after the form has been designed the
following steps are executed.
The form is obtained from the forms designer.
Each of the child components of the form have their
properties checked to see if they need to be serialized. This can
be done by getting all the
property descriptors and then checking the
ShouldSerializeValue method. If they do need to be serialized
then code is generated for them and added to a StringBuilder.
After all the child components are added the code for the
form is generated.
Finally the generated code is inserted into the text editor
inside the InitializeComponent method, replacing any existing
code. [Less]
Posted
about 1 month
ago
by
MattWard
SharpDevelop 3.1 now supports converting C# and VB.NET code to
IronPython. It can convert a single file or an entire project. The
code to convert between these languages is still under development
and has some limitations.
... [More]
Converting an Individual File
To convert a C# or VB.NET file, open it in SharpDevelop's
text editor, then from Tools menu select Convert code to
Python.
The code conversion is limited to converting classes so it will
not convert an arbitary piece of code that is not inside a
class.
Converting a Project
To convert a C# or VB.NET project, open it in SharpDevelop, then
from the Project menu select Convert From C# to
Python.
Once converted the project will most likely not compile straight
away due to limitations in the implementation. At the time of
writing converting a project has the following limitations:
Project's Main File is not set.
No code generated to call the project's Main entry
method.
Namespace imports do include all the used classes.
Code Conversion Internals
Converting code to IronPython was originally supported in
SharpDevelop 2.2 and was based on converting code to a
Microsoft CodeDOM and then getting IronPython 1.0 to generate
the Python code. In IronPython 2.0 this CodeDOM support was removed
so the code conversion feature was removed from SharpDevelop 3.0
since that was using IronPython 2.0. In SharpDevelop 3.1 the code
conversion has been rewritten to no longer use the CodeDOM support.
It now works by executing the following simple steps:
The C# or VB.NET code is parsed using SharpDevelop's
parsing library
NRefactory and an
abstract syntax tree (AST) is generated.
A
visitor class then walks this AST and generates Python code
which is added to a StringBuilder.
Once the visit is complete the generated Python code is then
displayed or saved to disk. [Less]
Posted
about 1 month
ago
by
MattWard
SharpDevelop 3.1 now supports NUnit
2.5.
A summary of which NUnit version is supported by SharpDevelop is
shown in the table below.
SharpDevelop 3.1
NUnit 2.5
SharpDevelop 3.0
NUnit
... [More]
2.4.8
SharpDevelop 2.2.1
NUnit 2.4.7
SharpDevelop 1.1
NUnit 2.2
NUnit 2.5 Changes
NUnit 2.5 has changed quite substantially compared with the
previous 2.4.8 release, as outlined in the
NUnit
2.5 release notes. The problems that we had when migrating
SharpDevelop's unit tests to NUnit 2.5 were as follows.
Assert.IsInstanceOfType has been replaced by
Assert.IsInstanceOf.
Your code will still compile and work if
Assert.IsInstanceOfType is used but you will get compiler
warnings.
NUnit.Framework.SyntaxHelpers namespace no longer exists.
All classes that were in this namespace have been moved to
the NUnit.Framework namespace.
The Has.Count constraint no longer takes an integer
parameter.
To fix this problem replace code such as:
Assert.That(classesCollection, Has.Count(1));
With the following:
Assert.That(classesCollection.Has.Count.EqualTo(1));
Overriding a [TestFixtureSetUp] method in a derived class
using the new keyword no longer works.
Some of the SharpDevelop unit tests were overriding an
abstract base test class [TestFixtureSetUp] method in a derived
class by using the new keyword, as shown below.
Base class:
[TestFixtureSetUp]
public void SetUpFixture()
{
// Setup code.
}
Derived class:
[TestFixtureSetUp]
public new void SetUpFixture()
{
// Extra setup code.
base.SetUpFixture();
}
In NUnit 2.4.8 the SetUpFixture method in the derived class
would be called when running the tests allowing it to execute
some extra setup steps. In NUnit 2.5 the base class
SetUpFixture method is called instead and the derived class
method is never called. To resolve the problem we changed the
base class so it used a virtual method and allowed the derived
class to override this to execute its extra setup steps.
Base class:
[TestFixtureSetUp]
public void SetUpFixture()
{
BeforeSetUpFixture();
// Setup code.
}
public virtual void BeforeSetUpFixture()
{
}
Derived class:
public override void BeforeSetUpFixture()
{
// Extra setup code.
} [Less]
vb c# dotnet sharp_develop clr #develop boo ide
|
edit tags
