[Mono-devel-list] Edit and Continue

Hello, My name is David Srbecky and I am working on SharpDevelop 2.0 debugger. The debugger is getting nearly finished, but it is still missing one 'cool' feature - edit and continue. The support for Edit and Continue (EnC) from the side of Microsoft runtime is good enough, but t

Re: [Mono-devel-list] Edit and Continue

ildasm) Thanks for help, David Paolo Molaro wrote: > On 08/03/05 David Srbecky wrote: > >>My name is David Srbecky and I am working on SharpDevelop 2.0 debugger. >>The debugger is getting nearly finished, but it is still missing one >>'cool' feature - edit and

Re: [Mono-devel-list] Edit and Continue

Mind that these are just drafts of public file specification. David Srbecky ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-devel-list] Edit and Continue

> We implement things based on publicly available materials. Ok, I do not insist that the data must be in the Microsoft format. You can create you own mono format which I can read and translate to MS format - windows has API for writing it so it should not be that big problem. The MS format is bin

[Mono-dev] Re: Edit and Continue

Anyone please? Regarding the Atsushi Eno's comment about legality of using the Microsoft's metadata format: I do not think it is a problem since: 1) The specification is going to be released soon anyway 2) We do not really need it anyway - Mono's own format can be used. Regards

[Mono-dev] Re: Edit and Continue

> On 08/10/05 David Srbecky wrote: > > As I wrote in my earlier reply, the feature requires a large amount of > work. Agreed, but there are two parts of this feature: - Debugger and jit support - Compiler support I guess that debugger and jit support is really difficult, but I on

Re: [Mono-dev] Re: Edit and Continue

Paolo Molaro wrote: > What if you just recompile the assembly and develop an assembly diff > tool? In a few months the Cecil library may be able to allow this. I been suggested this many times, but the problem is that it is way too slow. My target for application of EnC is < 100ms. The Cecil: Am

Re: [Mono-dev] Re: Edit and Continue

Paolo Molaro wrote: > On 08/16/05 David Srbecky wrote: >>Paolo Molaro wrote: >>>What if you just recompile the assembly and develop an assembly diff >>>tool? In a few months the Cecil library may be able to allow this. >> >>I been suggested this many times

Re: [Mono-dev] Re: Edit and Continue

Paolo Molaro wrote: > On 08/16/05 David Srbecky wrote: >>Isn't it better to use managed Cecil in S.R.Emit do the reading and >>writing of assemblies? > > No. > The runtime needs to be able to read assemblies before executing them, > so this code must be unmanaged.

Re: [Mono-dev] Incremental build for mono compiler

Yes, it is. Do you think we can figure something out so that we all benefit? David Alan McGovern wrote: > Hey, > > Out of interest, is this a gsoc project? > > Alan. > > On Fri, Apr 10, 2009 at 6:03 AM, Bartosz Lipinski > wrote: > > It is OK because till la

Re: [Mono-dev] Debugger on Windows

"Andrés G. Aragoneses [ knocte ] ("Andrés G. Aragoneses [ knocte ]) wrote: > AFAIK the Debugger is ready on Linux. What is lacking is updating the > Debugger Addin for MonoDevelop, which is the target of a SoC2007 project > IIRC. That is right - updating the Debugger Addin will be my job :-) Ge

Re: [Mono-dev] MCS and GMCS API Documentation

SharpDevelop's NRefactory could be of some help. It builds its own DOM tree and it already has functions to find references to methods. David Sachith M.D. wrote: > Hi, > > > > I am working on a project which required parsing C# source file and > consequently building the CodeDOM tree of t

Re: [Mono-dev] Managed Debugger from Microsoft

Miguel de Icaza wrote: >> What is everyones take on it? Could it help the mono debugger? > > Not really; The debugger architectures are quite different. Not much left to say. I can just confirm it. The license is a problem and even if it was not, there is no way to reuse the code in mono. I

[Mono-dev] Edit and Continue / Function body rewrite

- new TypeRef and MemberRef rows in metadata (if new external function is called) - String heap (if new string is used in function) Is there a way to get these from System.Reflection.Emit? Or alternatively, how difficult would it be to implement it? Thank you very much, David Sr

Re: [Mono-dev] Edit and Continue / Function body rewrite

Brian Crowell wrote: > David Srbecky wrote: >> The idea is that I will emit disk assembly using >> System.Reflection.Emit as usually, but later on I will re-emit body of >> some function and fetch changed data into memory. Once I got the data >> I can feed it to the

Re: [Mono-dev] Edit and Continue / Function body rewrite

it: If I want to change a function in a running program, what do I need? - whole IL code of the new function - new TypeRef and MemberRef rows in metadata (if new external functions are called) - String heap (if new string is used in function) - Anything else??? How can I get these from M

Re: [Mono-dev] Edit and Continue / Function body rewrite

> If you want to modify existing assemblies you should use Cecil > (http://www.mono-project.com/Cecil) because it is designed to do this > while System.Reflection.Emit is designed to emit new code and in fact I do not want to save the new IL code to assembly, I want to save it to memory to chan

Re: [Mono-dev] Edit and Continue / Function body rewrite

t to change IL > code but you want to modify metadata and string heap as well. > > Kornél > > - Original Message - From: "David Srbecky" <[EMAIL PROTECTED]> > To: "Kornél Pál" <[EMAIL PROTECTED]> > Cc: > Sent: Saturday, Jul

Re: [Mono-dev] Edit and Continue / Function body rewrite

code you need a compiler. Neither System.Reflection.Emit nor Cecil > provides any compiler so this is not a difference. > > Kornél > > - Original Message ----- From: "David Srbecky" <[EMAIL PROTECTED]> > To: "Kornél Pál" <[EMAIL PROTECTED]> &

Re: [Mono-dev] Edit and Continue / Function body rewrite

code. If you want to compile source code to IL >> code you need a compiler. Neither System.Reflection.Emit nor Cecil >> provides any compiler so this is not a difference. >> >> Kornél >> >> - Original Message - From: "David Srbecky" <[EMAI

[Mono-dev] Incremental C# compiler

Hello, It seems that my whole Edit and Continue effort boils down just to one thing: Being able to recompile as quickly as possible. The idea is that gmcs would not be used as a command line tool but as a library. After compilation it would keep all usefully data in memory so it could use them

Re: [Mono-dev] Incremental C# compiler

st, as normally very little would be changed from one > compilation to the other. But gmcs would have to invalidate only part > of the metadata/AST, what it wasn't built for. > > Hope it helps, > > On 7/12/06, David Srbecky <[EMAIL PROTECTED]> wrote: >> Hell

Re: [Mono-dev] Incremental C# compiler

old name anymore and thus you have to do semantic analysis on everything again. David Rafael Teixeira wrote: > On 7/12/06, David Srbecky <[EMAIL PROTECTED]> wrote: >> Thank you, >> >> So semantic analysis is the part that takes vast majority of the time >> and

Re: [Mono-dev] Incremental C# compiler

Jonathan Gilbert wrote: > I don't see any problem with removing methods -- it would just require an > extra pass over all of the presently-loaded IL to ensure that no code calls > the method being removed. If it's easy to walk the heap and find delegates, > that would also be a necessary test, I th

Re: [Mono-dev] Incremental C# compiler

Martin Baulig wrote: > So if you parse the same method a second time, the types previously > referenced by that method are still in the cache and thus your > metadata could grow a lot in size if you do that several times. I do not think that the new method will add that many entries to make thi