[Monodevelop-devel] Parser Overview

Christian Hergert christian.hergert at gmail.com
Wed Oct 1 03:18:47 EDT 2008

With your help, I was able to get this moving somewhat.

As an addin, this needs a lot of work. But it currently supports:

   - Python project type
   - Project and file template
   - Pluggable python runtimes (cPython2.5 only currently. this will change
   after i get the ui components added)
   - Precompiling of python modules (either .pyc or .pyo for optimized)
   - Code folding for functions/comments/classes
   - Really basic completion that I will be adding to over the next few
   nights (basically until its usable for myself daily)
   - Parsing of python code is done via a subprocess to a long running
   python process.  This allows for building a real AST using the "compiler"

and the obligatory screenshot



-- Christian

On Tue, Sep 30, 2008 at 11:59 AM, Christian Hergert <
christian.hergert at gmail.com> wrote:

> While I think its a worthy idea to remove the tight coupling to .NET logic,
> I'm not going to volunteer to do it.  I'll work around it for the time being
> and it seems like a notable post-2.0 feature.
> -- Christian
> On Mon, Sep 29, 2008 at 9:59 PM, Michael Hutchinson <
> m.j.hutchinson at gmail.com> wrote:
>> Hi,
>> > On Mon, Sep 29, 2008 at 3:38 PM, Christian Hergert
>> > <christian.hergert at gmail.com> wrote:
>> >>
>> >> I have a class that extends ParsedDocument.  Do references inside that
>> >> class get persisted to the parser database?  Or is this perhaps
>> something
>> >> that i should have encapsulated in an ICompilationUnit.
>> I /think/ any fields of objects that are [Serializable] will get
>> persisted, which includes all the collections that the base
>> ParsedDocument has.
>> On Mon, Sep 29, 2008 at 7:29 PM, Christian Hergert
>> <christian.hergert at gmail.com> wrote:
>> > Ok, so after some further exploration, I think I understand the
>> > ICompilationUnit stuff.  I was really hoping that the interface would
>> expose
>> > information via IEnumerable's so that I could maintain data in my own
>> format
>> > and yield requested data at will.  It also seems that the
>> ICompilationUnit
>> > is very much geared towards c#/.net.  I'll just map things the best I
>> can.
>> ParsedDocument is designed to be language-agnostic. ICompilationUnit
>> is very much .NET-specific, so if you don't want to use it, you don't
>> have to. Have the field here is not ideal IMO, but my suggestion for a
>> .NET parse unit interface was not taken up. There's a thread of
>> discussion about this that you might be able to contribute to.
>> The design so far has been pretty much driven by C#, so if you have
>> any suggestions to improve it, now would be the time to voice them,
>> before we start heading into the 2.0 betas.
>> >>
>> >> As an example ..
>> >>
>> >> PythonParsedDocument : ParsedDocument {
>> >>     PythonModule module; // hoping this gets persisted
>> If what I suspect is correct, PythonModule  would have to be
>> serializable. However, the DB is optimised/indexed for type lookup and
>> stuff, and this would obviously not work easily with custom
>> serializable classes. This may be something that we could improve.
>> --
>> Michael Hutchinson
>> http://mjhutchinson.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20081001/93151f73/attachment-0001.html 

More information about the Monodevelop-devel-list mailing list