Re: [Mono-dev] [PATCH] Support for AvailableFreeSpace, TotalFreeSpace, TotalSize in System.IO.DriveInfo
Hi, Gonzalo Paniagua Javier schrieb: AFAIR, statvfs() is not present on some systems that we support. is there a list of systems Mono supports? statvfs() is a POSIX-conform call, it should be present on mostly every UNIX system. Even if not, i can add a configure check for statvfs() and fall back to old behaviour of returning int64.MaxValue when statvfs() is not present. Also, I'm not sure how it works on MS.NET, but what happens if the available space changes after you have created the DriveInfo instance? Will you get the space at the time of the instance creation or the current one? I'll checked MS.NET behaviour and it shows that the values reflect the current space, not the ones at time out the DriveInfo instantiation. In my implementation the values are currently cached, i'll change the bahviour to retrieve the values everytime a property is get. Best regards, Christian Prochnow -- Christian Prochnow Geschäftsführer SecuLogiX Systems GmbH Mohriner Allee 28 12347 Berlin http://www.seculogix.de mobile: +49 (0)177 313 02 57 fon: +49 (0)700 SECULOGIX Geschäftsführer: Christian Prochnow Handelsregister: B 96491, Amtsgericht Charlottenburg ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Support for AvailableFreeSpace, TotalFreeSpace, TotalSize in System.IO.DriveInfo
Hi, Christian Prochnow cpr...@seculogix.de writes: Gonzalo Paniagua Javier schrieb: AFAIR, statvfs() is not present on some systems that we support. is there a list of systems Mono supports? statvfs() is a POSIX-conform call, it should be present on mostly every UNIX system. According to gnulib This function is missing on some platforms: MacOS X 10.3, OpenBSD 3.8, mingw. - Hari ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Support for AvailableFreeSpace, TotalFreeSpace, TotalSize in System.IO.DriveInfo
Hi,
Raja R Harinath schrieb:
According to gnulib
This function is missing on some platforms:
MacOS X 10.3, OpenBSD 3.8, mingw.
I've changed the implementation of GetDiskFreeSpaceEx() to use statvfs()
or statfs(). It falls back to guint64 MaxValue if none of these
functions are available.
I've also added the GetDriveType() wrapper to query a drive's type.
GetDriveType() currently uses /etc/[mtab|mnttab] to query the
filesystem, but it can be improved to use statfs.f_typename or
statvfs.f_type on systems which support it (cause /etc/mtab doesnt exist
on darwin).
Best regards,
Christian Prochnow
--
Christian Prochnow
Geschäftsführer
SecuLogiX Systems GmbH
Mohriner Allee 28
12347 Berlin
http://www.seculogix.de
mobile: +49 (0)177 313 02 57
fon: +49 (0)700 SECULOGIX
Geschäftsführer: Christian Prochnow
Handelsregister: B 96491, Amtsgericht Charlottenburg
Index: class/corlib/System.IO/DriveInfo.cs
===
--- class/corlib/System.IO/DriveInfo.cs (revision 122757)
+++ class/corlib/System.IO/DriveInfo.cs (working copy)
@@ -26,6 +26,7 @@
using System.Collections;
using System.Text;
using System.Runtime.Serialization;
+using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
namespace System.IO {
@@ -33,7 +34,6 @@
[ComVisibleAttribute(true)]
public sealed class DriveInfo : ISerializable {
_DriveType _drive_type;
- DriveType drive_type;
string drive_format;
string path;
@@ -42,8 +42,6 @@
this._drive_type = _drive_type;
this.drive_format = fstype;
this.path = path;
-
- this.drive_type = ToDriveType (_drive_type, fstype);
}
public DriveInfo (string driveName)
@@ -53,10 +51,8 @@
foreach (DriveInfo d in drives){
if (d.path == driveName){
this.path = d.path;
- this.drive_type = d.drive_type;
this.drive_format = d.drive_format;
this.path = d.path;
- this._drive_type = d._drive_type;
return;
}
}
@@ -69,28 +65,57 @@
Windows,
}
- [MonoTODO(Always returns infinite)]
public long AvailableFreeSpace {
get {
- if (DriveType == DriveType.CDRom || DriveType
== DriveType.Ram || DriveType == DriveType.Unknown)
- return 0;
- return Int64.MaxValue;
+ ulong availableFreeSpace;
+ ulong totalSize;
+ ulong totalFreeSpace;
+ MonoIOError error;
+
+ if (!GetDiskFreeSpaceInternal (path, out
availableFreeSpace, out totalSize,
+ out
totalFreeSpace, out error))
+ {
+ throw MonoIO.GetException (path, error);
+ }
+
+ return availableFreeSpace long.MaxValue ?
+ long.MaxValue : (long)
availableFreeSpace;
}
}
- [MonoTODO(Always returns infinite)]
public long TotalFreeSpace {
get {
- if (DriveType == DriveType.CDRom || DriveType
== DriveType.Ram || DriveType == DriveType.Unknown)
- return 0;
- return Int64.MaxValue;
+ ulong availableFreeSpace;
+ ulong totalSize;
+ ulong totalFreeSpace;
+ MonoIOError error;
+
+ if (!GetDiskFreeSpaceInternal (path, out
availableFreeSpace, out totalSize,
+ out
totalFreeSpace, out error))
+ {
+ throw MonoIO.GetException (path, error);
+ }
+
+ return totalFreeSpace long.MaxValue ?
+ long.MaxValue : (long) totalFreeSpace;
}
}
- [MonoTODO(Always returns infinite)]
public long TotalSize {
get {
- return
[Mono-dev] Spring fails to register assembly:// URI handler
I have a testcase + patch for a Mono bug that breaks new (1.2.0) Spring.Net release: https://bugzilla.novell.com/show_bug.cgi?id=464235 Is this ok to commit? And could this perhaps (I know it's late...) could be added to 2.2? Regards, Leszek 'skolima' Ciesielski ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Exception not carrying .Msg when thrown from IL called constructor.
Excuse the verbose subjectline :)
When investigating the necessary steps to get NInject to work on Mono, I
found several failing tests.
One category of failing tests boil down to the following behaviour. It
looks like a bug to me, but I could be wrong.
The attached repro program prints out SomeImportantMessage on the CLR,
and prints out on mono.
It looks like the .Msg property of an exception thrown in a constructor
is not available to a catchblock, if the constructor
was called trough dynamically generated IL.
If someone can confirm I'm not doing anything silly, and this is indeed
a bug, I'll file a bugzilla on it.
I tested on 2.0 and svn trunk.
Bye, Lucas
using System;
using System.Reflection;
using System.Reflection.Emit;
public class MonoTest1
{
static void Main()
{
try
{
ILTest();
}
catch (Exception e)
{
Console.WriteLine(Test1: Exception caught. Msg: + e.Message+
Type: +e.GetType());
Console.WriteLine(On the CLR Msg = SomeImportantMessgage);
Console.WriteLine(On Mono, Msg = nothing);
}
}
public static void ILTest()
{
var constructor =
typeof(ClassWithThrowingConstructor).GetConstructor(Type.EmptyTypes);
var dm = new DynamicMethod(String.Empty, typeof(object), new[] {
typeof(object[]) });
ILGenerator il = dm.GetILGenerator();
il.Emit(OpCodes.Newobj, constructor);
il.Emit(OpCodes.Ret);
var md = dm.CreateDelegate(typeof(MyDelegate)) as MyDelegate;
md.Invoke(new object[0]);
}
public delegate object MyDelegate(params object[] arguments);
public class ClassWithThrowingConstructor
{
public ClassWithThrowingConstructor()
{
throw new Exception(SomeImportantMessage);
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Exception not carrying .Msg when thrown from IL called constructor.
Hey, On 1/8/09, Lucas Meijer lu...@lucasmeijer.com wrote: If someone can confirm I'm not doing anything silly, and this is indeed a bug, I'll file a bugzilla on it. Yes, it's a bug. It's triggered only when the constructor is simple enough to be inlined. -- 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
[Mono-dev] GC.Collect() CLRMono difference.
Here's another one. (Unsure if these are considered ontopic. If not,
please let me know)
This small test program shows GC.Collect() + WeakReference working
different on CLR
than they do on Mono. In mono, the WeakReference is still alive after
GC.Collect(),
in the clr, the WeakReference is no longer active.
using System;
public class MonoTest2
{
public static void Main()
{
var obj = new Version();
WeakReference reference = new WeakReference(obj);
obj = null;
GC.Collect();
Console.WriteLine(reference.IsAlive: + reference.IsAlive);
//mono outputs true
//clr outputs false
}
}
If people think this is a a bug, I'll file a report.
Bye, Lucas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono C# Serial Port problem
Hello all which is the status of the serial port in MacOSX implementation? i think Shawn code is not released, and i wonder if patching mono with this patch: https://bugzilla.novell.com/show_bug.cgi?id=384227 and re-compiling Mono will work on Mac. Worked for anyone? i have no MACs around. Thanks. 2008/5/30 Shawn Schaerer sh...@cogmation.com: Hi, I hope to have our OSX implementation up in the next couple of days. This implementation should work under linux too!! I am also looking at the serial.c source and will try to get that to work under OSX as well. I will send the link ASAP. Shawn Schaerer Director of Research and Development Cogmation Robotics Inc www.cogmation.com On 30-May-08, at 12:03 PM, mono-devel-list-requ...@lists.ximian.com wrote: Alan_Chun wrote: HI, currently I am porting a windows app to linux using Mono. I have some difficulties to get the serial port work. here is the code(based on mono website): I have also tried BytesToRead, Read, ReadByte, all of them are working fine under windows using .net2.0 framwork. But once I use the mono runtime, the nightmare begins. Any help will be really apprecaited! Thanks I'm actually having the same problem. I'm using ubuntu 8.04. -- ___ 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] GC.Collect() CLRMono difference.
On Thu, Jan 8, 2009 at 10:33 AM, Lucas Meijer lu...@lucasmeijer.com wrote:
Here's another one. (Unsure if these are considered ontopic. If not,
please let me know)
This small test program shows GC.Collect() + WeakReference working
different on CLR
than they do on Mono. In mono, the WeakReference is still alive after
GC.Collect(),
in the clr, the WeakReference is no longer active.
using System;
public class MonoTest2
{
public static void Main()
{
var obj = new Version();
WeakReference reference = new WeakReference(obj);
obj = null;
GC.Collect();
Console.WriteLine(reference.IsAlive: + reference.IsAlive);
//mono outputs true
//clr outputs false
}
}
If people think this is a a bug, I'll file a report.
Bye, Lucas
According to this:
http://msdn.microsoft.com/en-us/library/system.weakreference(VS.80).aspx
IsAlive becomes false after the finalizer is done. It may be so, that
under mono your call to IsAlive is made before the finalizer is
called. Try with GC.WaitForPendingFinalizers() before the check.
--
Svetoslav Milenov (Sunny)
Even the most advanced equipment in the hands of the ignorant is just
a pile of scrap.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GC.Collect() CLRMono difference.
On Thu, Jan 8, 2009 at 11:45 AM, Sunny slon...@gmail.com wrote: According to this: http://msdn.microsoft.com/en-us/library/system.weakreference(VS.80).aspx IsAlive becomes false after the finalizer is done. It may be so, that under mono your call to IsAlive is made before the finalizer is called. Try with GC.WaitForPendingFinalizers() before the check. Hmmm, I just tried it under mono, it still outputs True. Looks like a bug. -- Svetoslav Milenov (Sunny) Even the most advanced equipment in the hands of the ignorant is just a pile of scrap. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GC.Collect() CLRMono difference.
Sunny wrote: On Thu, Jan 8, 2009 at 11:45 AM, Sunny slon...@gmail.com wrote: According to this: http://msdn.microsoft.com/en-us/library/system.weakreference(VS.80).aspx IsAlive becomes false after the finalizer is done. It may be so, that under mono your call to IsAlive is made before the finalizer is called. Try with GC.WaitForPendingFinalizers() before the check. Hmmm, I just tried it under mono, it still outputs True. Looks like a bug. This is not a bug. The sample is too primitive to trigger a GC collection. Just add some complexity, e.g. a for-loop which generates a lot of those WeakReferences. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to run C# DotNet 2.x windows service on Mac OS X?
It works on Mac. Problem with mono-service (all platforms) is that it creates a different app domain, and it's been really tough for us since for some reason we end up with huge memory leaks. We're still trying to isolate a test case, but seems impossible outside our app. Once you get rid of monoservice and handle the signals yourself... memory doesn't go wild anymore. pablo Petit Eric escribió: 2009/1/7 d_v dan.vandermo...@figpsoft.com: How do I run my C# DotNet 2.x windows service on a Mac OS X? I would like to run the .exe even if not logged on to the Mac. That means I can't start the terminal manually and type in mono myservice.exe. Also, where are the best forums for these kind of questions? Where can I get basic questions answered? I don t know mac, but with linux yu have /usr/bin/mono-service2 so in a shell script /usr/bin/mono-service2 yourpath to your service and need to know mac method to start something in linux it is in /etc/init.d/ thanks a lot. -- View this message in context: http://www.nabble.com/How-to-run-C--DotNet-2.x-windows-service-on-Mac-OS-X--tp21337625p21337625.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] GC.Collect() CLRMono difference.
- Original Message - From: Sunny slon...@gmail.com To: mono-devel-list@lists.ximian.com Sent: Friday, January 09, 2009 3:50 AM Subject: Re: [Mono-dev] GC.Collect() CLRMono difference. On Thu, Jan 8, 2009 at 11:45 AM, Sunny slon...@gmail.com wrote: According to this: http://msdn.microsoft.com/en-us/library/system.weakreference(VS.80).aspx IsAlive becomes false after the finalizer is done. It may be so, that under mono your call to IsAlive is made before the finalizer is called. Try with GC.WaitForPendingFinalizers() before the check. Hmmm, I just tried it under mono, it still outputs True. Looks like a bug. possible factor: references to 'obj' still exist, and are lingering on the stack, ... so, with a precise GC, the only reference which can exist is the weak reference; but with a conservative GC (such as Boehm), any lingering references are still good. (note: it appears to me like the project is implementing / has implemented an optional precise GC, but I don't know the status, ...). so, the GC runs, and maybe it finds a reference still on the stack somewhere?... ok then, the object is not collected, and thus no need for the weak ref to report a change... I could be wrong though... -- Svetoslav Milenov (Sunny) Even the most advanced equipment in the hands of the ignorant is just a pile of scrap. ___ 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] GC.Collect() CLRMono difference.
On Thu, Jan 8, 2009 at 6:05 PM, BGB cr88...@hotmail.com wrote: - Original Message - From: Sunny slon...@gmail.com To: mono-devel-list@lists.ximian.com Sent: Friday, January 09, 2009 3:50 AM Subject: Re: [Mono-dev] GC.Collect() CLRMono difference. On Thu, Jan 8, 2009 at 11:45 AM, Sunny slon...@gmail.com wrote: According to this: http://msdn.microsoft.com/en-us/library/system.weakreference(VS.80).aspxhttp://msdn.microsoft.com/en-us/library/system.weakreference%28VS.80%29.aspx IsAlive becomes false after the finalizer is done. It may be so, that under mono your call to IsAlive is made before the finalizer is called. Try with GC.WaitForPendingFinalizers() before the check. Hmmm, I just tried it under mono, it still outputs True. Looks like a bug. possible factor: references to 'obj' still exist, and are lingering on the stack, ... so, with a precise GC, the only reference which can exist is the weak reference; but with a conservative GC (such as Boehm), any lingering references are still good. (note: it appears to me like the project is implementing / has implemented an optional precise GC, but I don't know the status, ...). so, the GC runs, and maybe it finds a reference still on the stack somewhere?... ok then, the object is not collected, and thus no need for the weak ref to report a change... I could be wrong though... You are correct, this is exactly what happens on this case. The object still reachable to the conservative GC mono uses. Our precise GC is still in development. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Support for AvailableFreeSpace, TotalFreeSpace, TotalSize in System.IO.DriveInfo
Hi, Am 08.01.2009 um 10:49 schrieb Christian Prochnow: statvfs() is a POSIX-conform call, it should be present on mostly every UNIX system. It is part of the XSI extension, i.e. non-mandatory. Cf. http://www.opengroup.org/onlinepubs/009695399/functions/statvfs.html Andreas Even if not, i can add a configure check for statvfs() and fall back to old behaviour of returning int64.MaxValue when statvfs() is not present. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GC.Collect() CLRMono difference.
- Original Message - From: Rodrigo Kumpera To: BGB Cc: mono-devel-list Sent: Friday, January 09, 2009 6:44 AM Subject: Re: [Mono-dev] GC.Collect() CLRMono difference. On Thu, Jan 8, 2009 at 6:05 PM, BGB cr88...@hotmail.com wrote: - Original Message - From: Sunny slon...@gmail.com To: mono-devel-list@lists.ximian.com Sent: Friday, January 09, 2009 3:50 AM Subject: Re: [Mono-dev] GC.Collect() CLRMono difference. On Thu, Jan 8, 2009 at 11:45 AM, Sunny slon...@gmail.com wrote: According to this: http://msdn.microsoft.com/en-us/library/system.weakreference(VS.80).aspx IsAlive becomes false after the finalizer is done. It may be so, that under mono your call to IsAlive is made before the finalizer is called. Try with GC.WaitForPendingFinalizers() before the check. Hmmm, I just tried it under mono, it still outputs True. Looks like a bug. possible factor: references to 'obj' still exist, and are lingering on the stack, ... so, with a precise GC, the only reference which can exist is the weak reference; but with a conservative GC (such as Boehm), any lingering references are still good. (note: it appears to me like the project is implementing / has implemented an optional precise GC, but I don't know the status, ...). so, the GC runs, and maybe it finds a reference still on the stack somewhere?... ok then, the object is not collected, and thus no need for the weak ref to report a change... I could be wrong though... You are correct, this is exactly what happens on this case. The object still reachable to the conservative GC mono uses. Our precise GC is still in development. just wondering: will the precise GC also implement ref-counting?... sorry, I have not looked into the details of 'SGEN' much... at least when I have written precise GC's, refcounting is a very effective way at reducing the total amount of garbage, and thus making GC cycles more rare (IMO, the overhead of adjusting the counts is usually paid for by the drastic reduction in time spent doing garbage collection and other things, although another trick is that of finding elaborate ways to sidestep needing to adjust the ref-counts...). so, anymore, usually whenever I implement precise garbage collectors, I also include reference counts. in my case, this was usually stored as a few bits in either the cell bitmap, but object headers could be another good place (anywhere where one can spare a few bits). of course, there is always the major drawback of ref-counts: it may often be a good deal of effort to make sure an entire codebase if ref-count safe (or, at least, those parts which may directly interact with the precise GC), but alas, this does not add too much vs the overhead of making it precise-GC safe... now, I had considered adding a set of precise features to my existing GC (I had actually written out an idea spec for this, mostly documenting additions to the API, ...). primarily, this would take the form of a modified set of API calls for working with values, and specially coded values for precise references (a partial reason for this being actually to obscure the references from the conservative parts of the GC, which may then see them as something analogous to fixnums or flonums). another use is for the precise code to be backwards compatible with conservative references (only precise references get the precise treatment, conservative references behave just like before). sadly, all this will involve partly fragmenting the API (adding precise versions of many operations). note that it would also be able to make a conservative reference to a formerly precise object (I will call this the defile operation, as it will cause the object itself to change status, at least until all the conservative references dissappear). note that, in most cases, conservative operations could still be used, but would tend to automatically defile precise objects (otherwise, the API could be left fragmented, with all defile operations needing to be done explicitly). a related operation: undefile, could make a potentially precise reference to a currently defiled object, thus speeding its return to an 'undefiled' state (by more quickly getting conservative references out of the system). note that this will be no-op for plain conservative objects (the undefiled reference is simply the good old pointer, as before...). note that the reason for having both is that, admittedly, precise GC is a pain to work with, and so could be limited mostly to the core systems and any other code where it actually matters. in many other places, such as off in ordinary C land, the continued usage of conservative object handling is likely to remain being the default (it is just SO much more convinient...). this is actually the main reason I am using
