[Mono-dev] Cecil cannot read corlib
Hi Martin et al., I made some progress with the debugger on a MIPS platform. Unfortunately, I'm facing a problem with the Cecil library currently. When it tries to read the symbols of the corlib (Cecil.AssemblyFactory.GetAssembly()), the following error occurs: Cannot load symbol file `/usr/lib/mono/1.0/mscorlib.dll': Invalid XML string: PermissionSet Afterwards, null is returned. What does this error mean? Do you have any suggestions how to track this error down? I'm working with MDB 0.60, which uses Cecil 0.4.3.1. Where can I get the source of this version of Cecil? Thanks + best regards, Harald ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cecil cannot read corlib
Hey, On 7/7/08, Harald Krapfenbauer [EMAIL PROTECTED] wrote: I made some progress with the debugger on a MIPS platform. Unfortunately, I'm facing a problem with the Cecil library currently. When it tries to read the symbols of the corlib (Cecil.AssemblyFactory.GetAssembly()), the following error occurs: Cannot load symbol file `/usr/lib/mono/1.0/mscorlib.dll': Invalid XML string: PermissionSet Afterwards, null is returned. What does this error mean? Do you have any suggestions how to track this error down? I'm working with MDB 0.60, which uses Cecil 0.4.3.1. Where can I get the source of this version of Cecil? The SVN version of mdb uses the SVN version of Cecil, which is located in mcs/class/Mono.Cecil But somehow, I tend to doubt this is the cause of the error, as Cecil on x86 perfectly reads and write the mscorlib. -- Jb Evain [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Thread.Interrupt bug.
Hello All, I have a small threading patch that needs reviewed. Also contained in this patch are two unit tests that the changes to threads.c are meant to address. -bill threadInterrupt.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Thread.Interrupt bug.
Hi, This is ok to check in. Zoltan 2008/7/7 Bill Holmes [EMAIL PROTECTED]: Hello All, I have a small threading patch that needs reviewed. Also contained in this patch are two unit tests that the changes to threads.c are meant to address. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Streaming with Moonlight/Silverlight vs Flash
Hi Federico, I am about to choose the technology that will be used during the next two years to build the ESOF2010 web site (if you're curious about ESOF just check this year website, http://www.esof2008.org/). The project for 2010 includes a lot of streaming using preferably open protocols and open source software (mandatory on the servers, the client code should work at least on Windows and Linux and may use proprietary plugins). The tools to create the streams should be free software. We choosed to use feng as the streaming server because it supports RTP/RTSP and RTMP (now mostly free) with fallback on HTTP encapsulation and a lot of different non-proprietary codecs. The streaming Moonlight/Silverlight support is HTTP streaming (http://msdn.microsoft.com/en-us/library/cc251059.aspx). This is basically a protocol using HTTP to send commands (play, pause, stop, seek, etc) to the streaming server. I don't know much about other protocols, so I can't say how it compares to RTP/RTSP (or any other protocol for that matter). The supported codecs are most of the Windows Media codes + mp3 (http://msdn.microsoft.com/en-us/library/bb980063(VS.95).aspx) From what I've read about feng it does not support any of the Windows Media codecs. Looking at MS website for Silverlight specifications it seems to me that streaming using the standard protocols cited above is not supported and that only MS codecs (that we don't like to use) can be used. Correct. We also investigated the possibility of writing a a managed RTP implementation but it seems that UDP is not supported in Silverlight. And even if we manage to have a working implementation of RTP it is not clear how you can decode the data and send it to the multimedia part of the framework. You can't. So it seems that while we would much better like to work with Mono/Moonlight and keep compatibility with Silverlight in the end will be forced to use Adobe Flash (RTMP + one of the non-free codecs: at least there are open source tools to do the authoring and the encoding conversions). Ffmpeg can encode to Windows Media. I am writing to this list because I _hope_ we missed something and that Silverlight/Moonlight can be used to play streams using open protocols and codecs. If you can't/won't use MS codecs (Windows Media), you can't use Silverlight (support for other codecs have been requested by normal users on MS forums, no promise has been given by MS though.)) However since Moonlight is open sourced it is possible to add support for other codecs/protocols, and patches to implement this are very welcome :) Rolf Thank you for your time, federico -- signify error: can't use imaginary (1+0.191071i) weight! No virus found in this incoming message. Checked by AVG. Version: 8.0.136 / Virus Database: 270.4.5/1537 - Release Date: 06/07/2008 5:26 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Addins suppress console window showing
Fixed. Thanks! El dv 04 de 07 de 2008 a les 01:11 +0300, en/na Vladimir Dimitrov va escriure: Hello guys, Recently I started using Mono.Addins in my application and it looks very good. But as the application is primary used under windows (should be working fine under Linux too) I get an annoying console window showing when I run: AddinManager.Initialize (); And then another one when I run: AddinManager.Registry.Rebuild (null); I noticed in the code that at some point the .dll executes itself in a separate process ??!?! So if we add the following line: process.StartInfo.CreateNoWindow = true; to the file Mono.Addins/Mono.Addins/Database/SetupProcess.cs this would suppress the window to show under Window and should not cause any other complications. Please let me know what you think. Best regards, Vladimir Dimitrov P.S. I tried compiling my own copy with the change but it didn’t worked because when the process was trying to execute the .dll I compiled an exception was throws saying this is not a valid windows app. Maybe I need to compile it to .exe and just rename it? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Winx64 stack cleanup for calls
Hello All, Attached (cleanStack_08_07_07.diff) is a small patch that should be specific to Winx64 only that will cleanup the stack after each call emitted from mono_arch_output_basic_block. The calling convention on Winx64 requires that the caller always cleans the stack. (At least as far as I am aware.) Also I have some tests (unitTests_404729.diff ) that tests bug #404729 on Winx64. -bill cleanStack_08_07_07.diff Description: Binary data unitTests_404729.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Winx64 stack cleanup for calls
Hi, It might be easier to define IS_STDCALL as FALSE on windows, since afaik there is no stdcall calling convention on winx64. Zoltan 2008/7/7 Bill Holmes [EMAIL PROTECTED]: Hello All, Attached (cleanStack_08_07_07.diff) is a small patch that should be specific to Winx64 only that will cleanup the stack after each call emitted from mono_arch_output_basic_block. The calling convention on Winx64 requires that the caller always cleans the stack. (At least as far as I am aware.) Also I have some tests (unitTests_404729.diff ) that tests bug #404729 on Winx64. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Winx64 stack cleanup for calls
Zoltan, Agreed. I have attached an update. -bill On Mon, Jul 7, 2008 at 3:03 PM, Zoltan Varga [EMAIL PROTECTED] wrote: Hi, It might be easier to define IS_STDCALL as FALSE on windows, since afaik there is no stdcall calling convention on winx64. Zoltan 2008/7/7 Bill Holmes [EMAIL PROTECTED]: Hello All, Attached (cleanStack_08_07_07.diff) is a small patch that should be specific to Winx64 only that will cleanup the stack after each call emitted from mono_arch_output_basic_block. The calling convention on Winx64 requires that the caller always cleans the stack. (At least as far as I am aware.) Also I have some tests (unitTests_404729.diff ) that tests bug #404729 on Winx64. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list cleanStack_08_07_07.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Exceptions on Winx64
Hello All, I have made another change to patch. The difference from the last is that the unwindinfo pointer has been moved from MonoCompile to MonoCompileArch struct. -bill On Tue, Jun 24, 2008 at 2:59 PM, Bill Holmes [EMAIL PROTECTED] wrote: I have updated the patch with Robert's suggestion. -bill On Sat, Jun 14, 2008 at 6:26 AM, Robert Jordan [EMAIL PROTECTED] wrote: Bill Holmes wrote: Hello All, After a week of digging though awful online documentation I have finally got a patch for the exception unit tests in the runtime for Winx64. The attached patch appends the information to the code block for a method using structures that MS SEH understands. There is also a small stack alignment fix n this patch as well. For information on the unwind_info/code structs see. http://msdn.microsoft.com/en-us/library/ms794374.aspx http://msdn.microsoft.com/en-us/library/ms794567.aspx Suggestions? OK to commit? In mini.c, the local `unwindlen' remains uninitialized for !WIN64 and !MONO_ARCH_HAVE_UNWIND_TABLE. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list exceptoins_08_07_07.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Winx64 stack cleanup for calls
Hi, This is ok to check in. Zoltan On Mon, Jul 7, 2008 at 9:22 PM, Bill Holmes [EMAIL PROTECTED] wrote: Zoltan, Agreed. I have attached an update. -bill On Mon, Jul 7, 2008 at 3:03 PM, Zoltan Varga [EMAIL PROTECTED] wrote: Hi, It might be easier to define IS_STDCALL as FALSE on windows, since afaik there is no stdcall calling convention on winx64. Zoltan 2008/7/7 Bill Holmes [EMAIL PROTECTED]: Hello All, Attached (cleanStack_08_07_07.diff) is a small patch that should be specific to Winx64 only that will cleanup the stack after each call emitted from mono_arch_output_basic_block. The calling convention on Winx64 requires that the caller always cleans the stack. (At least as far as I am aware.) Also I have some tests (unitTests_404729.diff ) that tests bug #404729 on Winx64. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Console problem
Hello all, I am new here, hopefully in the right list :-) and I have a problem with using system.console under MONO: I try to reset the width and height of the console: Console.WindowHeight = 24 Console.WindowWidth = 80 Console.BufferHeight = 300 Console.BufferWidth = 80 But this does not work - I always get an error when using it with mono on linux. When I do the same on windows it works great! It looks like the console application does not take any notice when the size of the underlaying xterm changes. Is there any workarround to get this solved?! I want to write a command line interface for a linux system which should be used over ssh instead of a shell... Everything works fine - only the resize of the terminal does not! Thanks for help Johannes Johannes von Drachenfels Phone : +49-7231-9223800 Mobile: +49-171-6710815 Drachenfels GmbH Bleichstrasse 56 75173 Pforzheim Germany ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Console problem
2008/7/7 Johannes Drachenfels [EMAIL PROTECTED]: I want to write a command line interface for a linux system which should be used over ssh instead of a shell… How are you defining the difference between the command line and a shell? Is your end goal simply to provide a way to invoke commands on a remote machine securely regardless of the terminal/shell application being used, or do you want to build your own terminal/shell that is specific to your application? Everything works fine – only the resize of the terminal does not! Which terminal are you referring to? They come in all shapes and sizes on Unix*, and, as far as I know, there isn't any single API in which they have all have standardized on to control things like the width and height of the window and buffer. So while this is only a guess, my assumption would be that in the Windows world where -- up until a couple of years ago when Monad, now PowerShell, came into being -- there was really only one terminal application in cmd.exe, it was easy to map the .NET System.Console API to a specific application, whereas in the Unix* there is no real way to know ahead of time which terminal/shell will exist. In this regard (and assuming that I'm not way off base as to what seems to be the most logical reason) I really don't think it's possible to expect any the GUI portions of System.Console to work in the same way they work on Windows. Of course you could always hack on the Mono source directly, binding calls to the System.Console GUI API to the related commands of a given terminal/shell application via p/invoke (or via writing a C-based bindings wrapper), but that would require you distribute not only your application, but the modified System.dll file as well. You could instead write your own System.Console-like API, but that wouldn't be very portable unless you also wrote bindings for cmd.exe. In this regard, it might be easier to simply create your own Windows.Forms-based terminal application of which you would then have full control over the entire look, feel, and functionality on both Windows and Unix variants. -- /M:D M. David Peterson Co-Founder Chief Architect, 3rd Urban, LLC Email: [EMAIL PROTECTED] | [EMAIL PROTECTED] Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
