Re: [Mono-dev] [U-SPAM] Re: String.GetHashCode()
2007/12/2, Avery Pennarun [EMAIL PROTECTED]: On 02/12/2007, Andreas Nahr [EMAIL PROTECTED] wrote: Don't forget that 4 bytes per Hashcode isn't enough. You also need a boolean to store if the hash is already computed (as e.g. 0 is a valid hash, too). And then you would need one additional check for this boolean per call. Technically it would be safe (and no worse than current behaviour) to recalculate the hash every time in the rare case that it's exactly zero. And don't forget that strings within the corelib ARE mutable to some extent. That sounds somewhat more important. Wouldn't it be better, in the cases where precomputing the hash would have a large benefit, just to create a new class like PrecomputedHashString that stores a string along with its hash? Then the application itself could optimize for the cases where this matters by using the different class as the key to its hash tables. If only they didn't make string sealed ;) Have fun, Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] String.GetHashCode()
Extra memory cost, which would hit all allocated strings, also those short ones. For some applications, which use millions of small strings this would be unacceptable hit. 2007/11/30, Alan McGovern [EMAIL PROTECTED]: A thought struck me while i was dozing on the plane on the way home from the summit. Since strings are immutable, shouldn't it be possible to compute the hashcode once and store it rather than recomputing it over and over again? Is there some really obvious reason that i can't think of that would make this a bad idea? Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Linq sample?
foreach( Revision r in query )
{
// Console.WriteLine({0} - objid:{1}, num, r.ObjId);
++num;
}
I'm pretty sure (accounting your previous post about superb
performance) that this loop is actually optimized out by compiler. You
should *use* the r instance somehow, for example do a sum of all
r.ObjId values in both of the loops and then check the numbers.
--
Kamil Skalski
http://nazgul.omega.pl
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Linq sample?
2007/9/25, pablosantosluac [EMAIL PROTECTED]: Hi, Well, I've just tried some simple tests yet, but I'd say performance is awsome... I mean, searching in an array of 120 Million objects, using about 1GB RAM looking for a simple query checking a couple of properties needed only 185ms to finish!!! Doing it iteratively (looping through the array) took 284ms against 3 in a 12Million array (linq is faster!). After getting such results I would guess there is some problem with the benchmark. You could post it here, so we can look at it. Such results are hardly possible, since linq is mostly just a layer about the standard search code, so it should never actually run faster (unless we speak about some complex Linq to SQL stuff involving code generation etc.). -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Linq sample?
2007/9/24, pablosantosluac [EMAIL PROTECTED]: Thanks Robert, One more question: now it compiles but I can't run it. I'm using Mono JIT compiler version 1.2.5 (/trunk/ r84774) And I get: Unhandled Exception: System.InvalidProgramException: Invalid IL code in app:Main (): IL_: ldc.i4.8 Looks like a bug in compiler or runtime. You should produce a small sample triggering this error and post to bugzilla. -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] New Mono.Data.Sqlite problems with UTF8 conversion on Windows
Hello! I was trying to use the new implementation of Sqlite provider available now on mono, but I had several problems with it... First of all it failed to perform BindParameters properly when I tried to use named parameters. After some debugging it appeared that the names of parameters are improperly read from data returned by sqlite native function. The problem was the usage of Marshal.PtrToStrAuto in SQLiteConvert.cs function, which didn't properly decode strings on Windows system. I patched the implementation with the way it is done in old Mono.Data.SqliteClient - the implementation isn't very elegant, since it adds usage of unsafe pointer, but it worked well in the old implementation. If anybody knows a better way to convert unmanaged utf8 strings into managed string, without adding dependency on other libraries, then we could do this better. The second problem I encounter with new implementation is that it seems to deadlock when there are two threads using the same data-base... I use separate connections for each thread, but it looks like when I perform data-modify operations from both, it locks totally (concurrent reads seems to be ok). If anyone has some suggestions, please let me know. For now I will stick with old implementation. -- Kamil Skalski http://nazgul.omega.pl sqlite_utf.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (IL) Fault handlers not working
Yeah, it compiler with .NET 2.0:
Microsoft (R) .NET Framework IL Assembler. Version 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
Assembling 'm.il' to EXE -- 'm.exe'
Source file is ANSI
Assembled global method Main
Creating PE file
Emitting classes:
Emitting fields and methods:
Global Methods: 1;
Emitting events and properties:
Global
Writing PE file
Operation completed successfully
2007/1/6, Miguel de Icaza [EMAIL PROTECTED]:
Hello,
My mistake, the bug is our ilasm. That code should not compile (it
does not with MS ilasm).
I apologise for dragging this so much but the sample compiles with MS ilasm
too (at least for me).
In fact, to be more specific, I initially compiled it with MS ilasm and
tried Mono's ilasm too after your email; I got it compiled with both.
Anyway, I filed a bug report, thank you for your response.
Microsoft (R) .NET Framework IL Assembler. Version 1.1.4322.2032
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
Assembling 'f.il' , no listing file, to EXE -- 'f.EXE'
Source file is ANSI
f.il(8) : error : syntax error at token '{' in:{
* FAILURE *
Maybe a different version of ILASM?
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Kamil Skalski
http://nazgul.omega.pl
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Constructor implementation obligation via interface?
There is a slight problem. In C# empty constructors are added automatically, so you can't define a class without empty constructor. What you can do is to define a class with private empty constructor, which will prevent user from instanciating it directly. I guess there is not way to forbid this. 2006/5/24, Ympostor [EMAIL PROTECTED]: I have a question about C# 2.0: If I want the compiler to show an error if a class A does not implement the function void B(), I can make an interface that contains this method and make class A inherit from that interface. But, how can I do it if I want the compiler to show an error if class A doesn't have an empty constructor. Can this be controlled statically? Thanks in advance. -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: Constructor implementation obligation via interface?
Of course strictly speaking you cannot create class WITHOUT ANY constructor. If you don't specify any, the default empty ctor is generated by compiler. You can create a class without an empty ctor though, by defining the one with some parameters. I guess the only way to statically enforce having the empty ctor in a class is by hack provided by Jb. 2006/5/24, Ympostor [EMAIL PROTECTED]: Kamil Skalski escribió: There is a slight problem. In C# empty constructors are added automatically, so you can't define a class without empty constructor. What you can do is to define a class with private empty constructor, which will prevent user from instanciating it directly. I guess there is not way to forbid this. Thanks for your comment. But sorry because I think I haven't understood you completely. You say I can't define a class without empty constructor? That's not true. When you create an empty Console application in Visual Studio, there is a class Program that contains an static method but does not have any constructor. If you were trying to say that all classes, at the compiler level, contain an empty constructor, then ok; but what I want to do is to force a class to have a public empty constructor, and, if it doesn't have it, have the compiler to warn me because of the semantic requisite. Is there a way to achieve this? Regards. -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Handling SQLITE_BUSY throush option in SqliteConnection
Hi! Recently I had some locking/threading problems with my multithread application utilizing Sqlite and Mono provider. First problem was that I utilized the same SqliteConnection in two threads and it crashed in some situations. According to google and sqlite docs I must use separate sqlite structure / SqliteConnection in each thread. I used a little hack and just created getter for connections, which checked CurrentThread.ManagedThreadId and returned different object to each thread. This probably solved all places where I was reading database in concurrent way. But here comes the other problem. Assume one thread is doing some inserts/updates and another one is also trying to read/write something. According to http://www.sqlite.org/c_interface.html If the virtual machine is unable to open the database file because it is locked by another thread or process, sqlite_step will return SQLITE_BUSY. The calling function should do some other activity, or sleep, for a short amount of time to give the lock a chance to clear, then invoke sqlite_step again. This can be repeated as many times as desired. And indeed I got SqliteBusyException from Mono provider... But I thought that instead of fixing all places in my code to catch this exception and try to perform query once again, I could probably find some better solution. And indeed, there are methods in sqlite: void sqlite_busy_handler(sqlite*, int (*)(void*,const char*,int), void*); void sqlite_busy_timeout(sqlite*, int ms); which allow to configure behaviour in case of locks. So instead of fixing my code or even making SqliteDataReader handle SQLITE_BUSY state by sleeping and retrying, we could just configure underlaying DB to do this for us. As at the moment I do not need special handling of busy state, but just waiting till lock is cleared. I thought that we could introduce another parameter in SqliteConnection, which would pass timeout value to sqlite_busy_timeout. I would just give it some large value and hope that I will never see SQLITE_BUSY state again :) So, I will prepare the implementation of say, 'busy_timeout' parameter. Any suggestions? Some other name prefered? -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] SqliteDataReader should handle getting field type for null values
Hi!
I encountered NullReferenceException from SqliteDataReader, when I
have a query like
select a, b, NULL, c, FROM xxx
and I try to use reader.GetFieldType (2) for fetching info about
columns (actually DataAdapter from MS.NET calls this method for every
column in result)
I attach a patch (test included) for fixing this. It works great in my
app and it would be nice to have it official :)
May I commit?
--
Kamil Skalski
http://nazgul.omega.pl
Index: Mono.Data.SqliteClient/SqliteDataReader.cs
===
--- Mono.Data.SqliteClient/SqliteDataReader.cs (wersja 57661)
+++ Mono.Data.SqliteClient/SqliteDataReader.cs (kopia robocza)
@@ -368,7 +368,12 @@
int row = current_row;
if (row == -1 rows.Count == 0) return typeof(string);
if (row == -1) row = 0;
- return ((object[]) rows[row])[i].GetType();
+ object element = ((object[]) rows[row])[i];
+ if (element != null)
+return element.GetType();
+ else
+return typeof (string);
+
// Note that the return value isn't guaranteed to
// be the same as the rows are read if different
// types of information are stored in the column.
Index: Mono.Data.SqliteClient/ChangeLog
===
--- Mono.Data.SqliteClient/ChangeLog (wersja 57661)
+++ Mono.Data.SqliteClient/ChangeLog (kopia robocza)
@@ -1,3 +1,8 @@
+2006-03-07 Kamil Skalski [EMAIL PROTECTED]
+
+ * SqliteDataReader.cs: Handle null values in result as having
+ string type
+
2006-02-10 Joshua Tauberer [EMAIL PROTECTED]
* SqliteDataReader: Made 64bit clean. Patch from
Index: Test/SqliteDataReaderTest.cs
===
--- Test/SqliteDataReaderTest.cs (wersja 57661)
+++ Test/SqliteDataReaderTest.cs (kopia robocza)
@@ -75,5 +75,26 @@
}
}
}
+
+ [Test]
+ public void TypeOfNullInResultTest ()
+ {
+ _conn.ConnectionString = _connectionString;
+ SqliteDataReader reader = null;
+ using (_conn) {
+_conn.Open ();
+SqliteCommand cmd = _conn.CreateCommand ();
+cmd.CommandText = select null from test;
+reader = cmd.ExecuteReader ();
+try {
+ Assert.IsTrue (reader.Read());
+ Assert.IsNotNull (reader.GetFieldType (0));
+} finally {
+ if (reader != null !reader.IsClosed)
+ reader.Close ();
+ _conn.Close ();
+}
+ }
+ }
}
}
Index: Test/ChangeLog
===
--- Test/ChangeLog (wersja 57661)
+++ Test/ChangeLog (kopia robocza)
@@ -1,3 +1,8 @@
+2006-03-07 Kamil Skalski [EMAIL PROTECTED]
+
+ * SqliteDataReaderTest.cs: Add test for getting field type of null
+ value
+
2006-01-29 Joshua Tauberer [EMAIL PROTECTED]
* Added tests from Thomas Zoechling [EMAIL PROTECTED].
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] SqliteDataReader should handle getting field type for null values
Please do! Done. I'm wondering, tho, if wherever the adapter would return null, it should return a DBNull instead? Do other data adapters ever return 'null' values? Your question have a ready answer here http://bugzilla.ximian.com/show_bug.cgi?id=77535 :) So DataReader should throw an exception on null values being fetched. The proper way of dealing with it is IsDBNull method, which is used by MS.NET DataAdapter when it analyse result. GetValue () should probably just return DBNull.Value, though I didn't test this. -- - Joshua Tauberer http://taubz.for.net Unfortunately, we're having this discussion. It's too bad, because guess who listens to the discussion: the enemy. -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono runtime regression
Hi! I noticed another regression, which seems to be caused by http://lists.ximian.com/pipermail/mono-patches/2006-February/070993.html It gives NUnit version 2.2.0 Copyright (C) 2002-2003 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov, Charlie Poole. Copyright (C) 2000-2003 Philip Craig. All Rights Reserved. OS Version: Unix 2.6.10.0Mono Version: 2.0.50727.42 ** ERROR **: file loader.c: line 1582 (mono_method_signature_full): assertion failed: (mono_metadata_token_table (m-token) == MONO_TABLE_METHOD) aborting... Abort make[1]: *** [nunit] Error 134 During execution of Nemerle test suite. Just if it escape your attention :) (especially as it seems to fail quite late in our build/test process). To reproduce: 1. download http://nemerle.org/download/snapshots/nemerle-0.9.2.99.6135.tar.gz 2. configure, so that NUnit is activated (it should detect nunit-console2 in your environment) 3. make (to bootstrap compiler) 4. cd lib/tests 5. define NUNIT_LIB=-pkg:/home/user/local/lib/pkgconfig/mono-nunit.pc in Makefile 6. make -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: Regressions in generics runtime support
Hi! 2006/2/20, Paolo Molaro [EMAIL PROTECTED]: The 'call' puts a valuetype on the stack, which mono's il-verifier for 'ldfld' doesn't like. The ECMA 335 April 2005 draft says that it should be allowed -- maybe this is a change from the older ECMA standard? This is already fixed in svn. Thanks! I verified with revision 57081 and everything works fine :) -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Regressions in generics runtime support
Hi! I noticed a few refactorings of generics support in mono recently. Unfortunately there appeared some regressions. First one comes from patch http://lists.ximian.com/pipermail/mono-patches/2006-February/070865.html It causes following assertion when bootstraping Nemerle compiler: COMPILE [stage1] Nemerle.Compiler.dll ** ERROR **: file icall.c: line 1891 (ves_icall_MonoType_GetGenericArguments): assertion failed: ((t-type != MONO_TYPE_VAR t-type != MONO_TYPE_MVAR) || t-data.generic_param-owner) (this problems seems present also in current svn version) Later it got even worse, since with current svn, mono states there is some invalid IL in Nemerle.Compiler. Though from what I can see this might be related to Paolo's changes in IL verification. Here is the tarball to reproduce the problems: http://nemerle.org/download/snapshots/nemerle-0.9.2.99.6127.tar.gz Hm, probably I should open a bug for this, as IL and generics problems are probably not related. What is your opinion? -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Parse methods
Maybe it is related to locale? In some languages, like mine, '.' is used as tousand mark and ',' as decimal separator.Maybe in your locale it is also parsed this way somehow? Try 1,1
1 Feb 2006 15:13:29 -, Mayur Devendra Punekar [EMAIL PROTECTED]:
hi Zoltan,
here is my test case
public class Test{
public static void Main(string[] argv){
double d;
string s = 5.4 ;
d = Double.Parse(s);
System.Console.WriteLine(d);
}
}
output: 54
- I m suing Mono 1.1.10 with Debian machine
___Mono-devel-list mailing listMono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
-- Kamil Skalskihttp://nazgul.omega.pl
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Fwd: Planning for Mono 1.2: API freeze.]
There is still a pending patch for http://bugzilla.ximian.com/show_bug.cgi?id=76928 I'm not sure if this could be called a mono specific public API, but in some way a script name is such an API ;-) 2006/1/2, Miguel de Icaza [EMAIL PROTECTED]: -- Miguel de Icaza [EMAIL PROTECTED] Novell, Inc. -- Wiadomość oryginalna -- From: Miguel de Icaza [EMAIL PROTECTED] To: Mono Hackers [EMAIL PROTECTED] Date: Mon, 02 Jan 2006 12:54:19 -0500 Subject: Planning for Mono 1.2: API freeze. Hello folks, I know that this is a very short notice, I should have mentioned this in mid-December, but I completely blanked out. We are going to API freeze Mono this week. If you have any API changes that you want to make, please contact me directly. What this means is that the public API of the Mono-specific libraries will cease to change, although we can continue to bug fix it and document it. The .NET libraries already had their APIs set in stone, so those will continue to be developed (implementing NotImplementedExceptions, fixing bugs and implementing NET_2_0 protected code). Changes to the .NET public API to fix differences against the published .NET interface is ok (specially in the 2.x universe, as Mono 1.2 will not guarantee .NET 2.0 support in full anyways, so things are much more lax there). So in short: you can change implementation bits, but not public interfaces. If an API change is /absolutely required/ this needs to be discussed before the patch makes it into SVN. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Fwd: Planning for Mono 1.2: API freeze.]
We wont be able to upgrade NUnit on time. Upgrading NUnit in our tree will likely require build system changes and there is no time to include those. Well, actually the patch in mentioned bug is exactly the needed build system change. Everything to do here is to apply it. Upgrading NUnit itself in mono tree is not needed, we just need to tweak the place where config files are installed. You can still use the NUnit as provided by the NUnit maintainers, they should distribute it in Unix-installable form and distribute a pkg-config .pc file, which would allow folks to use the new NUnit. Yap, that is right. I can also use the patch included in bug (one of the reasons I created it was to allow use of nunit-console2 to all the people using mono). If it is really too late for this patch to get into the tree, then I'm fine with this. You just asked for pending changes, and here is one. -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] runtime specification in nunit-console.exe.config
Actually, as Sebastien mentioned in that thread, we cannot just install the 2.0 nunit assemblies, because they conflict with 1.1 profile ones. But indeed, removing .config file from nunit-console is a good idea, because it is rather meaningless on mono (the corlib should be choosen according to the profile for which nunit-console was compiled and there are no 1.0 compatibility issue). It is a safe operation and IMO can be commited immediately. And about resolving assemblies conflict problem... I have an idea that: - lib/mono/1.0 and lib/mono/2.0 directories would both contain nunit.core.dll, etc. symlinks to the GAC, but there would be two kind of directories in the gac/: - nunit.core, nunit.framework,... and nunit2.core, nunit2.framework, ... - if it is possible, those *2.* directories would just be the disambiguation hack and they would contain standard nunit.core.dll, nunit.framework.dll, ... - there would be additional mono-nunit2.pc, which would point to 2.0 assemblies This is my idea, but I'm not sure what Makefile stuff needs to be done for such configuration and the most important thing, if gacutil allows to create the mentioned hack directories. 2005/10/24, Atsushi Eno [EMAIL PROTECTED]: Oh, thanks Kamil, I overlooked the post... that patch looks cooler :-) I support it. Atsushi Eno Kamil Skalski wrote: Yap, removing this would be nice and it would bring nunit-console on 2.0 profile one step closer to being usable outside the mono build tree (see http://lists.ximian.com/pipermail/mono-devel-list/2005-September/014598.html) This is a deviation from original nunit.org sources though. Still, the most difficult problem with nunit for 2.0 is that we need to store somehow the 2.0 version of nunit assemblies and the current versioning/numbering scheme does not give a clean way for this. Nunit assemblies are currently installed into the GAC under 2.2.0.0 version number (and are compiler for 1.1 profile). -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] runtime specification in nunit-console.exe.config
Yap, removing this would be nice and it would bring nunit-console on 2.0 profile one step closer to being usable outside the mono build tree (see http://lists.ximian.com/pipermail/mono-devel-list/2005-September/014598.html) This is a deviation from original nunit.org sources though. Still, the most difficult problem with nunit for 2.0 is that we need to store somehow the 2.0 version of nunit assemblies and the current versioning/numbering scheme does not give a clean way for this. Nunit assemblies are currently installed into the GAC under 2.2.0.0 version number (and are compiler for 1.1 profile). 2005/10/23, Atsushi Eno [EMAIL PROTECTED]: Hello, Do we have to specify supportedRuntime and requiredRuntime in nunit-console.exe.config? If we omit those sections, we can run make PROFILE=net_2_0 run-test-ondotnet to verify our NUnit test sanity (i.e. check if they don't fail under .NET 2.0) on Windows. If there is no need, then the attached patch would make it possible. Atsushi Eno Index: nunit-console.exe.config === --- nunit-console.exe.config(revision 52109) +++ nunit-console.exe.config(working copy) @@ -23,11 +23,13 @@ -- startup +!-- supportedRuntime version=v1.1.4322 / supportedRuntime version=v2.0.50215 / supportedRuntime version=v1.0.3705 / requiredRuntime version=v1.0.3705 / +-- /startup @@ -89,4 +91,4 @@ /runtime -/configuration \ No newline at end of file +/configuration ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: SPAM-LOW: Re: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile
Well, ideally there should be no nunit shipped with mono. Or at least it would be nice to have mono/nunit20 kept in sync with nunit.org repository. As for my changes they are mostly mono build system specific except for the config file. Is there any reason why nunit use this kind of hardcoding the version of used mscorlib? Isn't it possible to use some command line option to switch the choosen mscorlib? 2005/9/9, Charlie Poole [EMAIL PROTECTED]: Ideally, I'd like to see the mono version of nunit that we build kept in synch with the one that you guys are building. So please let us know of changes that you think should be reflected back to NUnit. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastien Pouliot Sent: Thursday, September 08, 2005 11:18 PM To: Kamil Skalski Cc: mono-devel-list Subject: SPAM-LOW: Re: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile Hello, On Thu, 2005-08-09 at 23:22 +0200, Kamil Skalski wrote: Currently nunit distributed with mono is rather unusable with 2.0 there are, at least, 14236 tests saying otherwise http://mono.ximian.com/tests/displayTestResults.php?profile=1 distro=0 but I agree it may not be perfect for 2.0 ;-) assemblies. I attach a patch, which makes it fully usable: - nunit-console.exe.config is removed, because it enforces choosing 1.1 corlib assemblies in preference over 2.0 ones make sense as our main target is still 1.1 assemblies (and the contents of this config are mostly related to making nunit work on 1.0 .NET, which is not an issue with mono) - nunit-console2 is added, I'm copying the design of monop2 and wsdl2 - the nunit dlls from 2.0 are now installed you mean installed in the GAC ? if so what happens when 2.0 compiled assemblies overwrites the assemblies compiled with 1.1 (same name, version# and public key) ? does the 1.1 (default) profile still works ? Optionally we could leave the appSettings !--Specify the location to be used by .NET for the cache -- add key=shadowfiles.path value=%temp%\nunit20\ShadowCopyCache / /appSettings section in nunit-console.exe.config and remove any other contents. Should I commit? I think the real question is is it working ?, i.e. have you tested this on the mcs tree and ensure every test target are still working ? -- Sebastien Pouliot email: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Trying to compile mono-1.1.9 on solaris 10 x86
net_2_0' all-profiles ) || ok=false; \ ./semdel- wrapper || :; $ok make [3]: Entering directory `/home/pablo/download/mono-1.1.9/mcs' make profile-do--default-- all profile-do--net_2_0--all make[4]: Entering directory `/home/pablo/download/mono-1.1.9/mcs' make PROFILE=basic all make[5]: Entering directory `/home/pablo/download/mono- 1.1.9 /mcs' *** The compiler 'mcs' doesn't appear to be usable. sed: command garbled: s, /bin/sh: 0 [xX],,: not found /bin/sh: test: unknown operator stack make [5]: *** [do-profile-check] Error 1 make[5]: Leaving directory `/home/pablo/download/mono-1.1.9/mcs' make [4]: *** [profile-do-- basic-- all] Error 2 make[4]: Leaving directory `/home/pablo/download/mono-1.1.9 /mcs' make [3]: *** [profiles-do-- all] Error 2 make[3]: Leaving directory `/home/pablo/download/mono- 1.1.9/mcs' ** Message: Error deleting semaphore: Invalid argument make [2]: *** [all-local] Error 1 make [2]: Leaving directory `/home/pablo/download/mono-1.1.9/runtime' make [1]: *** [all- recursive] Error 1 make[1]: Leaving directory `/home/pablo/download/mono-1.1.9' make: *** [all] Error 2 = Any idea? Thanks, pablo Prueba el Nuevo Correo Terra; Seguro, R�pido, Fiable. ___ Mono- devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian. com/mailman/listinfo/mono-devel-list Prueba el Nuevo Correo Terra; Seguro, R�pido, Fiable. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists. ximian. com/mailman/listinfo/mono-devel-list Prueba el Nuevo Correo Terra; Seguro, R�pido, Fiable. ___ 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 Prueba el Nuevo Correo Terra; Seguro, R�pido, Fiable. ___ 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 -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Fwd: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile
I was a little bit too fast with saying that everything works without installing nunit assemblies into 2.0 install dir. The symlinks from /install_path/lib/mono/2.0/nunit.core.dll - /GAC are missing (it worked for me, because I had some old ones from previous installation). So it seems only my original patch actuall works, but as Sebastien pointed out it is not perfect - overwriting dll from one profile with other dlls during install is not a good idea, even though the result is satisfactionary... I don't know what might be the solution for this... My last patch allows using nunit-console2 out of the box (that is without MONO_PATH hack), but requires referencing /path/lib/mono/1.0/nunit.core.dll explicitly when compiling testcases. 2005/9/9, Kamil Skalski [EMAIL PROTECTED]: 2005/9/9, Sebastien Pouliot [EMAIL PROTECTED]: Hello, On Thu, 2005-08-09 at 23:22 +0200, Kamil Skalski wrote: Currently nunit distributed with mono is rather unusable with 2.0 there are, at least, 14236 tests saying otherwise I said rather unusable, not completely unusable ;-) Moreover, it IS completely unusable after make install (see notes below) http://mono.ximian.com/tests/displayTestResults.php?profile=1distro=0 but I agree it may not be perfect for 2.0 ;-) In fact, it runs only because of two special hacks in mono build system 1) the MONO_PATH=to_corlib_from_1.1_or_2.0_profile is specified to override settings specified in nunit-console.exe.config 2) when compiling the testcases, the nunit dlls with 2.0 version are referenced from explicitly specified build directory. Unfortunately they are not installed, thus it is not possible to compile 2.0 testcase with what resides in system after make install - the nunit dlls from 2.0 are now installed you mean installed in the GAC ? Well, I didn't notice that... yes, they are installed into the gac. After some futher testing it seems that this part of patch is not necessary. NUnit can handle running 2.0 tests without its 2.0 dlls in the path. if so what happens when 2.0 compiled assemblies overwrites the assemblies compiled with 1.1 (same name, version# and public key) ? does the 1.1 (default) profile still works ? Yes, it seems that 2.0 assemblies, which overwritten their 1.1 couterparts did not cause 1.1 profile to stop working. Anyways, I guess the shorter patch (attached) is better. Optionally we could leave the appSettings !--Specify the location to be used by .NET for the cache -- add key=shadowfiles.path value=%temp%\nunit20\ShadowCopyCache / /appSettings section in nunit-console.exe.config and remove any other contents. Should I commit? I think the real question is is it working ?, i.e. have you tested this on the mcs tree and ensure every test target are still working ? Yes, it is working (I wouldn't post a question about commit if I didn't test it), however make check shows some failures, but I think the errors are not related - nunit framework works just fine. Like this: OS Version: Unix 2.6.11.6Mono Version: 2.0.50215.16 Tests run: 5909, Failures: 1, Not run: 35, Time: 107,604149 seconds Failures: 1) MonoTests.System.TimeZoneTest.TestCtors : A03 String lengths are both 19. Strings differ at index 12. expected:03/31/2002 01:00:00 but was:03/31/2002 02:00:00 ---^ in [0x00054] (at /home/nazgul/projects/monosvn/mcs/class/corlib/Test/System/TimeZoneTest.cs:41) MonoTests.System.TimeZoneTest:CET (System.TimeZone t1) in [0x00028] (at /home/nazgul/projects/monosvn/mcs/class/corlib/Test/System/TimeZoneTest.cs:143) MonoTests.System.TimeZoneTest:TestCtors () in 0x0 unknown method in (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) in [0x00044] (at /home/nazgul/projects/monosvn/mcs/class/corlib/System.Reflection/MonoMethod.cs:127) System.Reflection.MonoMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) -- Kamil Skalski http://nazgul.omega.pl -- Kamil Skalski http://nazgul.omega.pl Index: mono/scripts/Makefile.am === --- mono/scripts/Makefile.am (wersja 49806) +++ mono/scripts/Makefile.am (kopia robocza) @@ -35,7 +35,8 @@ scripts_2_0 = \ monop2 \ - wsdl2 + wsdl2 \ + nunit-console2 scripts_rpmhelpers = mono-find-provides mono-find-requires Index: mcs/nunit20/nunit-console/nunit-console.exe.config === --- mcs/nunit20/nunit-console/nunit-console.exe.config (wersja 49806) +++ mcs/nunit20/nunit-console/nunit-console.exe.config (kopia robocza) @@ -1,92 +0,0 @@ -?xml version=1.0 encoding=Windows-1252? -configuration -!-- - Application settings
[Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile
Hi! Currently nunit distributed with mono is rather unusable with 2.0 assemblies. I attach a patch, which makes it fully usable: - nunit-console.exe.config is removed, because it enforces choosing 1.1 corlib assemblies in preference over 2.0 ones (and the contents of this config are mostly related to making nunit work on 1.0 .NET, which is not an issue with mono) - nunit-console2 is added, I'm copying the design of monop2 and wsdl2 - the nunit dlls from 2.0 are now installed Optionally we could leave the appSettings !--Specify the location to be used by .NET for the cache -- add key=shadowfiles.path value=%temp%\nunit20\ShadowCopyCache / /appSettings section in nunit-console.exe.config and remove any other contents. Should I commit? -- Kamil Skalski http://nazgul.omega.pl Index: mono/scripts/Makefile.am === --- mono/scripts/Makefile.am (wersja 49725) +++ mono/scripts/Makefile.am (kopia robocza) @@ -35,7 +35,8 @@ scripts_2_0 = \ monop2 \ - wsdl2 + wsdl2 \ + nunit-console2 scripts_rpmhelpers = mono-find-provides mono-find-requires Index: mcs/nunit20/core/Makefile === --- mcs/nunit20/core/Makefile (wersja 49739) +++ mcs/nunit20/core/Makefile (kopia robocza) @@ -8,11 +8,7 @@ LOCAL_MCS_FLAGS= -debug -r:nunit.framework.dll -r:System.dll /d:StronglyNamedAssembly NO_TEST = yo -ifeq (net_2_0, $(PROFILE)) -NO_INSTALL = yes -endif - EXTRA_DISTFILES = nunit.core.dll.csproj include ../../build/library.make Index: mcs/nunit20/framework/Makefile === --- mcs/nunit20/framework/Makefile (wersja 49739) +++ mcs/nunit20/framework/Makefile (kopia robocza) @@ -9,11 +9,7 @@ LIB_MCS_FLAGS = -debug /r:System.Xml.dll /r:System.dll /d:StronglyNamedAssembly NO_TEST = yo -ifeq (net_2_0, $(PROFILE)) -NO_INSTALL = yes -endif - EXTRA_DISTFILES = \ nunit.framework.dll.csproj Index: mcs/nunit20/nunit-console/nunit-console.exe.config === --- mcs/nunit20/nunit-console/nunit-console.exe.config (wersja 49739) +++ mcs/nunit20/nunit-console/nunit-console.exe.config (kopia robocza) @@ -1,92 +0,0 @@ -?xml version=1.0 encoding=Windows-1252? -configuration -!-- - Application settings for NUnit-console.exe. Do NOT put settings - for use by your tests here. - -- - appSettings - - !-- Specify the location to be used by .NET for the cache -- -add key=shadowfiles.path value=%temp%\nunit20\ShadowCopyCache / - - /appSettings - -!-- - These statements specify the runtime versions supported - in the order that they will be used if more than one - is present. You can change the order of these if you like - or remove any that do not apply. - - Since .NET 1.0 does not recognize the supportedRuntime elements, - a requiredRuntime element is used in case it is the only version - of the framework that is installed. --- - startup - - supportedRuntime version=v1.1.4322 / - supportedRuntime version=v2.0.50215 / - supportedRuntime version=v1.0.3705 / - - requiredRuntime version=v1.0.3705 / - - /startup - - !-- -The following runtime section allows running nunit under -.NET 1.0 by redirecting assemblies. The appliesTo attribute -causes the section to be ignored except under .NET 1.0version 1 -on a machine with only the .NET version 1.0 runtime installed. -If application and its tests were built for .NET 1.1 you will -also need to redirect system assemblies in the test config file. - -- - - runtime - -assemblyBinding xmlns=urn:schemas-microsoft-com:asm.v1 - appliesTo=v1.0.3705 - - dependentAssembly -assemblyIdentity name=System - publicKeyToken=b77a5c561934e089 - culture=/ -bindingRedirect oldVersion=1.0.5000.0 - newVersion=1.0.3300.0/ - /dependentAssembly - - dependentAssembly -assemblyIdentity name=System.Data - publicKeyToken=b77a5c561934e089 - culture=/ -bindingRedirect oldVersion=1.0.5000.0 - newVersion=1.0.3300.0/ - /dependentAssembly - - dependentAssembly -assemblyIdentity name=System.Drawing - publicKeyToken=b03f5f7f11d50a3a - culture=/ -bindingRedirect oldVersion=1.0.5000.0 - newVersion=1.0.3300.0/ - /dependentAssembly - - dependentAssembly -assemblyIdentity name=System.Windows.Forms - publicKeyToken=b77a5c561934e089 - culture=/ -bindingRedirect oldVersion=1.0.5000.0 - newVersion=1.0.3300.0/ - /dependentAssembly
Re: [Mono-dev] [PATCH][GMCS] add MakeGenericMethod to MethodInfo
I attach the more complete and correct patch - MakeGenericMethod is added to MethodBase instead of MethodInfo, I made necessary changes to gmcs and mbas, also the change to GenericParameterAttributes is included. One question I would like to ask is if I should also change the runtime icalls from BindTypeParameters to MakeGenericType / MakeGenericMethod, or should this be left for another patch. If this patch is ok in its state, I will commit. 2005/8/30, Michal Moskal [EMAIL PROTECTED]: Hello, The MS Aug CTP release removes BindGenericParameters/Arguments methods from System.Type and MethodInfo. Instead MakeGenericType and MakeGenericMethod should be used. Mono has the first one implemneted. The attached patch implemnets the second one. 2005-08-30 Michal Moskal [EMAIL PROTECTED] * MethodInfo.cs: Add MakeGenericMethod to match Aug CTP API. -- Michal Moskal, http://nemerle.org/~malekith/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH][GMCS] add MakeGenericMethod to MethodInfo
And the file goes here...
2005/9/2, Kamil Skalski [EMAIL PROTECTED]:
I attach the more complete and correct patch - MakeGenericMethod is
added to MethodBase instead of MethodInfo, I made necessary changes to
gmcs and mbas, also the change to GenericParameterAttributes is
included.
One question I would like to ask is if I should also change the
runtime icalls from BindTypeParameters to MakeGenericType /
MakeGenericMethod, or should this be left for another patch. If this
patch is ok in its state, I will commit.
2005/8/30, Michal Moskal [EMAIL PROTECTED]:
Hello,
The MS Aug CTP release removes BindGenericParameters/Arguments methods
from System.Type and MethodInfo. Instead MakeGenericType and
MakeGenericMethod should be used. Mono has the first one implemneted.
The attached patch implemnets the second one.
2005-08-30 Michal Moskal [EMAIL PROTECTED]
* MethodInfo.cs: Add MakeGenericMethod to match Aug CTP API.
--
Michal Moskal,
http://nemerle.org/~malekith/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Kamil Skalski
http://nazgul.omega.pl
--
Kamil Skalski
http://nazgul.omega.pl
Index: bmcs/generic.cs
===
--- bmcs/generic.cs (wersja 49356)
+++ bmcs/generic.cs (kopia robocza)
@@ -33,7 +33,7 @@
}
public bool HasValueTypeConstraint {
- get { return (Attributes GenericParameterAttributes.ValueTypeConstraint) != 0; }
+ get { return (Attributes GenericParameterAttributes.NotNullableValueTypeConstraint) != 0; }
}
public virtual bool HasClassConstraint {
@@ -195,7 +195,7 @@
if (sc == SpecialConstraint.ReferenceType)
attrs |= GenericParameterAttributes.ReferenceTypeConstraint;
else
- attrs |= GenericParameterAttributes.ValueTypeConstraint;
+ attrs |= GenericParameterAttributes.NotNullableValueTypeConstraint;
continue;
}
@@ -1733,7 +1733,7 @@
if (tc != null)
return tc.IsGeneric ? tc.CountTypeParameters : 0;
else
-return t.HasGenericArguments ? t.GetGenericArguments ().Length : 0;
+return t.IsGenericType ? t.GetGenericArguments ().Length : 0;
}
public static Type[] GetTypeArguments (Type t)
@@ -2171,7 +2171,7 @@
if (infered_types [i] == null)
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
return true;
}
@@ -2241,7 +2241,7 @@
if (!InferTypeArguments (param_types, arg_types, infered_types))
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
return true;
}
@@ -2269,7 +2269,7 @@
if (!InferTypeArguments (param_types, arg_types, infered_types))
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
return true;
}
Index: bmcs/ecore.cs
===
--- bmcs/ecore.cs (wersja 49356)
+++ bmcs/ecore.cs (kopia robocza)
@@ -2992,7 +2992,7 @@
if (gen_params.Length != atypes.Length)
continue;
-list.Add (mi.BindGenericParameters (atypes));
+list.Add (mi.MakeGenericMethod (atypes));
}
if (list.Count 0) {
Index: gmcs/generic.cs
===
--- gmcs/generic.cs (wersja 49356)
+++ gmcs/generic.cs (kopia robocza)
@@ -33,7 +33,7 @@
}
public bool HasValueTypeConstraint {
- get { return (Attributes GenericParameterAttributes.ValueTypeConstraint) != 0; }
+ get { return (Attributes GenericParameterAttributes.NotNullableValueTypeConstraint) != 0; }
}
public virtual bool HasClassConstraint {
@@ -199,7 +199,7 @@
if (sc == SpecialConstraint.ReferenceType)
attrs |= GenericParameterAttributes.ReferenceTypeConstraint;
else
- attrs |= GenericParameterAttributes.ValueTypeConstraint;
+ attrs |= GenericParameterAttributes.NotNullableValueTypeConstraint;
continue;
}
@@ -1692,7 +1692,7 @@
if (tc != null)
return tc.IsGeneric ? tc.CountTypeParameters : 0;
else
-return t.HasGenericArguments ? t.GetGenericArguments ().Length : 0;
+return t.IsGenericType ? t.GetGenericArguments ().Length : 0;
}
public static Type[] GetTypeArguments (Type t)
@@ -2128,7 +2128,7 @@
if (infered_types [i] == null)
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types);
return true;
}
@@ -2199,7 +2199,7 @@
if (!InferTypeArguments (param_types, arg_types, infered_types))
return false;
- method = method.BindGenericParameters (infered_types);
+ method = method.MakeGenericMethod (infered_types
[Mono-dev] Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Any update on those patches? The incompatible version numbers prevents using MS.NET bootstraped compiler on mono, so it would be nice to make mono more up to date. Kornel, I could help in creating the patch. 05-07-29, Kornél Pál [EMAIL PROTECTED] napisał(a): Disk space is cheap. I can get disk space for under $0.50 per Gigabyte. If you want to measure performance gains, they have to be in terms of time (reducing the number of pages read from disk: ie, show that you save at least 1 page from being read from the disk) or memory (show that you save at least one page of memory from being allocated due to mallocs that you save or from being kept paged in by the OS). I belive that altough we could add some random rubbish to compiled files like VB6 compiler does it's better not to include any unnecessary data in files. The point of view hardware is cheap is not good I think. Users could buy faster CPU and more RAM as well altough it is more expensive than HDD. Saying we don't care about HDD is the same as Microsoft does and their operating system is expanding without limits.:) From Kornel: BTW what about the 2.0.0.0 patch? I'd still like to kill all the #if NET_1_1 crap in the files and use MonoConsts.FxVersion or something. It will save us pain in the future. In this case I would like to do some more AssemblyInfo.cs centralization (movig common attributes to a common file and using a common set of attributes in all the assemblies with MS.NET attributes in mind of course) and cleanup because AssemblyInfo.cs files are a bit anarchistic currently. And adding AssemblyFileVersion attributes to all of the assemblies with the version you currently emit to the common MonoVersion.cs. And emit a contant instead of AssemblyVersion attribute that can be used in a common file. Is it OK? (I mean on OK that in addition that it meats your/our plans on Mono it will be approved if the patch is correct, without saying that we want to wait until next millenium or 101 other patches should be committed before that one. Because I don't like to waste time on patches that will not be approved in a resonable time.) Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] ByteFX mysql
You must modify the build process of your project. What are you using? Makefiles, MonoDevelop, Visual Studio? Anyway, you must add ByteFX to referenced assemblies, either by modifying compilation scripts to include mcs sources.cs -r ByteFX.Data.dll or add referenced assembly in your IDE 2005/8/8, Stefano Incontri [EMAIL PROTECTED]: Hi All, I'm a newby with C# and Mono... maybe this is a stupid question : I'm willing to use ByteFX mysql connector, but I don't know how to import or reference it in my project, the 'using' keyword doesn't find it. The message is 'Main.cs(4) error CS0246: The namespace `ByteFx.Data' can not be found (missing assembly reference?)'. Thanks Stefano ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] API change in System.Collections.Generic.KeyValuePair
Hi! In MS.NET 2.0 July CTP they have changed the System.Collections.Generic.KeyValuePair structure, so now it does not contain the fields Key and Value, but properties. I attach the patch, which fixes it, but there are two questions / issues about it. 1) Do we want the CTP API in mono now, or should I keep the patch locally and commit it after the next public release of runtime? (I don't have Beta2 at hand, but it seems that there were only Key and Value fields there - could someone check this?) 2) Key and Value are used for writing in Dictionary. I workarounded it by making the storage fields in KeyValuePair internal, and assign directly to them. Is it better to just create new instances of KeyValuePair in Dictionary (the perf. impact should not be great, since it is a structure) -- Kamil Skalski http://nazgul.omega.pl keyval.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Move System.GenericParameterAttributes to System.Reflection in .NET 2.0
Dnia roda, 15 czerwca 2005 16:25, napisae:
On Mon, 2005-06-13 at 00:49 +0200, Kamil Skalski wrote:
Attached is the patch moving GenericParameterAttributes to
System.Reflection
http://msdn2.microsoft.com/library/ms145349(en-us,vs.80).aspx
Done.
Martin, you forgot to change the actual namespace... Attached a simple patch.
--
Kamil Skalski
http://nazgul.omega.pl
Index: class/corlib/System.Reflection/GenericParameterAttributes.cs
===
--- class/corlib/System.Reflection/GenericParameterAttributes.cs(wersja
46086)
+++ class/corlib/System.Reflection/GenericParameterAttributes.cs(kopia
robocza)
@@ -32,7 +32,7 @@
//
#if NET_2_0 || BOOTSTRAP_NET_2_0
-namespace System
+namespace System.Reflection
{
[Flags]
public enum GenericParameterAttributes
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Broken mono svn builld
Hi!
This patch
http://galactus.ximian.com/pipermail/mono-patches/2005-June/05.html
caused mono svn to give:
...
checking whether Solaris gcc optimization fix is necessary... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating include/private/Makefile
config.status: creating doc/Makefile
config.status: executing depfiles commands
config.status: executing default commands
./configure[37251]: syntax error: `(' unexpected
error when trying to build on PLD Linux
(I'm trying the standard sequence - make clean; ./autogen.sh --prefix=blabla)
--
Kamil Skalski
http://nazgul.omega.pl
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] TypeBuilder.GetMethod and other updates for .NET 2.0 beta2 API
Dnia roda, 8 czerwca 2005 22:40, Martin Baulig napisa:
Hello,
I'll commit it tomorrow morning.
Don't worry, we're waiting with the release to get a few more of my
fixes in, so this'll definitely go in :-)
Sorry you had problems merging this patch. It was created against 45614.
Seems like Zoltan was faster in adding some of the similar API:
http://galactus.ximian.com/pipermail/mono-patches/2005-June/059635.html
in 45626
I'm attaching the new patch, against 45700. Hope the will be no more problems
(there are still some more 2.0 API additions there, so more conflicts are
possible).
--
Kamil Skalski
http://nazgul.omega.pl
Index: class/corlib/System/Type.cs
===
--- class/corlib/System/Type.cs (wersja 45700)
+++ class/corlib/System/Type.cs (kopia robocza)
@@ -760,6 +760,22 @@
return GetMethodImpl (name, bindingAttr, binder, callConvention, types, modifiers);
}
+ internal virtual MethodInfo GetMethod (MethodInfo fromNoninstanciated)
+{
+ throw new System.InvalidOperationException (can only be called in generic type);
+}
+
+ internal virtual ConstructorInfo GetConstructor (ConstructorInfo fromNoninstanciated)
+{
+ throw new System.InvalidOperationException (can only be called in generic type);
+}
+
+ internal virtual FieldInfo GetField (FieldInfo fromNoninstanciated)
+{
+ throw new System.InvalidOperationException (can only be called in generic type);
+}
+
+
public MethodInfo[] GetMethods ()
{
return GetMethods (DefaultBindingFlags);
@@ -1110,6 +1126,11 @@
return res;
}
+public Type MakeGenericType (Type[] types)
+{
+ return BindGenericParameters (types);
+}
+
public abstract bool IsGenericParameter {
get;
}
Index: class/corlib/System/ChangeLog
===
--- class/corlib/System/ChangeLog (wersja 45700)
+++ class/corlib/System/ChangeLog (kopia robocza)
@@ -1,3 +1,9 @@
+2005-06-09 Kamil Skalski [EMAIL PROTECTED]
+ * Type.cs: Add MakeGenericType method form .NET 2.0 beta 2 API
+
+ * Type.cs MonoType.cs: Add internal virtual Get{Method,Constructor,Field}
+ for obtaining instanciated *Info objects from non-instanciated counterparts
+
2005-06-09 Zoltan Varga [EMAIL PROTECTED]
* ModuleHandle RuntimeMethodHandle.cs RuntimeTypeHandle.cs RuntimeFieldHandle.cs RuntimeArgumentHandle.cs: Add missing 2.0 attributes.
Index: class/corlib/System/MonoType.cs
===
--- class/corlib/System/MonoType.cs (wersja 45700)
+++ class/corlib/System/MonoType.cs (kopia robocza)
@@ -224,6 +224,31 @@
}
[MethodImplAttribute(MethodImplOptions.InternalCall)]
+ extern MethodInfo GetCorrespondingInflatedMethod (IntPtr generic);
+
+ [MethodImplAttribute(MethodImplOptions.InternalCall)]
+ extern ConstructorInfo GetCorrespondingInflatedConstructor (IntPtr generic);
+
+ [MethodImplAttribute(MethodImplOptions.InternalCall)]
+ extern FieldInfo GetCorrespondingInflatedField (IntPtr generic);
+
+
+ internal override MethodInfo GetMethod (MethodInfo fromNoninstanciated)
+{
+return GetCorrespondingInflatedMethod (fromNoninstanciated.MethodHandle.Value);
+}
+
+ internal override ConstructorInfo GetConstructor (ConstructorInfo fromNoninstanciated)
+ {
+return GetCorrespondingInflatedConstructor (fromNoninstanciated.MethodHandle.Value);
+ }
+
+ internal override FieldInfo GetField (FieldInfo fromNoninstanciated)
+ {
+return GetCorrespondingInflatedField (fromNoninstanciated.FieldHandle.Value);
+ }
+
+ [MethodImplAttribute(MethodImplOptions.InternalCall)]
public extern override Type GetNestedType (string name, BindingFlags bindingAttr);
[MethodImplAttribute(MethodImplOptions.InternalCall)]
Index: class/corlib/System.Reflection.Emit/FieldBuilder.cs
===
--- class/corlib/System.Reflection.Emit/FieldBuilder.cs (wersja 45700)
+++ class/corlib/System.Reflection.Emit/FieldBuilder.cs (kopia robocza)
@@ -80,7 +80,7 @@
public override RuntimeFieldHandle FieldHandle {
get {
-throw CreateNotSupportedException ();
+return handle;
}
}
Index: class/corlib/System.Reflection.Emit/ChangeLog
===
--- class/corlib/System.Reflection.Emit/ChangeLog (wersja 45700)
+++ class/corlib/System.Reflection.Emit/ChangeLog (kopia robocza)
@@ -1,3 +1,11 @@
+2005-06-09 Kamil Skalski [EMAIL PROTECTED]
+ * ConstructorBuilder.cs FieldBuilders.cs MethodBuilder.cs: Return
+ RuntimeHandles when requested
+
+ * TypeBuilder.cs: Add static Get{Method,Constructor,Field} methods
+ from .NET 2.0 beta 2 API for obtaining instanciated
Re: [Mono-devel-list] [PATCH] TypeBuilder.GetMethod and other updates for .NET 2.0 beta2 API
Dnia roda, 8 czerwca 2005 17:31, Martin Baulig napisa: On Wed, 2005-06-08 at 15:50 +0200, Kamil Skalski wrote: I'm attaching our patch which updates mono with changes and additions in .NET 2.0 beta 2. There are some cosmetics changes of API, but most of the patch is related to TypeBuilder static methods, which are used for obtaining instanciated version of given MethodInfo (of Constructor / Field Info). Hello, thanks a lot for implementing this, it was next on my TODO list :-) The patch looks good, can you please commit ? Ah, great. It is nice that the new API will be included in upcoming release. I don't have svn access, so somebody should commit this, please :-) -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for generating debug info in System.Reflection.Emit
Dnia wtorek, 17 maja 2005 17:25, Lluis Sanchez napisa: Hi! This patch adds some basic support for generating debug info in SRE. It implements ModuleBuilder.DefineDocument and ILGenerator.MarkSequencePoint, and should be enough for most of compilers. With this patch, Boo and IKVM can generate correct debug info. This is really great news. Thanks a lot! Maybe now I will also try mono debugger for Nemerle development. The symbol writer is still implemented in Mono.CompilerServices.SymbolWriter. I added a wrapper class that implements ISymbolWritter and which is created by ModuleBuidler using reflection. This class just forwards the calls to MonoSymbolWriter (the one used by mcs). There is also a patch for reflection.c, which is a workaround for bug #74914. With this patch, MethodBuilder objects will return the correct token value after the module is saved. This fixes the problem because the debug info is generated after saving the module. I'll commit if there are no objections. Lluis. -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] On the way to make S.R.E generics API more usable
Hi!
On my work towards implementing generics emission in Nemerle I get into
following problems:
- MS is adding new methods to TypeBuilder for obtaining members of
instanciated generic types:
public static MethodInfo GetMethod (Type instanciated, MethodInfo meth)
public static ConstructorInfo GetConstructor (Type instanciated,
ConstructorInfo cons)
public static FieldInfo GetField (Type instanciated, FieldInfo fld)
see
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=d507aff5-b1e3-49b4-8178-065a00d2f15e
they are already available in Feb CTP, though not documented anywhere.
And not suprisingly, I need them... I hacked something in mono sources, so
it is partially enough for my experiments now, but it would be nice to have
it implemented correctly.
I'm not sure what would be the *correct* way of implementing it. I tried
iterating on instanciated.GetMethods (), but comparing if member signatures
match isn't that easy (for example GetParameters () method sometimes throws
exception when used for TypeBuilder)
Any suggestions?
- There is a new MakeGenericType method in TypeBuilder, which simply replaces
BindGenericTypes, which gets obsoleted (attached patch to add this method to
TypeBuilder)
- I need the HasGenericArguments method from TypeBuilder, which currently in
mono is throw NotImplementedException - attached patch to make it simply
check for presence of generic_params.
Kamil Skalski
Index: class/corlib/System/Type.cs
===
--- class/corlib/System/Type.cs (wersja 42625)
+++ class/corlib/System/Type.cs (kopia robocza)
@@ -1040,6 +1040,11 @@
return res;
}
+public Type MakeGenericType (Type[] types)
+{
+ return BindGenericParameters (types);
+}
+
public abstract bool IsGenericParameter {
get;
}
Index: class/corlib/System.Reflection.Emit/TypeBuilder.cs
===
--- class/corlib/System.Reflection.Emit/TypeBuilder.cs (wersja 42625)
+++ class/corlib/System.Reflection.Emit/TypeBuilder.cs (kopia robocza)
@@ -1381,7 +1381,7 @@
public override bool HasGenericArguments {
get {
-throw new NotImplementedException ();
+return generic_params != null;
}
}
Re: AW: [Mono-devel-list] Compiler thoughts, 2
Dnia czwartek, 17 marca 2005 19:31, Miguel de Icaza napisa: to find the Volatile bits on a field, This has been filed in MS product feedback some time ago: http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=376f87ea-71b8-4fd4-9366-9b9672a1b99a It is a minor, by annoying lack of functionality, so it would be good to vote on it. methods before you create the types. The information is readily available, but the API just refuses to give it you, so we had to create a parallel universe to track the information ourselves. This is a problem for all languages using SRE. I guess productfeedback is *some* way to get it fixed by MS side. SRE has one big advantage, you can easily set target of compiler to compile into memory and you created types immediately, thus it quite strightforward to compile features like eval, where you create code in you program and want it to execute. Kamil Skalski ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
