Re: [Mono-dev] Interactive C# shell for server monitoring
Hey Pablo, On 11/11/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: Any experience anyone using Interactive C# shell (http://www.mono-project.com/CsharpRepl) embedded into a server process for monitoring purposes (accessible through a socket maybe?) It's doable using the attach functionality of Mono: http://tirania.org/blog/archive/2008/Sep-29.html -- Jb Evain j...@nurv.fr ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Interactive C# shell for server monitoring
Hello, Sure, I've seen that. My question is if anyone already played with it, introducing it into an app and giving a network access to it. The problem today with CSharp and attach is that it is not integrated with the main loop of an application, so it is inherently unsafe. For Gtk# based applications, since we know that there is a main loop, we plug naturally into the main loop, so it is not an issue, but with server applications it is anyone's guess what kind of event processing exists. In those cases, it would be best if the specific server application provides an explicit interface to get C# source and evaluate it. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Interactive C# shell for server monitoring
Sure, I've seen that. My question is if anyone already played with it, introducing it into an app and giving a network access to it. Jb Evain wrote: Hey Pablo, On 11/11/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: Any experience anyone using Interactive C# shell (http://www.mono-project.com/CsharpRepl) embedded into a server process for monitoring purposes (accessible through a socket maybe?) It's doable using the attach functionality of Mono: http://tirania.org/blog/archive/2008/Sep-29.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Should we replace MemoryStream?
* Avery Pennarun apenw...@gmail.com [2009-11-10 17:34]: might or might not result in the array being reallocated even in the *naive* implementation. Each reallocation will cause a copy of the entire buffer every time. Conversely, a chunked implementation would reallocate-and-copy the data at most once, when you call GetBuffer(). So it is strictly equal-or-better than the naive implementation, in terms of reallocations and copies. Yes, it's true, but only partially. Code that knows how naive is MemoryStream could absorb the reallocations, maybe in some backgroud work. And the assume that GetBuffer is instantaneous (in GUI thread). (Yes, this is purely academic point; No, I don't have such code; No, I haven't seen one). greets silk ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] gmcs version #define
According to the documentation, gmcs #defines the __MonoCS__ constant when compiling C# code. However, it doesn't seem to provide a constant that identifies the compiler version. My use case: I have added a workaround to avoid some code which causes gmcs 2.0-2.4 to choke. Since this specific issue has been reported as fixed in the 2.6 branch, I would like to disable the workaround for newer versions of the compiler. Unless I have missed something obvious, this doesn't seem to be possible right now, at least not in an automated fashion. Does this sound like a reasonable feature? Would it be possible to add a constant like #define __MonoVersion__ 260 in some future version? (where 260 is gmcs 2.6.0, 281 is gmcs 2.8.1, etc) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs version #define
On Wed, 2009-11-11 at 17:22 +0200, Stefanos A. wrote: According to the documentation, gmcs #defines the __MonoCS__ constant when compiling C# code. However, it doesn't seem to provide a constant that identifies the compiler version. ... Does this sound like a reasonable feature? Would it be possible to add a constant like #define __MonoVersion__ 260 in some future version? (where 260 is gmcs 2.6.0, 281 is gmcs 2.8.1, etc) The problem here is that C# #defines can't have values, so you can't do `#define __MonoVersion__ 260`. Instead, you would need to have a family of #defines with the version encoded in the name, e.g. __MonoCS_200__, __MonoCS_220__, __MonoCS_240__, etc., and I'm not sure that would be very useful (as you couldn't have `#if __MonoCS__ 260` blocks, but instead `#if __MonoCS_260__ !__MonoCS_240__` or something, which relies on answering this: should gmcs 2.6 define *both* __MonoCS_260__ AND __MonoCS_240__, or just __MonoCS_260__?). My gut feeling is that this can't actually be solved easily within C# source; you'd instead need to move the logic into e.g. make(1), and use `#if BNC_XX` [0] in your source, and in your Makefile add -d:BNC_XX if `mcs --version` is a known bad version. - Jon [0] Why BNC_XX? Bugzilla.Novell.Com with XX as the bugzilla ID number. Replace BNC with the appropriate bugzilla abbreviation, as appropriate. Great fun, and lets you know when you can stop using the #define. :-) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Interactive C# shell for server monitoring
Ok, thanks Miguel. Miguel de Icaza wrote: Hello, Sure, I've seen that. My question is if anyone already played with it, introducing it into an app and giving a network access to it. The problem today with CSharp and attach is that it is not integrated with the main loop of an application, so it is inherently unsafe. For Gtk# based applications, since we know that there is a main loop, we plug naturally into the main loop, so it is not an issue, but with server applications it is anyone's guess what kind of event processing exists. In those cases, it would be best if the specific server application provides an explicit interface to get C# source and evaluate it. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs version #define
Στις 11-11-2009, ημέρα Τετ, και ώρα 11:22 -0500, ο/η Jonathan Pryor έγραψε: On Wed, 2009-11-11 at 17:22 +0200, Stefanos A. wrote: According to the documentation, gmcs #defines the __MonoCS__ constant when compiling C# code. However, it doesn't seem to provide a constant that identifies the compiler version. ... Does this sound like a reasonable feature? Would it be possible to add a constant like #define __MonoVersion__ 260 in some future version? (where 260 is gmcs 2.6.0, 281 is gmcs 2.8.1, etc) The problem here is that C# #defines can't have values, so you can't do `#define __MonoVersion__ 260`. Instead, you would need to have a family of #defines with the version encoded in the name, e.g. __MonoCS_200__, __MonoCS_220__, __MonoCS_240__, etc., and I'm not sure that would be very useful (as you couldn't have `#if __MonoCS__ 260` blocks, but instead `#if __MonoCS_260__ !__MonoCS_240__` or something, which relies on answering this: should gmcs 2.6 define *both* __MonoCS_260__ AND __MonoCS_240__, or just __MonoCS_260__?). I admit didn't know that C# #defines can't have values. I'm rather surprised but I guess should have checked the C# specs first. In this case, introducing version defines will likely cause more trouble than it's worth. My gut feeling is that this can't actually be solved easily within C# source; you'd instead need to move the logic into e.g. make(1), and use `#if BNC_XX` [0] in your source, and in your Makefile add -d:BNC_XX if `mcs --version` is a known bad version. Makes sense. I'll try to work out the details for the current msbuild/xbuild build environment (the main sticking point is keeping the solution cross-platform). Thanks! - Jon [0] Why BNC_XX? Bugzilla.Novell.Com with XX as the bugzilla ID number. Replace BNC with the appropriate bugzilla abbreviation, as appropriate. Great fun, and lets you know when you can stop using the #define. :-) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
