RE: [Mono-list] Re: Bootstrapping
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Paolo Molaro Sent: Friday, 9 July 2004 02:05 To: [EMAIL PROTECTED] Subject: Re: [Mono-list] Re: Bootstrapping On 07/08/04 Jonathan Pryor wrote: Besides, between the Mono and PNET projects we've effectively done the dual compiler scenario. For a full from source bootstrap you'd just need to get PNET's compiler to be able to process the Mono class libraries. This may already be possible, but I haven't tried it. There is no full from source bootstrap, since you have to start trusting something somewhere (are you sure your video card shows you the correct stuff? Is the firmware in your hard-drive trustworthy?). Originally mcs and corlib where compiled with csc on windows, so paranoid people suppose MS could have injected a trojan. Assuming pnet's compiler could compile mcs and corlib correctly, would that give any more guarantees? Nope, since thay had to use the MS compiler to build their own corlib for much longer than us, the window of opportunity for the evil MS to inject a trojan on their system was much bigger, so there is no additional guarantee and people are deluding themselves if they think there is. An attack on the original mcs binary would have been very sophitsticated, still someone thinks it would be possible to detect such an attack by ignoring an equivalently-sophisticated attack. Quite incorrect. Building pnet's corlib doesn't require an existing corlib because PNET's compiler (like MS's compiler) is written in C. Even if pnet used a trojan compiler to compile corlib at one point or another, any subsequent recompilation with cscc would overwrite the trojan. Regards, ^Tum ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] RE: [DotGNU]Re: Collaboration on alternatives to the US-patent-endangered APIs?
Maybe you are not familiar with it, but take my word, it is radically different. Both at the rendering level (Drawing) and at the toolkit level (Windows.Forms). I don't agree. The drawing primitives are the same and all they've done is replaced handles with classes. The API is actually identical to the 8 year old WFC classes from J++. It's the same non-MVC, ancient, outdated way of writing UIs. Appropriate for quick drag and drop UIs while making it difficult and inefficient to write anything more advanced. All the best, ^Tum ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] bug found! :-)
Hmm..that's not the reason. 4/3 isn't an integer if you're doing floating point arithmetic but that's not what's happening here. Notice how the following compiles without an error: int u = 3; int I = 4; int o = i / u; The reason there is an error in Maurizio's code is because dividing an integer by an unsigned integer yields a long (otherwise precision would be lost). The resulting long can't be assigned to the integer o without a cast. Of course the error should be cannot convert from long to int rather than cannot convert from int to long. All the best, ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Rohit Sent: Tuesday, 26 August 2003 3:37 p.m. To: Maurizio Colucci; [EMAIL PROTECTED] Subject: Re: [Mono-list] bug found! :-) thats not a bug! cause 4/3 = 1.333 != integer. thanks rohit --- Maurizio Colucci [EMAIL PROTECTED] wrote: uint u = 3; int i = 4; int o = i/u; error Mono gives the error: cannot convert from int to long. But there is no long here, just an uint (32 bits). mono 0.26 redhat rpms. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 13/11/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 13/11/2001 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] bug found! :-)
^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Rohit Sent: Tuesday, 26 August 2003 10:06 p.m. To: Thong (Tum) Nguyen; 'Maurizio Colucci'; [EMAIL PROTECTED] Subject: RE: [Mono-list] bug found! :-) please see inline... --- Thong (Tum) Nguyen [EMAIL PROTECTED] wrote: Hmm..that's not the reason. 4/3 isn't an integer if you're doing floating point arithmetic but that's not what's happening here. Notice how the following compiles without an error: int u = 3; int I = 4; int o = i / u; The reason there is an error in Maurizio's code is because dividing an integer by an unsigned integer yields a long (otherwise precision would be lost). The resulting long can't be assigned to the integer o without a cast. that is exactly what I mean when I said 4/3 != integer (i did mean 3 is of uint type as was asked and as gaurav too correctly and clearly pointed out). You said: 4/3 = 1.333 != integer. The excessive amount of 3s made me think you thought 4/3 = 1.3F rather than 4/3 = 1L = long != integer. That's an important distinction. ^Tum --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.298 / Virus Database: 161 - Release Date: 13/11/2001 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Marshal.SizeOf() vs. sizeof operator
The type of FieldType.Undefined is FieldType not byte.
You should prolly use Enum.GetUnderlyingType(typeof(FieldType)).
^Tum
-Original Message-
From: [EMAIL PROTECTED] [mailto:mono-list-
[EMAIL PROTECTED] On Behalf Of Giuseppe Greco
Sent: Wednesday, 13 August 2003 4:00 p.m.
To: Marcus
Cc: [EMAIL PROTECTED]
Subject: Re: [Mono-list] Marshal.SizeOf() vs. sizeof operator
Marcus,
here's an example:
public enum FieldType : byte
{
Undefined = 0,
Int16,
Int32,
Int64
}
Then, try something like this:
using System;
using System.Runtime.InteropServices;
public class MyClass
{
private FieldType fieldType = FieldType.Undefined;
public void MyMethod()
{
Console.WriteLine(The size of fieldType is {0},
Marshal.SizeOf(fieldType.GetType());
}
}
The code above executes sucessfully with Mono on Linux,
but it doesn't with .NET on Windwos, where I always get
the following exception:
Unhandled Exception: System.ArgumentException:
Type FieldType can not be marshaled as an unmanaged
structure; no meaningful size or offset can be computed.
at System.Runtime.InteropServices.Marshal.SizeOf(Type t)
Rewriting MyMethod like this
public void MyMethod()
{
Console.WriteLine(The size of fieldType is {0},
Marshal.SizeOf(Type.GetType(System.Byte));
}
it does function also with .NET on Windows...
OK, my target is Mono on *nix, but I cannot assume that
all the users of our software are running Linux...
Thanks,
Gius_.
-- Original Message --
From: Marcus [EMAIL PROTECTED]
To: Giuseppe Greco [EMAIL PROTECTED]
Subject: Re: [Mono-list] Marshal.SizeOf() vs. sizeof operator
Cc: [EMAIL PROTECTED]
Date: Tue, 12 Aug 2003 16:34:38 -0500
The sizeof operator can only be applied to valuetypes (e.g. char,
int, struct)
and not to reference types (classes). The sizeof operator is only
available
in unsafe code.
Marshal.SizeOf() can be applied to an instance or a Type, and it
returns
the
unmanaged size of the object. Unlike the sizeof operator,
Marshal.SizeOf()
is
not restricted to valuetypes.
I don't quite understand what you were saying about char types. Can
you
provide an example?
As for custom classes, I suspect that you need to use the
StructLayout
attribute, such as [StructLayout(LayoutKind.Sequential)] or using
explicit layout. The error on Rotor is System.ArgumentException: Type
Class
can not be marshaled as an unmanaged structure; no meaningful size or
offset
can be computed.
On Tuesday 12 August 2003 7:29 am, Giuseppe Greco wrote:
Marshal.SizeOf() and the sizeof() operator
return the same result, so what's the real
difference between them?
Until now, I've used Marshal.SizeOf()...
and with Mono on Linux it works fine.
This morning I've had the good (or bad) idea
to test my code on Windows with .NET... and
the result was
1. Marshal.SizeOf() is unable to determine the
type of custom classes
2. for char types, Marshal.SizeOf() always returns
System.byte[] instead of System.Char
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Reflection
Try System.Runtime.InteropServices.Marshal.SizeOf(Type). ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Giuseppe Greco Sent: Saturday, 2 August 2003 3:52 a.m. To: Mono Subject: [Mono-list] Reflection Hi all, sorry for my stupid question... but does anybody know how can I get the size of a type without using sizeof()? For example, sizeof(Int32) returns 4; how can I obtain the same result using the Type class? Thanks, Gius_. -- Giuseppe Greco ::agamura:: phone: +41 (0)91 604 67 65 mobile: +41 (0)76 390 60 32 email: [EMAIL PROTECTED] web:www.agamura.com ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] remoting mono with MS' CLR?
Hi Miguel, I can understand the need to interop with MS.NET, but I don't think sterilization compatibility is an easy goal. It's no easy task to replicate internal, implementation specific details from MS.NET. If MS upgrade ArrayList then interop between MS.NET versions will be broken as well. The solution is to use the same collections package on both runtimes and/or use a more customized serialization format (e.g. XML). PS. Java has the same problems with serialization. ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Miguel de Icaza Sent: Monday, 7 July 2003 5:21 a.m. To: Thong (Tum) Nguyen Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Mono-list] remoting mono with MS' CLR? Hello, Serializing the collection classes would require the collection classes to be an exact clone of the Microsoft classes. Not only do the field names have to match exactly, but the underlying implementation (how/when/where those fields are used) has to match exactly too. Good point Thong. In a few cases, we might be able to change the implementation to match the Microsoft runtime behavior, to maximize interop. It is not perfect, but at least worth trying. Miguel ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] remoting mono with MS' CLR?
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, 6 July 2003 3:02 a.m. To: [EMAIL PROTECTED] Subject: Re: [Mono-list] remoting mono with MS' CLR? At 07:39 PM 26/06/2003 +0200, you wrote: Hi, Hi, I was wondering if anyone had any experience using remoting through a TCP connection between Mono and Microsoft's implementation of the CLR? I have a sample program that works on mono when remoting to the local host as well as when remoting between two windows machines, but between linux and windows it crashes, regardless of which is the server or client. This is without using cygwin, which I can't use for this for various reasons. Is this supposed to be working at this point in Mono's development? I just want to know if the error is on my end or should I try to find another route to try with this project. Much thanks in advance for any help on this. -Joe The TcpChannel and the BinaryFormatter is (or should be) compatible with MS.NET. However, some classes from the library may have a different binary representation, because they may have a different internal data structure, so for example you won't be able to exchange a Hastable object between Mono and MS.NET. It should not be a problem if you are using primitive types, arrays or your own classes. In any case, could you post a test case? I have been thinking about this issue for some time now, and the more I think about it, the more of a serious issue it seems to be. Collection types are very commonly used, and if they are not compatible with remoting between MS .NET and mono, an entire section of the market (so to say) will be unavailable. It would in theory be possible to provide mono's remoting with some thunks to translate the binary format of collections to/from Microsoft-equivalent formats, right within the remoting layer. How much work would this be? I might be able to contribute it myself, but I am not sure where to start. I can't think of any reason why a solution such as this would be inherently contrary to mono's vision, but if such reasons exist please let me know :-) Serializing the collection classes would require the collection classes to be an exact clone of the Microsoft classes. Not only do the field names have to match exactly, but the underlying implementation (how/when/where those fields are used) has to match exactly too. ^Tum ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Building gc.dll
Hi guys, Does anyone know if how to build gc.dll without VC++? Thanks, ^Tum ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] .dll .exe ?
Hi Miguel, I agree that it made sense for Microsoft to use the DLL vessel format. I just don't see why they needed to keep the DLL file extension. Nothing about windows prevents DLLs from having different file extensions and as I noted, many DLLs on windows do actually use different file extensions :-). I'm still campaigning for .DNA for libraries and .RNA for modules. Not sure what the extension for executables should be yet :-). ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Miguel de Icaza Sent: Thursday, 19 June 2003 8:08 a.m. To: Thong (Tum) Nguyen Cc: 'juan'; [EMAIL PROTECTED] Subject: RE: [Mono-list] .dll .exe ? Hello, I'll never understand why Microsoft used the .DLL extension. Even pre-dotnet dlls didn't always use .DLL (e.g. ActiveX controls use .OCX and control panel applets used .CPL). In .NET you can mix managed and unmanaged code into the same assembly (Managed C++ can do this for example). So you can actually have mixed assemblies, so it makes sense to reuse the vesel format. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] kernel support
That would break mono binaries on other CLIs though.. Try this: http://go-mono.com/tutorial/html/en/installation/linux.html (bottom of the page) Regards, ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Simon Kitching Sent: Tuesday, 17 June 2003 5:31 p.m. To: George Farris Cc: mono list; mono devel list Subject: Re: [Mono-list] kernel support On Tue, 2003-06-17 at 16:08, George Farris wrote: Does anyone know what the plans are for kernel support of mono binaries? Right now a binary mono file shows as: MS Windows PE 32-bit Intel 80386 console executable What command displays this?? This of course, is totally unacceptable on a Linux machine. I want to be able to run my binaries directly instead of through a shell script. Well, for executable file which starts with the byte sequence corresponding to #!, the application loader will extract the following characters up to the next linefeed, and start that application passing the executed filename as a parameter. This is most familiar from shell scripts, perl, etc., but it works for any interpreter and mono is an interpreter... So if (a) the mono compiler inserts: #!mono\n at the start of each binary, and (b) the mono runtime skips over these bytes when they occur at the start of an executable then it should be possible to start mono executables as if they were native. I'm a real newbie to mono, so I don't know if this functionality already exists... Cheers, Simon ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Suggestion: warning member variable not initialized
Members are implicitly initialized to 0 or null so they do have a
meaning even if you don't explicitly initialize them...
^Tum
-Original Message-
From: [EMAIL PROTECTED] [mailto:mono-list-
[EMAIL PROTECTED] On Behalf Of Maurizio Colucci
Sent: Sunday, 8 June 2003 12:50 a.m.
To: mono-list
Subject: [Mono-list] Suggestion: warning member variable not
initialized
Hi,
Currently the Microsoft C# compiler gives an error if you forget to
initialize a readonly member variable (this can be done either in the
contructor or in the declaration itself.)
I already posted a wish for mcs about that, but:
What about extending this behavior to non-readonly member-variables?
(Maybe a warning instead of an error?)
RATIONALE:
I cannot think of a case where not initializing a member variable (in
the constructor or at declaration time) makes sense. So we would catch
a frequent semantic error without any drawback...
Someone could reply that there ARE indeed some cases when you don't
know an appropriate value for a member variable when the constructor
is called. Maybe the user must initialize it explicitely, after
construction.
e.g.
class C{
private int member_var;
public C(){
// I don't yet know how to initialize member_var. Only the
// user can do that, via the Init method.
}
public void Init(int m){
member_var=m;
}
}
But, on the other hand, the above is bad design:
If member_var is not always meaningful across the lifetime of class C,
then member_var should NOT have been declared as a member of C, in the
first place. In other words, C is a state machine with two states:
Initialized and NotInitialized, such that member_var only makes sense
in the Initialized state, and not in the other one.
Good design:
class C{
private abstract class State{}
private class Initialized: State{
public int member_var; // this variable only makes sense
// when C is in the Initialized state!
// therefore it is declared here,
// not inside C.
public Initialized(int m){
member_var = m;
}
}
private class NotInitialized: State{}
private int state = new NotInitialized();
public void Init(int m){
state = new Initialized(m);
}
}
In this latter example, member_var DOES NOT EXIST when it does make
sense. This avoid the risk that someone reads/writes it when it makes
no sense!
In the former case, there is a time when member_var exists but does
not make sense (and is not initialized). Error prone.
So by raising an error in the former case we would enforce good
design.
Any comments?
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Suggestion: warning member variable not initialized
Hi Maurizio, Readonly members are implicitly initialized (all memory is zeroed before it is used) but since readonly members can't be set anywhere except for in the initializer or constructor a warning is given. The compiler will actually give an warning if you never initialize a field but it won't give you an warning if you initialize it *somewhere* (doesn't have to be the constructor). So the C# semantics for all fields appear to be that a warning is given if it is read *somewhere* but is never assigned a value *somewhere*. ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Maurizio Colucci Sent: Sunday, 8 June 2003 2:59 a.m. To: mono-list Subject: Re: [Mono-list] Suggestion: warning member variable not initialized On Saturday 07 June 2003 16:03, Thong (Tum) Nguyen wrote: Members are implicitly initialized to 0 or null so they do have a meaning even if you don't explicitly initialize them... ^Tum I see. :-P So the semantics of readonly members is members which are not implicitly initialized, and must be explicitly initialized in the constructor... right? So the C# semantics is itself error-prone, because implicit initialization is error-prone. Of course we cannot change the semantics! :-) On the other hand, my suggestion as a warning might still be useful, maybe... bye, Maurizio ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Implementation of ListWrapper.Sort
Can't remember if this is the place for patches or not... ^Tum The true measure of a man is how he treats someone who can do him absolutely no good. - Samuel Johnson (1709-1784) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003 listwrapper.diff Description: Binary data
RE: [Mono-list] Exceptions and error codes.
Hi Paolo, It is an interesting point! It seems like a good idea not to throw exceptions from methods invoked by native code. You can still throw exceptions before and after invoking native code (outside of call-backs) so the problem doesn't affect the recommendation I made that public methods in GTK# should throw exceptions rather than use error codes ;-). All the best, ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Paolo Molaro Sent: Wednesday, 26 March 2003 12:30 a.m. To: [EMAIL PROTECTED] Subject: Re: [Mono-list] Exceptions and error codes. On 03/21/03 Thong (Tum) Nguyen wrote: You make some good arguments, but I think most of it is irrelevant since, in order to remain compatible with .NET, Mono must behave the same way with respect to returning (or not) exceptions. The MSDN docs describe exactly what exceptions/return codes File.Exists and File.Open should return, Mono should do the same (unless the docs are in error). A lot of work has already been done on this. You'll notice that many of the test cases test whether or not the correct exception is being returned. Definitely. I was more referring to our own class libraries (such as GTK#). I just want to add another data point to the ones already explained about the use of error codes or exceptions, especially as it relates to Gtk+, but this also applies to other libraries that are P/invoked from the CLR. C code has no notions of exceptions and of the way exception handling can unwind the stack (yes, on windows people use SEH in C code, but it's non-standard and I don't even know if the MS CLR deals with SEH in C code). So what may happen is: C# code with a try block - Gtk+ code (takes a lock and calls a delegate) - C# code that trows an exception - exceptions handling triggers and gets the stack back to the try block - next time Gtk+ is called again and it needs the lock (that could be not unlocked by the exception code, since it's not aware of it) you get a nice deadlock lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Exceptions and error codes.
Hi Miguel,
There are definitely examples where exceptions can slow down your code.
The thing is, how often would those cases appear in the real world, and
when they do appear would they be a hotspot?
WRT your example...
If you're expecting many of the lines to contain non-integers then it
would make sense to seek an alternative method because you're then using
exceptions to notify you of a situation that you *normally* expect. The
problem isn't that Int32.Parse throws exceptions, it's because you're
using Int32.Parse in a way that wasn't intended. Int32.Parse isn't
designed for testing whether something is an int or not. Int32.Parse
expects to be given valid input most of the time and fails (with an
exception) when you (or the user) accidentally give it invalid input.
In your example, it looks like a non-int line isn't invalid input but
simply alternate input.
Since the loop appears to be a meaty part of the program my solution
would be to use a tokenizer.
^Tum
-Original Message-
From: [EMAIL PROTECTED] [mailto:mono-list-
[EMAIL PROTECTED] On Behalf Of Miguel de Icaza
Sent: Monday, 24 March 2003 3:43 p.m.
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Mono-list] Exceptions and error codes.
Hello,
You do raise interesting points.
The problem with exceptions is that throwing and catching an
exception is an expensive operation. Using an exception as a
mechanism
to return a failure error, when failure is likely to happen is
inefficient.
Contrast `likely to happen error' with `exceptional condition:
internal error, or unlikely error to happen'.
Lets consider a sample: a program that uses Int32.Parse to detect
whether an integer is available, or maybe a string command exists, and
we are parsing, say, a million records:
for (i = 0; i one_million; i++){
string line = readline ();
try {
v = Int32.Parse (line);
handle_numberic_argument ();
} catch {
ParseCommand (line);
}
}
This is so bad, that you probably want to rewrite the code to
pro-actively avoid parsing things that are known not to be integers.
It is easy to turn an error-code API into an exception-throwing
API
with no performance loss. The opposite is not possible.
Miguel
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Exceptions and error codes.
-Original Message-
From: [EMAIL PROTECTED] [mailto:mono-list-
[EMAIL PROTECTED] On Behalf Of Piers Haken
Sent: Friday, 21 March 2003 8:59 a.m.
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Mono-list] Exceptions and error codes.
-Original Message-
From: Thong Nguyen [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 12:14 PM
To: [EMAIL PROTECTED]
Subject: [Mono-list] Exceptions and error codes.
Hiya guys,
I recently read some recommendations on the GTK# mailing list
regarding the use of exceptions.
You make some good arguments, but I think most of it is irrelevant
since, in order to remain compatible with .NET, Mono must behave the
same way with respect to returning (or not) exceptions. The MSDN docs
describe exactly what exceptions/return codes File.Exists and
File.Open
should return, Mono should do the same (unless the docs are in error).
A
lot of work has already been done on this. You'll notice that many of
the test cases test whether or not the correct exception is being
returned.
Definitely. I was more referring to our own class libraries (such as
GTK#).
Of course, for new class libraries many of your arguments are valid.
Although I'd argue that the case for exceptions in .NET isn't as
clear-cut as you propose.
For example, since you're not required to declare the exceptions that
a
method throws, it's just as easy to miss handling an exception as it
is
to miss handling a return code.
That's true. The issue of checked exceptions opens up another can of
worms that I'm not willing to open here ;-).
But remember, with exceptions you still have the security of knowing the
following statements won't execute.
The argument that it's easy to forget to
handle a return code is purely subjective. I've been writing COM code
in
C++ since '95 and I've found that it's quite simple to get into the
habit of checking the result of every call and doing it in a way
that's
readable.
Yes. I've written a lot of COM code myself and have found that you do
get used to using the SUCCESS macro ;-). It's just a pain when you want
to handle errors for a block of code in the same way -- which happens
very often. In COM there is no choice; you *must* check and handle
every HRESULT.
In fact I often find that code that explicitly checks return
codes for each call is easier to read than code that relies on catch
blocks, since you know exactly which error handling code is associated
with each call. Catch locks are fine if you want to apply the same
exception handling code to a whole bunch of code, but as soon as you
have to nest them they become unwieldy.
For example, compare:
try
{
DoSomething ();
try
{
DoSomethingElse ();
// some more code here...
}
catch (Exception e)
{
// handle exception in DoSomething ()
}
}
Catch (Exception e)
{
// handle exception in DoSomethingElse ()
}
Typically, if you design a good exception hierarchy the code is a lot
tidier:
try
{
DoSomething();
DoSomethingElse();
}
catch (DoSomethingException e )
{
}
catch (DoSomethingElseException e)
{
}
Or you if you want to handle both the same way:
try
{
DoSomething();
DoSomethingElse();
}
catch (DoException e)
{
// catch(exception) is bad cause you can swallow things
// like OutOfMemorryException
}
You can write code for the best case (e.g. no error) and handle the
errors in a pseudo declarative way (with exceptions). I'm a sucker for
declarative languages.
With
HRESULT hr;
if (FAILED (hr = DoSomething ()))
{
// handle error in DoSomething ()
}
else if (FAILED (hr = DoSomethingElse ()))
{
// handle error in DoSomethingElse ()
}
else
{
// some more code here...
}
Or, if you don't need nested catch blocks:
HRESULT hr;
if (FAILED (hr = DoSomething ()) ||
FAILED (hr = DoSomethingElse ()))
{
// handle error
}
else
{
// some more code here...
}
Or, if you prefer your error handling to be at the end:
HRESULT hr;
if (SUCCEEDED (hr = DoSomething ())
SUCCEEDED (hr = DoSomethingElse ()))
{
// some more code here...
}
else
{
// handle error
}
The tidied try/catch looks nicer IMO :-).
What if you had 10 statements and they all should be handled the same
way?
Use this:
HRESULT hr;
if (SUCCEEDED (hr = DoSomething1())
SUCCEEDED (hr = DoSomething2())
SUCCEEDED (hr = DoSomething3())
SUCCEEDED (hr = DoSomething4())
SUCCEEDED (hr = DoSomething5())
SUCCEEDED (hr = DoSomething6())
SUCCEEDED (hr = DoSomething7())
SUCCEEDED (hr = DoSomething8())
SUCCEEDED (hr = DoSomething9())
SUCCEEDED (hr = DoSomething10()))
{
// some more code here...
}
else
{
// handle error
}
Or this:?
try
{
DoSomething1();
DoSomething2();
DoSomething3();
DoSomething4();
DoSomething5();
DoSomething6();
RE: [Mono-list] mono and real-time programming
Hard real time is pretty difficult to achieve with languages like C#. You can get close though. The Wonka VM for Java aims to be good enough for most embedded applications. Check it out: http://wonka.acunia.com/wonka.html ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED] On Behalf Of Parrish M Myers Sent: Sunday, 16 March 2003 9:07 a.m. To: [EMAIL PROTECTED] Subject: [Mono-list] mono and real-time programming Hello, I am currently taking a real-time programming class this semester. For the class we are required to do a project. Of which, I want to do it on real-time aspects/considerations of C#. What little information I have found, about the subject, indicate that C# is no good for hard real-time applications, but not much more. Does anyone know some sites for information on the subject? Maybe even how this relates to mono... Anything would be greatly appreciated. I can certainly share any information I find out (if anyone is interested). Thanks Parrish Myers = --- Academia is a little like child | Parrish M. Myers rearing, it provides a chance at | The Wacked Jester immortality without the stretch | [EMAIL PROTECTED] marks -- (unknown source)| --- __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] someone, please clear out that patents issue
Yep. And in reality, they aren't going to be making inroads against Java if they aggressively enforce any .NET patent (if they are even granted -- which IMO, is unlikely). ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED]] On Behalf Of J. Perkins Sent: Friday, 14 February 2003 1:43 a.m. To: [EMAIL PROTECTED] Cc: Miguel de Icaza Subject: Re: [Mono-list] someone, please clear out that patents issue I read a some of these discussions, but gave it up when it became clear that most of the people had no idea what was going on. Kudos to Miguel for staying the course and not responding to the petty remarks directed at him. Mono is a remarkable project...I will never go back to C++! FWIW, I was contacted by an MS employee -- I don't know anything about his role or responsibilities -- about the possibility of using wx.NET as a GUI library for Rotor. So they are out there, watching, listening... ;) Jason 379 Miguel de Icaza wrote: I personally did not want to get involved with the debate, because most of it was from miss-informed opinions. The original ZDnet article ahs a few quotes from people who looked at the caption and made a blank statement, so there is nothing really new in the discussion. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Difference in assemblies
Hi Ali, The book might be out of date. Currently, all the types in the System.Text.RegularExpressions namespace are contained within the System.dll assembly in v1.0 of the .NET framework. You should be able to leave out the /r switch and compile regex.cs fine. ^Tum -Original Message- From: [EMAIL PROTECTED] [mailto:mono-list- [EMAIL PROTECTED]] On Behalf Of Alfonso Ali Sent: Thursday, 6 February 2003 7:14 p.m. To: [EMAIL PROTECTED] Subject: [Mono-list] Difference in assemblies Hi all!!! While testing the examples in A Programmer´s Introduction to C# i found the following sentence: // compile with: csc /r:system.text.regularexpressions.dll regex.cs but the current mono don't have an assembly with that name, instead it have the System.Text namespace in the System.dll assembly. I know it doesn't have too much importance (the example compile without problems once i realized that i just had to drop the reference to the system.text.regularexpressions.dll assembly) but perhaps it would be good to have the sames assemblies than MS .NET. Well..., just an idea Best regards and keep the marvelous work ;) Ali ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Bug 35150
Any change that someone could look at it? http://bugzilla.ximian.com/show_bug.cgi?id=36150 I think it's a bug in the metadata subsystem which I haven't familiarised myself with. PS. The code works in MS.NET and Portable.NET. Cheers, ^Tum ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
