Re: [Mono-devel-list] On no regression policy
That's even worse. We don't want to ship it in our mono-*.tar.gz. Atsushi Eno Yaacov Akiba Slama wrote: Hello, The testsuite from w3c is only 675KB if packaged as a tar.bz2 (instead of 1.5 MB for the zip). A solution would be to add the tar.bz2 to the source tree. What do you think ? --yas Atsushi Eno wrote: No massive download for everyone who just want to test sys.xml. Atsushi Eno Andrew Skiba wrote: Hi, Atsushi Eno wrote: The core of what I really dislike about the proposal is that it is said as policy. If it is something like guideline, and replacing must with should, forbidden with discouraged or not recommended, then yes it would be OK. If you agree with me, then you don't have to read it anymore. Let's make things simple - I want to run the W3C testsuite when one makes make run-test from the class/System.XML dir. Is it OK for you and Ben? Andrew. ___ 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-devel-list] Shadow copying
From: Goodwin, Robert-P28209 I don't believe it does. I have an application that sets the shadow copy property when creating the a new AppDomain. But when I load the Assembly into the new AppDomain, and then try to update it on the file system, the os comes back with a message that it is locked or in use. I have been meaning to post the same question. I have tried it only on Windows as it did the same. Does Mono lock the assembly file on Linux as well or shadow copying is simply not necessary as it does not lock the file? Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Windows service
Does Mono support Windows Service as daemon or something? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Assembly version for 2.0 profile system assemblies
Hi, Right now, the Mono system assemblies still use version 2.0.3600.0 (.NET Framework 2.0 Beta 1) for the 2.0 profile. Wouldn't it be better to update it to 2.0.0.0, which MS uses for Beta 2 ? Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] unsubscribe... [EMAIL PROTECTED]
___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Shadow copying
On Thu, 2005-06-02 at 15:58 +0200, Kornl Pl wrote: From: Goodwin, Robert-P28209 I don't believe it does. I have an application that sets the shadow copy property when creating the a new AppDomain. But when I load the Assembly into the new AppDomain, and then try to update it on the file system, the os comes back with a message that it is locked or in use. I have been meaning to post the same question. I have tried it only on Windows as it did the same. Does Mono lock the assembly file on Linux as well or shadow copying is simply not necessary as it does not lock the file? No, mono does not support shadow copying. There's a bug report for it. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] running mcs compiled apps with MS CLR
Hi all. Could someone explain to me why code compiled with mcs does not run with the MS CLR. (without mono runtime) Based on my understanding, the CIL is standard and thus runtime engines would not differentiate between one created with mcs and one created with csc. Cheers, Kevin -- Cheers,Kevin( http://www.)Copyright 2005 Kevin Parama Veragoo. Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] HasShutdownStarted race?
Hi,
System.Environment.HasShutdownStarted is the officially recommended way
of protecting finalizers against accessing finalized objects
(see http://msdn2.microsoft.com/library/xw9chd06(en-us,vs.80).aspx).
What worries me is that I'm not sure this is free from race conditions.
For example:
~SomeClass()
{
if(!System.Environment.HasShutdownStarted)
{
_mem1.foo();
_mem2.bar();
_mem3.baz();
// etc...
}
}
I can find nothing in the documentation that would guarantee that the
condition cannot change halfway through the execution of a finalizer,
for example, if System.Environment.Exit() is called from another thread.
The only way this would be possible would be for the GC and Exit()
to interlock on setting HasShutDownStarted to true, so that the value
of the property cannot change halfway through the execution of a finalizer.
But, as far as I can see, that's not happening in the code.
Comments, anyone? Is this a potential bug?
Cheers,
Michi.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] HasShutdownStarted race?
On Fri, 2005-06-03 at 14:11 +1000, Michi Henning wrote:
Hi,
System.Environment.HasShutdownStarted is the officially recommended way
of protecting finalizers against accessing finalized objects
(see http://msdn2.microsoft.com/library/xw9chd06(en-us,vs.80).aspx).
What worries me is that I'm not sure this is free from race conditions.
For example:
~SomeClass()
{
if(!System.Environment.HasShutdownStarted)
{
_mem1.foo();
_mem2.bar();
_mem3.baz();
// etc...
}
}
I can find nothing in the documentation that would guarantee that the
condition cannot change halfway through the execution of a finalizer,
for example, if System.Environment.Exit() is called from another thread.
The only way this would be possible would be for the GC and Exit()
to interlock on setting HasShutDownStarted to true, so that the value
of the property cannot change halfway through the execution of a finalizer.
Finalizers are run by one thread, so once you are in one, no new objets
will get finalized behind your back.
However, I'm not sure if the spec promises that at all.
OTOH, HasShutdownStarted probably *could* change in the middle of the
method. But it won't matter.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [GENERICS] implementing static TypeBuilder.GetMethod (Field, Constructor)
On Mon, 2005-05-30 at 14:20 +0200, Michal Moskal wrote: There is a static method in the 2.0 .NET reflection API: MethodInfo TypeBuilder.GetMethod (System.Type t, MethodInfo m) there is no documentation on msdn, so I'll skip the link. Hello, is this method only in TypeBuilder or also in Type ? I think if it's only in TypeBuilder it's not really that useful at all. What it does is take instanciated generic type and a method taken from the non instanciated generic type m. It then returns the same method in t. We have some unmanaged API in Mono for that, shouldn't be hard exposing it through that function. However, you should also be able to implement this entirely in managed code, I'll have a look at this next week and send you some sample code. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
