Re: [Mono-dev] Build fails: name `AllowReversePInvokeCallsAttribute' does not exist
2012/1/31 Leszek Ciesielski skol...@gmail.com
Did you try
make get-monolite-latest
make
Tried:
cd /home/tavasti/build/mono/mcs/class/lib { (wget -O-
http://mono.ximian.com/daily/monolite-99-latest.tar.gz || curl
http://mono.ximian.com/daily/monolite-99-latest.tar.gz) | gzip -d | tar xf
- ; }
--2012-02-01 08:55:53--
http://mono.ximian.com/daily/monolite-99-latest.tar.gz
Connecting to 10.21.4.37:8080... connected.
Proxy request sent, awaiting response... 404 Not Found
2012-02-01 08:55:53 ERROR 404: Not Found.
Might http://mono.ximian.com/daily/monolite-96-latest.tar.gz work?
MONO_CORLIB_VERSION is now 99,, but there is no MonoLite later than 96?
Ok, changed in Makefile.am monolite_url =
http://mono.ximian.com/daily/monolite-latest.tar.gz
make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/gmcs.exe
...
make[5]: Entering directory `/home/tavasti/build/mono/mcs'
/bin/sh .//mkinstalldirs build/deps
mkdir -p -- build/deps
touch build/deps/.stamp
make[6]: Entering directory `/home/tavasti/build/mono/mcs'
/home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe:
/home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe: cannot execute
binary file
make[6]: *** [build/deps/basic-profile-check.exe] Error 126
make[6]: Leaving directory `/home/tavasti/build/mono/mcs'
*** The compiler '/home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe'
doesn't appear to be usable.
*** You need Mono version 2.4 or better installed to build MCS
*** Read INSTALL.txt for information on how to bootstrap a Mono
installation.
make[5]: *** [do-profile-check] Error 1
(Sorry Leszek I first replied you only, not familiar with my webmail)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build fails: name `AllowReversePInvokeCallsAttribute' does not exist
2012/2/1 Markku Tavasti tava...@seravo.fi
make[5]: Entering directory `/home/tavasti/build/mono/mcs'
/bin/sh .//mkinstalldirs build/deps
mkdir -p -- build/deps
touch build/deps/.stamp
make[6]: Entering directory `/home/tavasti/build/mono/mcs'
/home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe:
/home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe: cannot execute
binary file
make[6]: *** [build/deps/basic-profile-check.exe] Error 126
Installed wine, and tried:
tavasti@susesrv:~/build/mono ${PWD}/mcs/class/lib/monolite/gmcs.exe
bash: /home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe: cannot
execute binary file
tavasti@susesrv:~/build/mono wine
${PWD}/mcs/class/lib/monolite/gmcs.exewine: Install Mono for Windows to run
.NET 2.0 applications.
tavasti@susesrv:~/build/mono err:ntdll:RtlDeleteResource Deleting active
MRSW lock (0x1124e4), expect failure
wine: Unhandled page fault on write access to 0x1100f849 at address
0x7bc48c62 (thread 0017), starting debugger...
err:seh:start_debugger Couldn't start debugger (winedbg --auto 14 48)
(1115)
Read the Wine Developers Guide on how to set up winedbg or another debugger
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Nuget and xbuild
Hi all,
during playing with nuget I discovered that xbuild has some problems
with playing with nuget's targets. Specifically nuget.targets contains
lines like that one:
PackagesConfig$([System.IO.Path]::Combine($(ProjectDir),
packages.config))/PackagesConfig
During the build one can see errors like that one:
Unable to locate '$([System.IO.Path]::Combine(/some/path, another/path))'
Is it that Combine is not executed at all but rather taken as a string?
Is it a bug?
I'm attaching whole nuget.targets.
--
Regards,
Konrad
?xml version=1.0 encoding=utf-8?
Project ToolsVersion=4.0 xmlns=http://schemas.microsoft.com/developer/msbuild/2003;
PropertyGroup
SolutionDir Condition=$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'$(MSBuildProjectDirectory)\..\/SolutionDir
NuGetToolsPath$([System.IO.Path]::Combine($(SolutionDir), .nuget))/NuGetToolsPath
NuGetExePath$(NuGetToolsPath)\nuget.exe/NuGetExePath
PackagesConfig$([System.IO.Path]::Combine($(ProjectDir), packages.config))/PackagesConfig
PackagesDir$([System.IO.Path]::Combine($(SolutionDir), packages))/PackagesDir
PackageOutputDir Condition=$(PackageOutputDir) == ''$(TargetDir.Trim('\\'))/PackageOutputDir
!-- Package sources used to restore packages. By default will used the registered sources under %APPDATA%\NuGet\NuGet.Config --
PackageSources/PackageSources
!-- Enable the restore command to run before builds --
RestorePackages Condition=$(RestorePackages) == ''false/RestorePackages
!-- Property that enables building a package from a project --
BuildPackage Condition=$(BuildPackage) == ''false/BuildPackage
!-- Commands --
RestoreCommand$(NuGetExePath) install $(PackagesConfig) -source $(PackageSources) -o $(PackagesDir)/RestoreCommand
BuildCommand$(NuGetExePath) pack $(ProjectPath) -p Configuration=$(Configuration) -o $(PackageOutputDir) -symbols/BuildCommand
!-- Make the build depend on restore packages --
BuildDependsOn Condition=$(RestorePackages) == 'true'
RestorePackages;
$(BuildDependsOn);
/BuildDependsOn
!-- Make the build depend on restore packages --
BuildDependsOn Condition=$(BuildPackage) == 'true'
$(BuildDependsOn);
BuildPackage;
/BuildDependsOn
/PropertyGroup
Target Name=CheckPrerequisites
!-- Raise an error if we're unable to locate nuget.exe --
Error Condition=!Exists('$(NuGetExePath)') Text=Unable to locate '$(NuGetExePath)' /
/Target
Target Name=RestorePackages DependsOnTargets=CheckPrerequisites
Exec Command=$(RestoreCommand)
LogStandardErrorAsError=true
Condition=Exists('$(PackagesConfig)')
WorkingDirectory=$(NuGetToolsPath) /
/Target
Target Name=BuildPackage DependsOnTargets=CheckPrerequisites
Exec Command=$(BuildCommand)
LogStandardErrorAsError=true
WorkingDirectory=$(NuGetToolsPath) /
/Target
/Project___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build fails: name `AllowReversePInvokeCallsAttribute' does not exist
Is there a mono package available for your distro? If so, just install that.
Alan
On 1 February 2012 09:41, Markku Tavasti tava...@seravo.fi wrote:
2012/2/1 Markku Tavasti tava...@seravo.fi
make[5]: Entering directory `/home/tavasti/build/mono/mcs'
/bin/sh .//mkinstalldirs build/deps
mkdir -p -- build/deps
touch build/deps/.stamp
make[6]: Entering directory `/home/tavasti/build/mono/mcs'
/home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe:
/home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe: cannot execute
binary file
make[6]: *** [build/deps/basic-profile-check.exe] Error 126
Installed wine, and tried:
tavasti@susesrv:~/build/mono ${PWD}/mcs/class/lib/monolite/gmcs.exe
bash: /home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe: cannot
execute binary file
tavasti@susesrv:~/build/mono wine
${PWD}/mcs/class/lib/monolite/gmcs.exewine: Install Mono for Windows to run
.NET 2.0 applications.
tavasti@susesrv:~/build/mono err:ntdll:RtlDeleteResource Deleting active
MRSW lock (0x1124e4), expect failure
wine: Unhandled page fault on write access to 0x1100f849 at address
0x7bc48c62 (thread 0017), starting debugger...
err:seh:start_debugger Couldn't start debugger (winedbg --auto 14 48)
(1115)
Read the Wine Developers Guide on how to set up winedbg or another debugger
___
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] Nuget and xbuild
2012/2/1 Konrad M. Kruczyński konrad.kruczyn...@gmail.com Hi all, during playing with nuget I discovered that xbuild has some problems with playing with nuget's targets. Specifically nuget.targets contains lines like that one: PackagesConfig$([System.IO.**Path]::Combine($(ProjectDir), packages.config))/**PackagesConfig During the build one can see errors like that one: Unable to locate '$([System.IO.Path]::Combine(/**some/path, another/path))' xbuild doesn't support property functions yet. In this case, the replacement should be easy: PackagesConfig$(ProjectDir)\packages.config/PackagesConfig -- Blog : http://www.ankitjain.org/blog ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException
What kind of machinery does your RTOS support? Something akin mach exception ports? Because you either need something like an exception port or sigaltstack to handle stack overflows as it requires stack space anyways. The way to implement this is to do the same logic as of altstack but from a remote thread, I suppose. On Tue, Jan 31, 2012 at 12:37 PM, Miguel Mudge michael.mu...@welchallyn.com wrote: I'm not specifically interested in the abort machinery, but looks like it's in a good position to handle low of mem/stack. Our RTOS also doesn't support signals at all. Are there better places to handle and recover from low mem/stack? - Kipp On Tue, Jan 31, 2012 at 9:16 AM, Rodrigo Kumpera kump...@gmail.comwrote: Mono already handles that in the case of stack overflow by using sigaltstack. Why do you want the abort machinery to raise anything but their related abort exceptions? On Mon, Jan 30, 2012 at 5:08 PM, Miguel Mudge michael.mu...@welchallyn.com wrote: We've got a single-process RTOS running Mono and we've started to tackle what happens when a stack overflow or out of memory condition occurs. We're using an AppDomain to load and unload a variety of apps that come off the external flash drive. When things go very wrong [StackOverflow or OutOfMemory], we terminate Mono entirely so the rest of the device can continue doing its job. We'd like to be able to more gracefully handle StackOverflow, OutOfMemory so that finally clauses execute and the root AppDomain can continue running. As I understand it, mono_throw_exception() throws immediately, but since stack/memory runs out unexpectedly, it's best if we have some spare memory/stack so the native code can finish what it was doing before managed exception handling starts cleaning up the mess. So - we're looking for behavior closer to ThreadAbortException. I see that in threads.c/mono_thread_execute_interruption(), thread-interruption_requested indicates that the ThreadAbortException should be thrown at the native-managed transition [among maybe some other actions]. I'm proposing that gets changed [or amended] to throw an arbitrary exception, both for future use and for our specific case. Native code such as signal handlers would be able to cause an exception to be thrown only after execution returns to managed. Our goal is to have several MB of guard pages (in spare memory and on the stack) available to handle the unwind. Comments? Am I on the right track here? Any forseen gotchas? - Kipp ___ 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] Handling StackOverflow, OutOfMemory, ThreadAbortException
Yes, it's got machine exceptions. With the help of the MMU, we are able to detect when the stack is down to the last 64K, so there is no need for an alternate stack. We can call a function from there, somewhat akin to signals. The requirements are that: - The native code is allowed to continue execution. - The managed code throws a StackOverflowException that executes finally blocks. - The root AppDomain continues running. As I understand it, the stack overflow handling in Mono only works on certain OSes and doesn't satisfy all of our requirements. It also seems that the ThreadAbortException handling satisfies all of these requirements, so that code would be an architecturally appropriate place to handle both. The out-of-memory exception is almost the exact same story... When memory gets low, I want to be able to do something that allows native code to continue, but OutOfMemoryException is thrown when execution returns to managed code. I assume there is no mechanism in there for this? - Kipp On Wed, Feb 1, 2012 at 8:21 AM, Rodrigo Kumpera kump...@gmail.com wrote: What kind of machinery does your RTOS support? Something akin mach exception ports? Because you either need something like an exception port or sigaltstack to handle stack overflows as it requires stack space anyways. The way to implement this is to do the same logic as of altstack but from a remote thread, I suppose. On Tue, Jan 31, 2012 at 12:37 PM, Miguel Mudge michael.mu...@welchallyn.com wrote: I'm not specifically interested in the abort machinery, but looks like it's in a good position to handle low of mem/stack. Our RTOS also doesn't support signals at all. Are there better places to handle and recover from low mem/stack? - Kipp On Tue, Jan 31, 2012 at 9:16 AM, Rodrigo Kumpera kump...@gmail.comwrote: Mono already handles that in the case of stack overflow by using sigaltstack. Why do you want the abort machinery to raise anything but their related abort exceptions? On Mon, Jan 30, 2012 at 5:08 PM, Miguel Mudge michael.mu...@welchallyn.com wrote: We've got a single-process RTOS running Mono and we've started to tackle what happens when a stack overflow or out of memory condition occurs. We're using an AppDomain to load and unload a variety of apps that come off the external flash drive. When things go very wrong [StackOverflow or OutOfMemory], we terminate Mono entirely so the rest of the device can continue doing its job. We'd like to be able to more gracefully handle StackOverflow, OutOfMemory so that finally clauses execute and the root AppDomain can continue running. As I understand it, mono_throw_exception() throws immediately, but since stack/memory runs out unexpectedly, it's best if we have some spare memory/stack so the native code can finish what it was doing before managed exception handling starts cleaning up the mess. So - we're looking for behavior closer to ThreadAbortException. I see that in threads.c/mono_thread_execute_interruption(), thread-interruption_requested indicates that the ThreadAbortException should be thrown at the native-managed transition [among maybe some other actions]. I'm proposing that gets changed [or amended] to throw an arbitrary exception, both for future use and for our specific case. Native code such as signal handlers would be able to cause an exception to be thrown only after execution returns to managed. Our goal is to have several MB of guard pages (in spare memory and on the stack) available to handle the unwind. Comments? Am I on the right track here? Any forseen gotchas? - Kipp ___ 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] Handling StackOverflow, OutOfMemory, ThreadAbortException
On Wed, Feb 1, 2012 at 9:48 AM, Rodrigo Kumpera kump...@gmail.com wrote: On Wed, Feb 1, 2012 at 12:22 PM, Miguel Mudge michael.mu...@welchallyn.com wrote: Yes, it's got machine exceptions. With the help of the MMU, we are able to detect when the stack is down to the last 64K, so there is no need for an alternate stack. We can call a function from there, somewhat akin to signals. On which stack and thread is that function called? You obviously can't call it on the overflown one. The RTOS is ThreadX for ARM - it is fairly useless. Mono is supported mostly by a homebrew POSIX implementation wrapped around it [cringe]. We wrote our own MMU driver. When an overflow occurs, we increase the size of the stack on the fly and call the overflow-handling function on the same thread and stack where the overflow occurred. When that function returns, execution resumes on the instruction that caused the overflow, but this time with the larger stack. The requirements are that: - The native code is allowed to continue execution. - The managed code throws a StackOverflowException that executes finally blocks. - The root AppDomain continues running. The out-of-memory exception is almost the exact same story... When memory gets low, I want to be able to do something that allows native code to continue, but OutOfMemoryException is thrown when execution returns to managed code. I assume there is no mechanism in there for this? OOM is quite a different beast, it's handled synchronously since we know exactly when we're out of managed memory. Mono doesn't handle native allocation failures well and this is something I would love to see patches for. Managed allocation failures are well handled with sgen. Since Mono doesn't handle running out of system memory very well, I'd rather actually handle it in exactly the same way as StackOverflowException - free up some guard memory and throw the OutOfMemoryException when execution returns to native code. In the context of our own requirements, I still see ThreadAbortException, StackOverflowException and OutOfMemoryException as ideally following the same code path. In all 3 cases, a specific thread isn't prepared to handle the exception on the the exact instruction where it happens, so the exception gets thrown at the native-managed transition. Perhaps I'm oversimplifying this - maybe the thread abort code is too specific to thread abort, and I certainly don't want to butcher it. To me, so far, this looks like an opportunity to generalize code that was originally intended to be an exception [so to speak] to the way ThreadAbortException is thrown, compared to other exceptions. We're also not super-familiar with all of Mono's existing facilities for this stuff - if there is a straightforward function we should call and/or adapt to our environment, that'd be quite helpful too. - Kipp ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building mono on windows
Hi, I used to build mono on Cygwin/Windows a couple of month ago. Therefore I had to convert a few files using dos2unix command. Today I did a clean checkout and applied dos2unix as before. But when runing make it complained about ./depcomp: line2: $'\r': command not found As depcomp hat unix format, I have no idea, what to do. Regards Michael ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Nuget and xbuild
2012/2/1 Konrad M. konrad.kruczyn...@gmail.com On Wed, 2012-02-01 at 16:52 +0530, Ankit Jain wrote: xbuild doesn't support property functions yet. In this case, the replacement should be easy: PackagesConfig$(ProjectDir)\packages.config/PackagesConfig I thought so. Your workaround should work most of the time. The problem is little bit wider however - this is the content of default nuget.targets file and can be found in some (many in future?) open source projects which can't therefore be built this way on Mono (but other than that are well buildable). Do you know whether someone currently works on that? I would try to fix that myself, however I'm not familiar with xbuild's code yet. Andrés plans to work on adding support for string property functions, to start with ;) Added him to CC. -- Blog : http://www.ankitjain.org/blog ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building mono on windows
Hi, git config --global core.autocrlf true should fix any EOL problems with building on Windows. (Make sure to do a clean clone after that.) Regards, Alex On Wed, Feb 1, 2012 at 5:26 PM, Michael Stoll unwicht...@mistoll.de wrote: Hi, I used to build mono on Cygwin/Windows a couple of month ago. Therefore I had to convert a few files using dos2unix command. Today I did a clean checkout and applied dos2unix as before. But when runing make it complained about ./depcomp: line2: $'\r': command not found As depcomp hat unix format, I have no idea, what to do. Regards Michael ___ 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] Handling StackOverflow, OutOfMemory, ThreadAbortException
On Wed, Feb 1, 2012 at 1:39 PM, Miguel Mudge michael.mu...@welchallyn.comwrote: On Wed, Feb 1, 2012 at 9:48 AM, Rodrigo Kumpera kump...@gmail.com wrote: On Wed, Feb 1, 2012 at 12:22 PM, Miguel Mudge michael.mu...@welchallyn.com wrote: Yes, it's got machine exceptions. With the help of the MMU, we are able to detect when the stack is down to the last 64K, so there is no need for an alternate stack. We can call a function from there, somewhat akin to signals. On which stack and thread is that function called? You obviously can't call it on the overflown one. The RTOS is ThreadX for ARM - it is fairly useless. Mono is supported mostly by a homebrew POSIX implementation wrapped around it [cringe]. We wrote our own MMU driver. When an overflow occurs, we increase the size of the stack on the fly and call the overflow-handling function on the same thread and stack where the overflow occurred. When that function returns, execution resumes on the instruction that caused the overflow, but this time with the larger stack. The requirements are that: - The native code is allowed to continue execution. - The managed code throws a StackOverflowException that executes finally blocks. - The root AppDomain continues running. The out-of-memory exception is almost the exact same story... When memory gets low, I want to be able to do something that allows native code to continue, but OutOfMemoryException is thrown when execution returns to managed code. I assume there is no mechanism in there for this? OOM is quite a different beast, it's handled synchronously since we know exactly when we're out of managed memory. Mono doesn't handle native allocation failures well and this is something I would love to see patches for. Managed allocation failures are well handled with sgen. Since Mono doesn't handle running out of system memory very well, I'd rather actually handle it in exactly the same way as StackOverflowException - free up some guard memory and throw the OutOfMemoryException when execution returns to native code. In the context of our own requirements, I still see ThreadAbortException, StackOverflowException and OutOfMemoryException as ideally following the same code path. In all 3 cases, a specific thread isn't prepared to handle the exception on the the exact instruction where it happens, so the exception gets thrown at the native-managed transition. Perhaps I'm oversimplifying this - maybe the thread abort code is too specific to thread abort, and I certainly don't want to butcher it. To me, so far, this looks like an opportunity to generalize code that was originally intended to be an exception [so to speak] to the way ThreadAbortException is thrown, compared to other exceptions. We're also not super-familiar with all of Mono's existing facilities for this stuff - if there is a straightforward function we should call and/or adapt to our environment, that'd be quite helpful too. Now I see how and what you're trying to accomplish. Let's think in steps. About OOM. The managed case is already handled for you, the unmanaged one will require some environment help. But your plan of releasing some guard memory and then raising an OOM exception is sound. To apply it to stack overflow is a bit trickier since you need to handle the case where managed code is executing as well. To handle native OOM, I guess patching the thread interruption code is the easier way to go. Change mono_thread_interruption_checkpoint_request to check for your OOM condition and you're set. To handle stack overflow it will require a bit more work. You could patch mono_thread_interruption_checkpoint_request to check for it as well. But would still need to patch the stack with a trampoline to raise the overflow exception in case it happens strictly on managed code. And then you have a trickier issue, which is to reconquer soft guard pages from stack and memory allocator. This is specially important in case of stack overflow. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
2012/1/24 Konrad M. konrad.kruczyn...@gmail.com Even if performance was backed in, it would not help a lot since you have the large bottleneck of file backed. As I said, I would rather not delete file directly on the callback's thread, but queue its deletion. Also the mentioned approach can be useful for other kinds of resources. I feel quite unease with publishing the current code as an API as it would require us to support it, which means we can't change it at all. I expect it to be exposed to further internal usage and which will better shape it. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
On Wed, 2012-02-01 at 22:04 -0200, Rodrigo Kumpera wrote: I expect it to be exposed to further internal usage and which will better shape it. I totally agree on this point. Maybe I could have some use on this via p/invoke to itself (using __Internal). What do you think? -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
