Re: [Mono-docs-list] monodoc Licensing
Hi Jon, Long time, no talk. I hope you are doing well. MIT/X11 is fine for anything I've written in monodoc. -b On Fri, 25 Jan 2008, Jonathan Pryor wrote: Joshua et al, You wrote and contributed to the monodoc module many related utilities, such as monodocer, monodocs2html, etc., in addition to monodoc/engine and related documentation providers. The monodoc module currently claims to be under the GPL, as does `monodocer --version` and monodocs2html. How would you feel about relicensing these contributions under MIT/X11? No major reason, aside from an eventual simplification of Mono's licensing policy from GPL/LGPL/MIT-X11 to LGPL/MIT-X11, and I don't see much reason to prevent non-GPL-compliant reuse of these libraries and apps... Thanks, - Jon ___ Mono-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/31/06 Miguel de Icaza wrote: Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). While that is clearly a very inefficient way to do things, we can't say it is the issue that is making vbnc unusable especially in mono. First, it depends if the tokens are kept for the whole source or just one file at a time: in the latter case it should not be so bad, since the vbnc compiler is spread over hundreds of tiny files, so the actual memory usage should be limited. Besides a non-moving GC can be faster at handling such long lists than a moving one (one of my long-linked-list stress It seems that the linked list for *all* files was kept for the *entire* duration of the gc, from my profiling on windows. Rolf, can you confirm this? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hey, Even after the patches I suggested to Rolf, VBNC had a heap size of ~100mb on MSFT. I'm a bit suprised Mono is having so much trouble. It's quite possible this is a GC issue. The compiler stores a very large linked list of all tokens in the program. With a non-generational gc, we may be having very bad performance from walking the heap so much. You might try aborting before the resolve phase, to see if you can --profile before that point on Mono. Also, it's worth using profilers on MSFT's runtime (most commercial ones have demos, that's always worked for me). Sadly, I'm not going to have time to take a look at this for quite a while. -b I was using SVN HEAD. Please try the previously referenced patch, maybe you will be able to find out something more. The compiler don't seem to have endless recursions or loops but I may be wrong. Other than this problem I have no other idea, because it's running, but is slow and eats memory. Kornél - Original Message - From: Rolf Bjarne Kvinge [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Sent: Sunday, October 29, 2006 7:37 PM Subject: Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono Hello, Are you using latest svn for vbnc? A few optimization was committed this week so it should be faster. If it is running out of memory though I think there might some other problem optimizations won't resolve. Rolf On Sun, 29 Oct 2006 19:21:07 +0100, Kornél Pál [EMAIL PROTECTED] wrote: Hi, Using the patch in http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021093.html no exception ocurred in vbnc but I wasn't able to finish the resolve phase because it runs out of memory. The machine I used has 1 GB RAM and is running Windows XP. And I think such a machine should be able to run a VB compiler. Note that running the same binary on MS.NET is much faster and requires much less memory. If you have any idea making VBNC's footprint smaller please let me know. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ 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
[Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Hey guys,
On the 2.0 profile, Encoding uses the char*/byte* version of encoding
methods to avoid allocating memory. One code path missed this
optimization, I've attached a fix.
This code path ends up being used in Banshee quite a bit on their tree
view (basically, every time the model is queried, this method gets called
in passing String objects to char*).
A few things to think about:
- It might pay to do something on the 1.0 profile as well.
- Paolo, can you comment on how this kind of change works with the moving gc?
-bIndex: Encoding.cs
===
--- Encoding.cs (revision 66966)
+++ Encoding.cs (working copy)
@@ -211,12 +211,18 @@
// Convenience wrappers for GetByteCount.
public virtual int GetByteCount (String s)
{
- if (s != null) {
- char[] chars = s.ToCharArray ();
- return GetByteCount (chars, 0, chars.Length);
- } else {
+ if (s == null)
throw new ArgumentNullException (s);
+#if NET_2_0
+ unsafe {
+ fixed (char* cptr = s) {
+return GetByteCount (cptr, s.Length);
+ }
}
+#else
+ char[] chars = s.ToCharArray ();
+ return GetByteCount (chars, 0, chars.Length);
+#endif
}
public virtual int GetByteCount (char[] chars)
{___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for fixing binary search
Hey, This also exists for qsort object objPivot = keys.GetValueImpl ((low + high) / 2); -- Ben On Sat, 2006-06-03 at 18:04 -0400, Duncan Mak wrote: Hello, As pointed out by this blog post by Joshua Bloch: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html The current by-the-book implementation of BinarySearch has an integer overflow bug due to this: int mid = (low + high) / 2; This bug manifests itself when (low + high) Int32.MaxValue. Here's a patch for fixing this in Array, ArrayT and ArrayList. Duncan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono profiler agent for jitted code
Hey Jason, I'm glad to see interest in this again. I took a quick look at this during a week I was in Boston over my winter break. I checked some code in to svn to emit a ELF file in (what I think is) the correct format for oprofile as it works right now. I know the state of anonymous samples for oprofile is in quite a state of flux. Once a proposal and implementation is in place for oprofile, we have a team of people whom I'm sure we can get to have a working mono agent (Paolo, Massi, Zoltan, and myself should all be up to the task, time permitting). If you need help navigating the Mono code base, please feel free to ask on this list, or join us on IRC. -- Ben This is rather off topic from the original thread What would you like to see in Mono. Thus, I created a new thread for this discussion while leaving Joe's original message in this mail. I have been working on a proposal to extend Oprofile to profile the anonymous samples resulted from jitted code. I am not familiar enough with Mono to determine how such profiler will benefit Mono. I would like to know if such profiler would benefit Mono, and also how would you use this profiler if it is available. If this profiler can benefit Mono, I would like to write a profile agent for Mono and make sure that it will work with Mono. It would also be great if someone can point me the files that I should check if I ever need to look at how Mono creates jit code. Jason [EMAIL PROTECTED] wrote: Hi, This stretched out a bit more than I originally intended. :) On Tue, 2006-03-28 at 20:47 -0500, Miguel de Icaza wrote: What would be the top feature you would like to see in Mono? Although not really in Mono itself, one thing I would like to see is better integration with automake. The main Beagle Makefile.am is currently 1181 lines. There is definitely room for us to clean this up substantially a bit on our own, but I've love to see things like compilation handled automatically, installation of .mdb files, maybe even automatic gacutil for assemblies, etc. Beyond that, additional profiling tools would help a lot. Specifically: * A profiler that tracked threads. * A profiler that tracked when files were opened and closed. * A profiler which detected potential deadlocks. I'd recommend really investigating all the profilers and debugging tools available for Java and then work on implementing them in Mono. As I've said to you personally many times before, the biggest difficulty in developing applications in Mono at this point is a lack of high-quality tools. In addition, various bug fixes related to profiling: heap-buddy locks up instantaneously on SMP machines (not sure if Jon ever filed that or had just had discussions about it with Ben and others) and more robust reporting of the stack traces of all threads with SIGQUIT. It might also be helpful if the various profilers could be integrated into MonoDevelop or something to give profiling info while the program is running. This data is most useful when it can be visualized. Coverage tools, both at compile and runtime, integrated into Mono would be handy. I am sure .NET ones exist out there, but they're neither immediately obvious nor immediately useful inside a Unix Mono development environment. And one thing that has always bugged me: my apps all behave strangely and then crash when I recompile underneath a running instance. That's very annoying, and I suspect it's also a problem if you upgrade packages and an app is running as well. Joe ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] monodoc - no mcs sources
On Tue, 2006-02-21 at 00:23 +, Lieven De Keyzer wrote: From: Rafael Ferreira [EMAIL PROTECTED] To: Lieven De Keyzer [EMAIL PROTECTED] CC: mono-list@lists.ximian.com Subject: Re: [Mono-list] monodoc - no mcs sources Date: Mon, 20 Feb 2006 16:07:02 -0700 On Mon, 2006-02-20 at 22:48 +, Lieven De Keyzer wrote: I've downloaded, compiled and installed mono, libgdiplus and gtk-sharp from http://go-mono.com/sources/ . Now I want to compile monodoc, but at the end of the configure step, I'm being told: The sources of the mono compiler (mcs) were not found. To include the COMPILER ERRORS in the documentation, download the mcs sources and rerun autogen.sh How can I install these sources? I don't see a mcs source tarball nor an option during the configuration of mono to install the sources. under mono/mcs in the tarball you downloaded. Yes, but how to I install them? A normal make install doesn't. monodoc and mcs need to be in the same directory. For example: msvn/ mono/ mcs/ gtk-sharp/ monodoc/ -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Refactoring in System.Data.Common
On Sun, 2006-01-29 at 05:13 -0800, Konstantin Triger wrote: I made some methods/fields in System.Data.Common/ExceptionHelper.cs, DbTypes.cs to enable reuse in other assemblies like System.Data.OracleClient. Isn't this creating new public types? We can't do that. It would prevent the other db providers from running on the Microsoft runtime (handy for testing). If you need to reuse stuff like this, we need to figure out a way to let the build system do that. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Speed of MethodInfo.Invoke?
On Fri, 2006-01-27 at 08:50 -0500, Chad Robinson wrote: I have a question about Mono internals (or CLR internals?). How is MethodInfo.Invoke actually implemented? I'm trying to write an extensible application that would support loading custom modules in external DLLs. However, the application is also tightly performance constrained. I guess what I'm asking is, what is the overhead like for invoking a method discovered through MethodInfo (assume I discover in advance, assume 2-3 object ref params) vs. a traditional call? The fastest way is through a delegate, which takes care of argument binding for you. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-dev] Re: [Mono-patches] r55711 -trunk/mcs/class/System.Web/System.Web.UI
I doubt there are enough uses of Color.Empty to justify a 3rd opcode.
Actually, the best use of a 3rd opcode would be for colors that have 100%
alpha (which is the case for most color values from s.web).
Use the method I suggested in the previous value (choose a knowncolor to
use as a flag and if the knowncolor is that value, use one extra bool to
disambig. Or you could even use the -1 knowncolor).
-- Ben
Please review the reworked patch.
Regards,
Konstantin Triger
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben
Maurer
Sent: Sunday, January 22, 2006 9:58 PM
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Re: [Mono-patches] r55711
-trunk/mcs/class/System.Web/System.Web.UI
Hey,
I think this patch adds more bytes than needed to the serialization. An
easy way of saving a few bytes would be to make Empty a sort of known
color. So if the known color that was written out was 0, we would then
write an additional byte to disambig. between known color 0 and empty.
-- Ben
On Wed, 2006-01-18 at 03:57 -0500, Konstantin Triger
([EMAIL PROTECTED]) wrote:
Author: kostat
Date: 2006-01-18 03:57:28 -0500 (Wed, 18 Jan 2006)
New Revision: 55711
Modified:
trunk/mcs/class/System.Web/System.Web.UI/ChangeLog
trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs
Log:
preserve emptiness in ColorFormatter
Modified: trunk/mcs/class/System.Web/System.Web.UI/ChangeLog
==
--- trunk/mcs/class/System.Web/System.Web.UI/ChangeLog
2006-01-18 08:51:22 UTC (rev 55710)
+++ trunk/mcs/class/System.Web/System.Web.UI/ChangeLog
2006-01-18 08:57:28 UTC (rev 55711)
@@ -1,5 +1,9 @@
2006-01-18 Konstantin Triger [EMAIL PROTECTED]
+* ObjectStateFormatter.cs: preserve emptiness in ColorFormatter. +
+2006-01-18 Konstantin Triger [EMAIL PROTECTED]
+
* HtmlTextWriter.cs: perform case insensitive compare;
return correct key in default case.
Modified:
trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs
==
--- trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs
2006-01-18 08:51:22 UTC (rev 55710)
+++ trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs
2006-01-18 08:57:28 UTC (rev 55711)
@@ -663,19 +663,24 @@
if (!c.IsKnownColor) {
w.Write (PrimaryId);
-w.Write (c.ToArgb ());
+w.Write(c.IsEmpty);
+if (!c.IsEmpty)
+w.Write (c.ToArgb ());
} else {
w.Write (SecondaryId);
-w.Write ((int) c.ToKnownColor
());
+w.Write(c.IsEmpty);
+if (!c.IsEmpty)
+w.Write ((int)
c.ToKnownColor ());
}
}
protected override object Read (byte token,
BinaryReader r, ReaderContext ctx)
{
+bool isEmpty = r.ReadBoolean();
if (token == PrimaryId)
-return Color.FromArgb
(r.ReadInt32 ());
+return isEmpty ? Color.Empty :
Color.FromArgb (r.ReadInt32 ());
else
-return Color.FromKnownColor
((KnownColor) r.ReadInt32 ());
+return isEmpty ? Color.Empty :
Color.FromKnownColor ((KnownColor) r.ReadInt32 ());
}
protected override Type Type {
___
Mono-patches maillist - Mono-patches@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-patches
___
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
[Mono-dev] Re: [Mono-patches] r55711 - trunk/mcs/class/System.Web/System.Web.UI
Hey,
I think this patch adds more bytes than needed to the serialization. An
easy way of saving a few bytes would be to make Empty a sort of known
color. So if the known color that was written out was 0, we would then
write an additional byte to disambig. between known color 0 and empty.
-- Ben
On Wed, 2006-01-18 at 03:57 -0500, Konstantin Triger
([EMAIL PROTECTED]) wrote:
Author: kostat
Date: 2006-01-18 03:57:28 -0500 (Wed, 18 Jan 2006)
New Revision: 55711
Modified:
trunk/mcs/class/System.Web/System.Web.UI/ChangeLog
trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs
Log:
preserve emptiness in ColorFormatter
Modified: trunk/mcs/class/System.Web/System.Web.UI/ChangeLog
===
--- trunk/mcs/class/System.Web/System.Web.UI/ChangeLog2006-01-18
08:51:22 UTC (rev 55710)
+++ trunk/mcs/class/System.Web/System.Web.UI/ChangeLog2006-01-18
08:57:28 UTC (rev 55711)
@@ -1,5 +1,9 @@
2006-01-18 Konstantin Triger [EMAIL PROTECTED]
+ * ObjectStateFormatter.cs: preserve emptiness in ColorFormatter.
+
+2006-01-18 Konstantin Triger [EMAIL PROTECTED]
+
* HtmlTextWriter.cs: perform case insensitive compare;
return correct key in default case.
Modified: trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs
===
--- trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs
2006-01-18 08:51:22 UTC (rev 55710)
+++ trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs
2006-01-18 08:57:28 UTC (rev 55711)
@@ -663,19 +663,24 @@
if (!c.IsKnownColor) {
w.Write (PrimaryId);
- w.Write (c.ToArgb ());
+ w.Write(c.IsEmpty);
+ if (!c.IsEmpty)
+ w.Write (c.ToArgb ());
} else {
w.Write (SecondaryId);
- w.Write ((int) c.ToKnownColor ());
+ w.Write(c.IsEmpty);
+ if (!c.IsEmpty)
+ w.Write ((int) c.ToKnownColor
());
}
}
protected override object Read (byte token,
BinaryReader r, ReaderContext ctx)
{
+ bool isEmpty = r.ReadBoolean();
if (token == PrimaryId)
- return Color.FromArgb (r.ReadInt32 ());
+ return isEmpty ? Color.Empty :
Color.FromArgb (r.ReadInt32 ());
else
- return Color.FromKnownColor
((KnownColor) r.ReadInt32 ());
+ return isEmpty ? Color.Empty :
Color.FromKnownColor ((KnownColor) r.ReadInt32 ());
}
protected override Type Type {
___
Mono-patches maillist - Mono-patches@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-patches
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] System.Web.UI/HtmlTextWriter.cs issue
On Sun, 2006-01-22 at 04:17 -0800, Konstantin Triger wrote: if (!onclick.Trim().EndsWith(;)) EndsWith is culture sensitive, so we need to make sure to use an invariant culture version. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-list] Profiling web app to find where memory is going
I'm not sure if this is related but there are some terrible
inefficiencies in following two classes
mcs/class/corlib/System.IO/TextWriter.cs
mcs/class/System.Web/System.Web/HttpWriter.cs
I've not had a chance to make a patch yet, so I'll explain so someone
else can if they want to get it done before I can. But suffice to say
that how one calls Write on a TextWriter output stream in XSP/Mod_mono
can double your connections/sec (as it did for me)!
It comes down to this method in TextWriter.cs
public virtual void Write (char[] value)
{
if (value != null) {
for (int i = 0; i value.Length; ++i)
Write (value [i]);
}
}
Which I think should look like this
public virtual void Write (char[] value)
{
// No if statement needed since TextWriter is abstract
// the implementing class should take care of checking for null.
Write(value, 0, value.Length);
}
I fixed this part of the issue in System.IO. Thanks for pointing this out!
-- Ben
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-dev] UrlEncode difference in dotnet and mono
+ for (char c=Char.MinValue; c128; c++) chars are from 0 to 2^16-1 -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Data test suite
Hello all, Attached is another bulk of System.Data tests from Mainsoft repository. It brings 100 new tests but also introduces 7 new failures. If no one object I'll commit. default_centum_tests := \ $(centum_tests) \ class/System.XML\ class/System.Data S.Data is one of the nunit suites that must pass for distcheck, etc to pass. So, to add a test that is failing, one must add [Category (NotWorking)] -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] udrec.exe doesn´t work anymore after updating SuSE 10 mono packets (1.0.x) to 1.1.12 from go-mono.org
Unhandled Exception: System.NotImplementedException: The requested feature is not implemented. in 0x0001d System.Threading.Thread:Interrupt () in 0x000ac Resend:Acknowledge (.UdpPacket packet) in 0x001e6 Record:UdpReceiver () in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () I´ve attached the source code witch includes the method with the unhandled exception. Do i have to contact the author of the software about the problem or is the code perfectly ok and it´s just a problem of the new mono release? We had never implemented this function. However, before it was a nop, while now we say that it hasn't been implemented. Before, it could have silently caused bugs in your program. I'm not sure how hard it would be to implement this. Somebody else commented about this specific app. The app isn't really using the threading APIs in the correct way, and could be buggy even on windows. I'd advise you contact the author. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] UrlEncode difference in dotnet and mono
Hi Gonzalo,
I found that UrlEncode behaves differently in dotnet and Mono, namely
Mono encodes the asterisk (*) symbol into %2a.
The following code prints different values, for example:
public static void Main ()
{
Console.Out.WriteLine
(System.Web.HttpUtility.UrlEncode(aaa*bbb));
}
A naive fix might be like this, but may be there are similar problems
with other characters. What do you think?
This should really come with a unit test. In fact, what really should be
done is to generaate a table of UrlEncode (c) for c in [0...char.MaxValue]
on msft and check that we give the same results. This would make sure we
have no other issues.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] System.Threading.Thread::Interrupt no longer implemented?
On Sat, 2005-12-17 at 22:19 +0100, [EMAIL PROTECTED] wrote: I have been using an application called udrec.exe (some Streaming client for a DVB receiver box). Until a few days ago I have been running it under some 1.0.x Mono version (don't remember which one exactly, unfortunalety). So far all was great. Since the latest upgrade to 1.1.10 I keep getting the following Exception: Unhandled Exception: System.NotImplementedException: The requested feature is not implemented. in 0x0001d System.Threading.Thread:Interrupt () in 0x000ac Resend:Acknowledge (.UdpPacket packet) [...] Any idea what has changed between 1.0 and 1.1 Mono that might cause this situation? The code in question uses some UDP connection controlled by its own thread, which it awakens from Thread::Sleep using Thread::Interrupt as soon as it has anything to send. We never had this code implemented. I think we may have added a throw to warn the user about this. Interrupt is the wrong way to implement this. You want to use Monitor.Pulse and Monitor.Wait. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [PATCH] SecureString implementation
On Fri, 2005-12-09 at 15:14 -0500, Sebastien Pouliot wrote: Hello, This patch almost complete the SecureString implementation. The missing pieces are: - the new Marshal.SecureStringTo... methods; and - that, AFAIK, the runtime doesn't support CriticalFinalizerObject SecureString is implemented on top of ProtectedMemory. On Windows Data Protection API (DPAPI) is used to implement ProtectedMemory while on Linux (and other platforms) I added AES support into the runtime (so we get partial ProtectedMemory support). The AES implementation used (too large to be part of the patch) can be found at: http://www.mirrors.wiretapped.net/security/cryptography/algorithms/aes/aes-c-rijmen/ P.S. Support for some of the new Marshal methods will be added later. Why does this need to be implemented in unmanaged code? The win32 apis could be pinvoked, and we already have an AES implementation in managed code. Your code mentioned ProtectedMemory is in System.Security.dll - move this into the runtime/icall. If that is the only reason, there are workarounds we could use (reflection to acquire a delegate, implement it in mscorlib and use the internals visible to stuff). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] SecureString implementation
I think I am confused about the design of ProtectedMemory, can you correct the errors I make in the following reply? Mostly this because I am curious about the API now ;-). On Fri, 2005-12-09 at 17:39 -0500, Sebastien Pouliot wrote: Hello Ben, On Fri, 2005-12-09 at 16:28 -0500, Ben Maurer wrote: Why does this need to be implemented in unmanaged code? The win32 apis could be pinvoked, and we already have an AES implementation in managed code. Oh, believe me I have a *much* higher preference to managed code (and I did try it) but in the end the choice wasn't about how, it was about why. The use cases for ProtectedMemory (and SecureString is very similar) are very different from the general use cases of cryptography. I won't get in long (and potentially boring for some) details (there's lot of docs on MSDN for interested people) but PM and SS are mainly used to limit the window of opportunity to access some data during software execution. The primary goal of ProtectedMemory (or SecureString) seems to be: 1. To prevent the protected value from being exposed should it ever be swapped to disk (and the computer rebooted into an OS that could read the swap file) 2. To reduce the window for for a process with access to the program's address space to view the data (what is an example of where somebody would have access to the programs address space but can't just call the DAPI code to decrypt the string? I don't think I understand this case) 3. (SecureString) Allow untrusted APIs to be given a string without being able to read it. For example, I could give somebody a password for a web service and know that they'd never be able to get the password and send it to a place I didn't want it to go. Right? There are some reasons this cannot be build on top of the managed implementation. The biggest one, IMHO, is that the symmetric algorithms in .NET have a design flaw[1]: the secret key is publicly exposed (and some would say it's by design ;-). This it's not a big deal for the most common usage where you already supply, hence know, the secret key. However the lack of encapsulation of the key (like provided in CryptoAPI, and many other toolkits, using opaque handles) makes it hard to share the use of a common key without sharing the key itself. By hard I mean it's too easy to share so it destroy the real advantage of using PM/SS (as the window of opportunity on the secret key would be larger than on the protected data). How does having encapsulated in the runtime add additional security? Somebody who has access to reflect on private APIs (such as the secret key for ProtectedMemory/SecureString) should be able to get this data from the runtime just as easily (well, they might need some more hackery as the C library obviously isn't reflectable. But it seems to be protection by obscurity rather than real protection). Could it be implemented differently ? Maybe. ProtectedData is very similar but has some different rules (e.g. longer-term) and it's API makes it easy to use asymmetric cryptography (which doesn't have the design flaw [1]) so it was fully implemented in managed code. However a quick look at the PM API shows, without a doubt, that the implementation is based on a symmetric block cipher. Could I modify the managed AES implementation to achieve this ? Probably for a good chunk of the current code/features. Hardly for the other MemoryProtectionScope options. [1] The asymmetric algorithms have the opaque concept (using the CspParameters class) which can (this is really implementation dependent) allow keypairs to be used without disclosing the private key (e.g. by refusing to export it). How is this opacity implemented? If I have the ability to read a random address in memory, can't I (with some level of reverse engineering) find the shared key with no more effort than I needed to gain access to the secure string in the first place? How is the shared key protected from being swapped to disk? -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono-find-provides
On Wed, 2005-11-30 at 12:07 -0600, Mike Kestner wrote: The following patch is a stab at extending mono-find-provides to identify assembly versions supported by policy assemblies. The script currently exposes the policy assemblies as: mono(policy.2.4.gtk-sharp) = 0.0.0.0 instead of the desired: mono(gtk-sharp) = 2.4.0.0 Will commit unless somebody can think of a better way. This looks good to commit. It'd be nice to have something that would handle something called policy-enforcer (ie, make monodis explicitly say this is a policy module). Not sure how that would be done. One other minor issue is that somebody might want to say Build-Depends: mono(gtk-sharp) = 2.4.0.0. The policy thing doesn't really provide gtk-sharp 2.4 for building (because the resulting assembly will depend on another version). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch for Mono.Cairo to rename Graphics to Context
On Tue, 2005-11-29 at 10:35 -0600, Mike Kestner wrote:
We are already exposing Cairo.Graphics in the 2.7.1 release of Gtk#.
It's an unstable release, so I can change the symbol still, but the
change as posted would break 2.7.1 on newer mono releases.
If this change is going to be made, at the very least I would suggest
adding something like:
[Obsolete (Replaced by Cairo.Context)]
public class Graphics : Context {}
That would at least give source compat, if not runtime compat. But I
don't personally think it's worth changing just to be consistent with
other language bindings.
I really hope we aren't considering the Cairo bindings to be stable
right now. I took a quick look and found a few api issues:
* Things like Point are classes not structs. This is confusing as
all the other graphics apis (S.Drawing, Gdk) use structs.
* Point, Color, etc use public fields rather than properties. For
example, Color should probably check that r,g,b,a are = 1.0.
* There are many apis to do the same thing:
// FIXME should be made into a property
public void FontSetSize (double size)
{
CairoAPI.cairo_set_font_size (state, size);
}
public double FontSize {
set { CairoAPI.cairo_set_font_size (state, value); }
}
public void SetFontSize (double scale)
{
CairoAPI.cairo_set_font_size (state, scale);
}
public void SelectFontFace (string family, FontSlant slant,
FontWeight weight)
{
CairoAPI.cairo_select_font_face (state, family, slant,
weight);
}
public void FontFace (string family, FontSlant s, FontWeight w)
{
CairoAPI.cairo_select_font_face (state, family, s, w);
}
public IntPtr Handle {
get {
return surface;
}
}
public IntPtr Pointer {
get {
return surface;
}
}
* Other todos in the API, (See Graphics.cs around line 531).
* Inconsistent following of API guidelines wrt case of API names:
* public Cairo.Color ColorRgb {
* public void SetSourceRGB (double r, double g, double b
* (Micorosft uses public static Color FromArgb (int argb))
In short, I don't think this API has had the level of auditing needed to
declare it stable. If we consider the current API to be stable, we will
be left with binding full of [Obsolete] methods and riddled with some
unfixable issues.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] how to improve mono performance
On Thu, 2005-11-17 at 23:32 -0800, zhu shi song wrote: I insist that performance is the key factor for key applications. For example, we now have one enterprise web query application. Every day between 8:30AM and 12:00AM, it serve about 2 requests. Now we use one P4 2.6G PC Server with 512M DDR running Windows 2003 Server, it works well. If we port it to Linux + Mono, we must upgrade the hardware to meet the same workload. Have you actually ported and measured this? From your previous emails it sounds like you haven't. Just because something can add doubles N times faster does not mean that it will be N times faster for your application. If you'd like us to help you with your application, you are going to have to do something more than show us issues with our GC and Register Allocator that we already know about (See Miguel's blog: http://tirania.org/blog/texts/mono-status.html) What we need is: * Output of --profile from *your application* running on mono under realistic load * (If possible) The source code to your application (I am sure that Miguel could help you if you need an NDA, etc) so that we can better understand why some functions show up in the profile To reiterate: your benchmarks do not help us fix *your* problems, at least not in the short term. I'd also point out: 20,000 requests / (3.5 hours) = 1.5 requests / second Is your server using *all* it's cpu power for 1.5 requests/sec? Maybe you can make small optimizations in your application which will help it on either platform (I recently encountered a web application where submissions were taking 20 seconds each, it turned out that we did not use indexes correctly in sql server. A little bit of DBA action made requests take 1 second each). It's often easier to optimize the application than the platform. This seems like a small price to pay for the benefit of not having to deal with the latest worm, patch Tuesday and the general pain of Windows system administration (not to mention the money one saves from the Windows license!) -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] how to improve mono performance
On Fri, 2005-11-18 at 03:19 -0500, Ben Maurer wrote: Is your server using *all* it's cpu power for 1.5 requests/sec? Maybe you can make small optimizations in your application which will help it on either platform (I recently encountered a web application where submissions were taking 20 seconds each, it turned out that we did not use indexes correctly in sql server. A little bit of DBA action made requests take 1 second each). It's often easier to optimize the application than the platform. This seems like a small price to pay for the benefit of not having to deal with the latest worm, patch Tuesday and the general pain of Windows system administration (not to mention the money one saves from the Windows license!) Please don't take this to mean that we expect performance to be our user's problem. Many of the project's hackers (including myself) are dedicated to providing a high performance runtime. However, there's only so much we can do with limited resources. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Error compiling 1.1.10
On Wed, 2005-11-16 at 15:58 -0500, David P. Donahue wrote: I just tried using the installer for Mono 1.1.10 to try and get around my compilation issues, but now when I try to view any ASP .NET page my error log shows the output pasted below. So it looks like whatever's causing me to be unable to compile 1.1.10 is also causing me to not be able to run the installer version. Any ideas? As a side note, I would prefer to compile from source rather than use the installer, if possible. ## BEGIN PASTE ## /opt/mono-1.1.10/bin/mono: relocation error: /opt/mono-1.1.10/bin/mono: symbol epoll_create, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference You have a very old version of glibc (pre rh9). The installer will only work on post rh9 distros. No idea why you have the compilation error. It could have something to do with your distro. Wade -- is it possible for us to detect this in the installer and give an error? -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [PATCH] A fastpath dead code elimination
On Tue, 2005-11-15 at 15:14 -0500, Miguel de Icaza wrote:
Hello,
The alias analysis pass has O(n) complexity (n = code size), it is
just a linear sweep on the list of instructions.
Then, deadce operates one BB at a time, scanning the code linearly
and using the liveness bits as start/end conditions (so it is O(n)
as well).
Is there is a threshold that will disable the optimization from running?
Massi's code is inside:
if (cfg-opt MONO_OPT_LINEARS) {
We already have:
if ((cfg-num_varinfo 2000) !mono_compile_aot) {
/*
* we disable some optimizations if there are too many variables
* because JIT time may become too expensive. The actual number
needs
* to be tweaked and eventually the non-linear algorithms
should be fixed.
*/
cfg-opt = ~ (MONO_OPT_LINEARS | MONO_OPT_COPYPROP |
MONO_OPT_CONSPROP);
cfg-disable_ssa = TRUE;
}
Obviously though, that comment about tuning still applies.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-list] .Net Membership API Support
On Mon, 2005-11-14 at 21:43 -0500, Kellner, Peter wrote: Speaking of Membership, is anyone working on that class? If so, is the plan to make a provider for mysql since Microsoft does not have that? Well, there are some basic stubs that I did (a long time ago). But AFAIK, nobody is working on implementing one of the providers. IMHO, SqlMembershipProvider (if it is implemented) should be written so that it queries a mssql server with the schema that msft's framework uses -- there would be some value to being able to share an authentication database with apps that are written on windows. Also, if somebody wants to quickly migrate an application from windows to linux, it may be easiest to first do the web part, then the db part. (in fact one app that I am working on for school would benefit greatly from being able to attach to the MSFT schema). If we want to have a provider that uses a free database (which is needed), it should probably be a mono specific assembly (that way people on Windows can use it too, if they don't want to pay $1000 for sqlserver (and for some reason can't use don't want sqlexpress). We could still make this class the default in Mono's machine.config, so that things worked out of the box (however, for this to really work, we'd need something like sqlexpress's database attaching). In terms of mysql, pgsql might be a better choice as the mysql provider is now GPL and we are no longer updating it from upstream. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] SVN case conflict
On Thu, 2005-11-10 at 12:20 +0100, Gena wrote: Hello, I'm trying to checkout the SVN trunk for mono in my Windows XP box, but there is one file that has the same name Upper and Lower case, this makes conflict and I get an error and can't continue with TortoiseSVN. I found some solutions for this [1] but all of them in the server side, I think for compatibility the best is don't have same-name-different-case files, this also happens with MacOS X [2] Anyway, the files are not from the source code: svn://svn.myrealbox.com/source/trunk/website/newsitems/jun-28.html svn://svn.myrealbox.com/source/trunk/website/newsitems/Jun-28.html (Note the j/J in the name) [1] http://tortoisesvn.sourceforge.net/?q=case_conflict_solution [2] http://subversion.tigris.org/issues/show_bug.cgi?id=667 Thank you, Rodrigo Queipo. -- Saludos, Rodrigo. Hi Rodrigo, thanks for the links, did you solve the problem? Is there another solution to fix it on a client side (i.e. provide some SVN configuration file to skip these files during update)? Please anybody delete the *website/newsitems/Jun-28.html* file :). I guess it would be the best if someone will install in the repository something like sripts in [1] which will prevent SVN server to create 2 files different only by case. FYI, there is no reason to check out /trunk/. You will get way too much stuff. You should check out /trunk/mcs, /trunk/mono, etc. There are a few scripts that would be nice to put for some quick error checking. For example, I'd really like one that forbids new text files that aren't svn:eol-style=native. In a similar vein, it'd be great to have one that forbids users from adding \r\n lines to a file that is completely \n. It's more a matter of us having time to QA and in some cases write the scripts. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .Net 2.0 code failing on mono
Hey,
On Thu, 2005-11-10 at 16:19 -0700, Ron Vered wrote:
My company is not officially supporting mono and some client WinForms
code was built for .net 2.0.
With my limited bandwidth, I would like to help the cause of mono to
make this code run also on mono.
When naively running the client app with mono (1.1.9.2) I get a
dialougue with
** ERROR **: file class.c line 2233 (mono_class_setup_parent): should
not be reached aborting...
With no additional information about the problem.
Guessing it maybe related to missing assemblies / implementation, I
have tried:
mono --trace=M:Assembly:GetTypes
which produces no information.
The lines in question look like:
if (!MONO_CLASS_IS_INTERFACE (class)) {
class-parent = parent;
if (!parent)
g_assert_not_reached (); /* FIXME */
This code looks like it is trying to initialize the parents of the class
being setup. Maybe you are inheriting from a new 2.0 class that we have
not created?
I'd first try compiling your program with gmcs. If there are classes
that we don't have, it should be more easily apparent there.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] To split or not to split Mono?
On Thu, 2005-11-03 at 22:24 +0100, Kornél Pál wrote: The problem is that some modules are evolving much faster than the others. It's a good idea to split them, but there could be daily binary releases in addition to source code snapshots. As I know packaging is automated so it could be possible to release binaries as well. Of course they were unstable just like daily source code but I'm sure that there are people who need this. Yes, that'd be possible (I meant to do that when I started the packaging stuff, it's in Wade's hands now). I'd point out that splitting up mono would make this much easier: everything except the core part is OS/Distro/Arch independent. In fact we could just release *tarballs* of the .dll files and have a script to install the dlls into the gac correctly, or something. This would actually make it easier for people who want to hack on/test a patch on some part of mono to do if they run from rpms. For example, if I want to write a patch for System.Web, I can install mono-core from rpms, and then check out the web portion from svn, build and install it. (in theory I guess you might be able to get away with this today, but right now it's an advanced hack, once we split it could be the norm). Anyways, there are clearly many advantages of the split, what is probably more helpful in this thread is: * Cons to splitting * Some thinking about logistics (eg, do we have a unified release of all the parts of mono (mono poly ;-) every N months, or are the components completely disjoint release cycles) One thing that jonp and I mentioned briefly on irc today under the cons category: support. With a Chinese menu style of release (pick one from column a, one from column b...) we will get more configurations to test and may start seeing weird interactions between versions. One way to handle this sanely this would be to have a clear list of 1-3 acceptable combinations. This would fit in with the concept of a release of the complete mono stack: mono 2.0 would be when we put the new runtime, and all class libs in the stable configuration. Miguel has suggested a split along functional lines: this part does gui, that part does databases, etc. This seems to have alot of logical appeal, and it is the easiest for a user to understand. However, the goal is to allow us to update a component that is moving rapidly while isolating the core components from potentially destabilizing changes. For example Atlas would surely be part of a web component, but clearly there are different stability requirements for Atlas and System.Web. It might also be nice to be able to update the 2.0 packages without affecting 1.0 packages (however, this would be hard unless the stable 2.0 mscorlib is very good, as we can't just push in a new corlib). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] To split or not to split Mono?
On Thu, 2005-11-03 at 21:10 -0500, Jonathan Pryor wrote: As for the build system, it would be nice if we could have a mono-build module that was inserted into every checkout into a `build' directory as if through CVS' ampersand modules. This would allow a manner of consistency across all modules without needing to manually update each copy individually, resulting in incompatibilities. svn has a similar mechanism via the svn:externals property; see: http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-3 I'm not sure how well svn:externals works in practice though. In particular the feature that svn:externals refers to a URL is rather annoying, as it means we'd have to use a URL that anonymous users can access, implying that we could only update the build system by updating the mono-build module (and not via any of the existing checkouts). It also undermines the ability to have multiple anonymous svn repositories. It's something to consider anyway. The primary problem with this is the fact that its a url, you lose a bit of stuff by doing it (like the ability to easily make atomic commits without referencing the real build directory). I'd suggest we do: / build mono-core mono-data Most people will check out /, which will give them a fully buildable directory (in fact, there could be a master makefile in here or something). If somebody really wants to save on disk space, they can check out build and mono-core in a directory (much like one checks out mono and mcs). A few comments about the directory layout you choose: - mono-winforms (GUI support) - assembly - System.Drawing - System.Windows.Forms (from mcs/class/Managed.Windows.Forms) - libgdiplus (instead of a separate module, since these are tied) Other modules depend on s.drawing, it would either need to be moved into mono-core or its own module. Also, SWF only needs to be build once while libgdiplus needs to be build once per arch: since swf is more rapily changing its a plus to have it in a xplatform module. - mono-mscompat (non-core Microsoft-compatibility assemblies) - assembly - System.Transactions - Microsoft.* (Build, VisualBasic, Web.Atlas, etc.) - tools - xbuild I think the plan gets a bit icky around here. Consider when we get to a point where we support the vb compiler. Clearly, we will want to apply the same policy we do to mcs: keep it stable. In effect, we will want to have the default configuration pull a more stable branch of vb. At the same time Atlas might be alive and jumping, we'll want to give people new versions every month with lots of changes. So we'll have to pull vb out or something. The point is, in many ways we are looking at two kinds of splits: 1) splits across logical lines 2) splits across maintenance policy lines. We need to come up with a way that developers can see split 2 and users see split 1. I'd note that the split you are coming up with looks suspiciously like our rpm split. The rpm splits already cover the logical splits the way our users see them. In some ways, I'd like to leave the rpm split alone (this has been debated since prehistoric times, the current setup is the 3rd or so iteration) and only change the way we build mono. All we'd need is some sort of control file that says for the stable build, get mono, mcs from branches/stable, and winforms from trunk or something. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Colletions.Generic.SortedList
This is looking pretty good: * Since the enumerator is private, can you use a `yield' based one? that will be cleaner. * The indentation is a bit funkey, please use tags * When you do int pos = Array.IndexOf(this.sortedKeys, key); for Contains, etc, you should use binary search, as it will be faster * It's cleaner to do if (blah) throw Exception; ... rather than if (!blah) ...; else throw Exception (); * IDictionary.Remove argument checking is incorrect * Needs test cases * (does msft use some sort of tree structure here? -- this is only an initial impl, so it's not really necessary to be fully optimal). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Fold a + 'b' + c to a + b + c in mcs
On Tue, 2005-10-11 at 07:59 +0100, Marek Safar wrote: Hello Ben, Today I noticed a perf issue in corlib in a place where we did a + 'b' + c. The constant char in this case needs to be boxed and a string allocated for its value. A better way to write this is a + b + c, which saves two allocations. Good idea, so why not extend this to all other constant cases like. a + 1 + c etc. ToString there is culture dependent, for char it is not. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling System.Web with CSC
On Tue, 2005-10-11 at 19:34 +0200, Eyal Alaluf wrote: Hi, all. We prefer the solution where mcs is generating pdb files. This solution is well aligned with our strategy for the long term. In case the mcs/pdb project is not so simple and easy to implement soon, we need to examine the shorter term solutions. Checking the approach of using .Net 2.0 compiler, I took a less hacky approach where I analyzed the assembly created by .Net 2.0 compiler (using ildasm) and added to our binary compiler the few new .Net 2.0 opcodes that were used. I will still need to see how to read the PDB files of MS .Net 2.0, but this should be feasible. How are you guys handling generics in Array? In 2.0, array has methods like: public static int IndexOfT (T [] array, T value) Method overloading will redirect calls that before were non-generic to generic calls in 2.0. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Can't find older binaries
On Sun, 2005-10-09 at 14:11 -0400, Joshua Tauberer wrote: Can someone point me to the location of RPMs for 1.1.8? http://go-mono.com/download/x86/mono-1.1/1.1.8.2/ibm-data-db2-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-basic-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-complete-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-core-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-data-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-data-oracle-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-data-postgresql-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-data-sqlite-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-data-sybase-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-devel-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-extras-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-jscript-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-locale-extras-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-nunit-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-web-1.1.8.2-0.novell.i586.rpm http://go-mono.com/download/x86/mono-1.1/1.1.8.2/mono-winforms-1.1.8.2-0.novell.i586.rpm -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monop patch to filter obsolete output
On Mon, 2005-10-10 at 21:14 -0400, John Luke wrote: Hey, Here is a patch to filter [Obsolete] things from being printed by monop. Its useful when there are lots of deprecated things in an API. I guess another way to go would be to print [Obsolete] for these things but I would rather just not see them. Please commit, thanks. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monop path to print referenced assemblies
On Mon, 2005-10-10 at 21:29 -0400, John Luke wrote: Hey, Another small patch to print the referenced assemblies with monop. Commit please -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Fold a + 'b' + c to a + b + c in mcs
Today I noticed a perf issue in corlib in a place where we did a + 'b' +
c. The constant char in this case needs to be boxed and a string
allocated for its value. A better way to write this is a + b + c,
which saves two allocations.
The attached patch does this at the mcs level. The pattern occurs a few
times in the mono classlibs, so this appears to be generally useful.
-- Ben
Index: expression.cs
===
--- expression.cs (revision 51070)
+++ expression.cs (working copy)
@@ -3343,6 +3343,10 @@
public void Append (EmitContext ec, Expression operand)
{
+ // Change a + 'b' + c to a + b + c
+ if (operand is CharConstant)
+operand = new StringConstant (((CharConstant) operand).GetValue ().ToString (),operand.Location);
+
//
// Constant folding
//
@@ -3373,6 +3377,13 @@
public override void Emit (EmitContext ec)
{
MethodInfo concat_method = null;
+
+ // happens when you have a + 'b'
+ if (operands.Count == 1) {
+((Expression) operands [0]).Emit (ec);
+return;
+ }
+
//
// Do conversion to arguments; check for strings only
@@ -3405,12 +3416,7 @@
//
switch (operands.Count) {
case 1:
-//
-// This should not be possible, because simple constant folding
-// is taken care of in the Binary code.
-//
-throw new Exception (how did you get here?);
-
+throw new Exception (How did you get here?);
case 2:
concat_method = is_strings_only ?
TypeManager.string_concat_string_string :
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-docs-list] Re: msdn-browser/monodoc intergration
On Thu, 2005-09-29 at 22:32 -0400, Miguel de Icaza wrote: Hello, IMHO, this is a silly argument. First, we should not give our users stubs for documentation because they might fill in the stubs. Second, if a user is inspired to fill in the stubs, the first thing he is going to need to do is to find the msdn docs for the same method so that he can get some idea of what it does. So why not make this process easier, by providing them a usable interface (IE, a treeview that doesn't suck in firefox)? We are giving them stubs, because stubs are better than nothing, at least you get an idea of what is available, the types of the arguments and the return values. Sure, it would be best to have full documentation, but this is not bad. Its a graphical monop, which as Visual Studio has shown, it is useful to have *anyways*. Of course; I've never disputed this. Now, if we can go from there to contributions, that is even better. Given the historic rate of contributed docs (especially non-gtk# docs), that seems like a pretty big if. What reason do we have to expect that there will be a large change from the status quo in this area? We as a project need to produce a full stack of open documentation, and our tools reflect this need and that is why we have a Wiki-like setup. Yes, we do. Your tool is already available, feel free to improve it, but it is merely an improved online browser, it is not an offline browser and it Sure, if we added it to monodoc we'd need to make sure it behaved cleanly with no network connection. NetworkManager :-) is not encouraging our community to use the Wiki feature to create real open documentation. I don't see that this needs to be the case. What if we injected the text this method is only subbed out in Mono's documentation. Help us out! in msdn pages. The fact that we don't get alot of contributions suggests one of two things: 1) we don't have many users because they don't find the stubs useful compared to google. In this case, maybe my browser can keep people in the monodoc gui, encouraging them to use the wiki features 2) people are generally too lazy to contribute docs. I don't think my browser affects this group in any way. They aren't going to contribute docs. Period. As for convenience, its hard to beat Google for finding an API *anyways*, so people will resort to the Web anyways. I'd love to see web searching added. I don't know if you noticed this, but the .net sdk doc viewer in 2.0 does web searching. It looks in community forums, sites like http://asp.net and on msdn, and combines the results. Maybe we could use the google api and show results. If they were on msdn.m.c we go to my doc browser. To me, monodoc is the ideal place to put an msdn viewer. I do not want to detract from the monodoc audience by pulling them to a different GUI where there is no incentive to wiki what they find out from msdn. Anyways, if this doesn't convince you that having msdn docs as an additional form of documentation in monodoc is a Good Thing or at least an OK Thing, I guess there's no use in debating this any more. But my feeling is that worst case, the msdn browser will not affect the frequency of wiki-style contributions and best case it will increase them because people will choose monodoc over google. -- Ben ___ Mono-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
[Mono-docs-list] Re: msdn-browser/monodoc intergration
On Sat, 2005-09-24 at 11:25 +0200, Mario Sopena wrote: 2005/9/24, Ben Maurer [EMAIL PROTECTED]: get some idea of what it does. So why not make this process easier, by providing them a usable interface (IE, a treeview that doesn't suck in firefox)? The reason are what Joshua already said. If the user has a great doc (msdn) at hand, they will just move to look there and not to use mono docs, because what they care is having a good doc and not where that doc come from (well, most part of the users). But that is just my opinion. If the user is not willing to deal with the fact that our classlib docs has mostly stubs, they are going to end up using another documentation browser. For example, I usually use terminal server to a Windows computer to look up docs because I can use the .net doc browser. Now, lets say we integrate an msdn viewer. This will make it easy to get to the good docs. Thus, we will increase the use of monodoc. This has a huge side benefit: since people are inside monodoc, they can easily write docs for stubbed methods. We could even play on this fact; we could put a message on top of the msdn page for each member we have stubs Mono's free documentation only has stubs for this method. Help us out by writing docs. We'd have to be careful not to encourge plagiarism with this, but I think it could help us rather than hurt us. I'd also like to remind you that most monodoc users (I'd guess upwards of 90%) do not contribute to the documentation, and there is almost nothing we can do to get them to do so (except maybe a bribe^Wcontest). not including a way to get to the msdn docs is just making their life harder, with no benefit to us. -- Ben ___ Mono-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
[Mono-docs-list] Re: msdn-browser/monodoc intergration
On Mon, 2005-09-19 at 16:53 +0200, Mario Sopena wrote: 2005/9/16, Rafael Ferreira [EMAIL PROTECTED]: yeah I see your point of view. But not having the documentation there can also just lead to the user popping a browser and going to msdn anyways, and by doing that he/she cannot add value to monodoc. Keeping the user inside monodoc increases the chance of contributions. In any I'm not sure that is the case. I'm also more from the opinion of Joshua, as I told to BenM on IRC. I do think the documentation in mono is getting better but slowly, so we have to find ways to encourage people to write docs, and that addition to monodoc will send an ambiguous message to contributors IMHO, this is a silly argument. First, we should not give our users stubs for documentation because they might fill in the stubs. Second, if a user is inspired to fill in the stubs, the first thing he is going to need to do is to find the msdn docs for the same method so that he can get some idea of what it does. So why not make this process easier, by providing them a usable interface (IE, a treeview that doesn't suck in firefox)? Realistically, it is going to take us a long time to have docs that we can really call a replacement for the msdn docs. Also, msdn has other valuable content (for example, the articles, win32 api docs which can come in handy for the IO layer, etc) besides the api docs. BTW, the msdn doc utility is incomplete, as you cannot click on the links (and it won't be easy to fix); Shouldn't be all that hard. All I need to do is intercept the link click from gecko, load it, and sync the toc, all of which are actually pretty easy (there is data in the html pages for toc syncing). so it needs a lot of work before being added. IMHO, this tool is useful today even without any more features. It is 10x faster for me to use my tool than it is to use firefox. Also, it is made with gtk#2 and we use gtk#1 in monodoc. Miguel has talked about bumping monodoc up to depend on gtk#2. Once we do this, I'd love to see the primary tree be moved to the new api. But for now, I could live with another tab. -- Ben ___ Mono-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
Re: [Mono-dev] patch to monop to catch exception on Process.Start
On Wed, 2005-09-21 at 19:24 -0400, John Luke wrote: A little patch to catch an exception if gacutil cannot be found. Why would that happen? (btw, at least on mono, shouldn't we explicitly look in `dirname MSCORLIB_LOCATION`/gacutil.exe, so that it works even if we are using a mono that's not in the $PATH. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch to monop to catch exception on Process.Start
On Wed, 2005-09-21 at 19:41 -0400, John Luke wrote: Ben Maurer wrote: On Wed, 2005-09-21 at 19:24 -0400, John Luke wrote: A little patch to catch an exception if gacutil cannot be found. Why would that happen? (btw, at least on mono, shouldn't we explicitly look in `dirname MSCORLIB_LOCATION`/gacutil.exe, so that it works even if we are using a mono that's not in the $PATH. This was on windows/.net runtime, where gacutil is not in the path by default (at least it seems so). And it goes on to display an annoying message box. Why it would happen is sort of irrelevant here as anytime you do a Process.Start I think it needs to be in a try catch for various reasons. I'll leave that other part to you. Sounds reasonable, check it in. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] monolite
On Tue, 2005-09-20 at 11:58 +0100, Paul F. Johnson wrote: Roughly what time (GMT) is the monolite-latest package generated? I'm going to see about adding something to my website about it to avoid the usual make get-monolite-latest gives version x and the source won't compile because it has version y question (which has caught me today!) Honestly, the best bet is for people to install version N-1 of mono-core from rpms and then use that to bootstrap. It is the most reliable system to avoid the issue. All of our build machines use rpms to bootstrap rather than monolites. The monolites production isn't quite as reliable as it could be, which is part of the problem. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] monolite
On Wed, 2005-09-21 at 00:43 +0200, Jordi Mas wrote: From my experience: changes in the class library and mcs sometimes prevent you from working this this setup. Specially, if there is a big gap between N-1 and N. Our rpm build system, and build bot, all build version 1.1.x off of 1.1.x-1. For the 1.1 series, I've never seen this fail. If it does fail, that means that somebody didn't do the BOOTSTRAP_OLD or whatever that var is called thing correctly. Note that you might not be able to compile the entire class lib with the old mcs. However, the part of the bootstrap process which uses the old mcs *must* pass with the latest released version. If you have the latest mono-core rpm installed, and a fresh svn checkout won't bootstrap, it is a bug which will eventually show up in buildbot or the rpm system. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] monolite
On Wed, 2005-09-21 at 00:03 +0100, Paul wrote: Hi, Roughly what time (GMT) is the monolite-latest package generated? I'm going to see about adding something to my website about it to avoid the usual make get-monolite-latest gives version x and the source won't compile because it has version y question (which has caught me today!) Honestly, the best bet is for people to install version N-1 of mono-core from rpms and then use that to bootstrap. It is the most reliable system to avoid the issue. That's the way I usually do it. This time, I thought I'd try it as if I was a user who needed to install from source (say they use Mandriva or [goodness forbid!] Linspire) for whom there is no rpm available to install from. They can always build an older tarball first (which has a monolite built in) and then use that to bootstrap. I realize that is a somewhat longish procedure. However, given that 99.9% of our users are on Debian, Ubuntu, RHEL/Fedora or SUSE/NLD/SLES, all of which have packages built either in the distro or by us, it seems much more rational to tailor your instructions to that audience. One could also use the bitrock installer as a seed for the bootstrap. The monolites production isn't quite as reliable as it could be, which is part of the problem. What's the problem with it? Well, the first problem is that it is non-deterministic. It is quite easy to get complicated error messages if you get the wrong monolite at the wrong time. In general, we try to bump the version number to keep the error message friendly, but that hasn't always been the case. The more important problem is that they are not generated every day, so if you depend on monolite for getting mono working you may find yourself hindered. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Building Mono RPMs for Fedora Core 4 x86-64
Hi, For the benefit of x86-64 early adopters on Fedora Core 4, I wish to start building Mono RPMs for the x86-64 platform and offering them publicly. Is it possible to get the SRPMs used to build the x86 RPMs for Fedora to simplify my work? Who's responsible for creating those RPMs anyway? The mono rpms will work fine from any x86-64 distro. We only build one set of rpms per arch anyways. Hopefully we can offer fc4 rpms (on x86 and -64) at some point in the near future. Wade is responsible for that. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Fixes for Grasshopper compilation
On Thu, 2005-09-08 at 16:27 +0300, Eyal Alaluf wrote: Hi, all. Attached are fixes to WebCategoryAttribute.cs WebSysDescriptionAttribute.cs that mark them as [AttributeUsage(AttributeTargets.All)]. The MS C# compiler refused to compile System.Web otherwise (from within Grasshopper). The fix seems innocent enough, though. Any comments? Is this an mcs bug? If so, can you file it? -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Remove UnmanagedType_80
On Mon, 2005-09-05 at 20:01 +0200, Kornél Pál wrote: Hi, Using (UnmanagedType) 80 was required because there was a bug in mcs; it used I4 as the default ArraySubType instead of 80. This bug was fixed so we no more require Consts.UnmanagedType_80. Is it OK to commit the patch? How new of a mcs do you need to compile? Many people (buildbot and the rpm build machines being one example) always compile mono by using an rpm install of mono-core for 1.1.n-1. For example, right now, the buildbot/rpm build machines have mono 1.1.8.3 installed. After we release 1.1.9, we will rug up to that version. This means that mono from svn must be buildable with a mono-core install from the latest released version. Our build setup would get alot more tricky if we need to depend on getting monolites in the build system, so I don't think we would want to break this policy. Btw, there are a few other hacks like this that could potentially be removed under the BOOTSTRAP_WITH_OLDLIB name. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Collections.Generic.{Stack, Queue} API updates
On Sun, 2005-09-04 at 16:00 -0600, David Waite wrote:
+ [Serializable, StructLayout(LayoutKind.Sequential)]
public struct Enumerator : IEnumerator T,
IEnumerator, IDisposable {
The StructLayout change is very interesting. The only reason I could see
for them to do that would be to allow the optimization of enumerators
inside the JIT. It'd be interesting to look at a debugger and see what
kind of bytecode they are emitting for the foreach pattern.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Fresh install
On Mon, 2005-08-29 at 12:24 +0100, peter wrote: Ben Maurer wrote: Uhm, what issues have you found with your packages? I know that we aren't able to support gtk# on a distro the day it comes out. But for mono itself our packages should work flawlessly. OTOH, compiling takes a bit of time and is error prone. It's some time since I last tried anything with rug, so I've forgotten a lot of the commands, but here's a taste of what I get: [EMAIL PROTECTED]:~ rug channels subd? | Alias| Name --+--+--- Yes | gtk-sharp-official | Gtk# 1.0.x Yes | gtk-sharp-2-official | Gtk# 2 Yes | mono-1.1-official| Mono 1.1.x Yes | mono-tools-official | Tools for mono [EMAIL PROTECTED]:~ rug update ERROR: Unresolved dependencies: Upgrading gtk-sharp-gapi-1.0.8-3 = gtk-sharp-gapi-1.0.10-0.suse93.novell[Gtk# 1.0.x] There are no installable providers of (any)perl-XML-LibXML-Common[[Any]] for gtk-sharp-gapi-1.0.10-0.suse93.novell[Gtk# 1.0.x] There are no installable providers of (any)perl-XML-LibXML[[Any]] for gtk-sharp-gapi-1.0.10-0.suse93.novell[Gtk# 1.0.x] gtk-sharp-gapi-1.0.10-0.suse93.novell is scheduled to be installed, but this is not possible because of dependency problems. Marking this resolution attempt as invalid. [EMAIL PROTECTED]:~ 1) you don't need the gapi stuff. Don't bother with it. 2) those deps are in suse. YOu need to find a suse mirror. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Patch for compiling System.Web/HttpResponseStream.cs under TARGET_JVM
On Mon, 2005-08-29 at 13:00 +0300, Eyal Alaluf wrote: +#else wr.SendResponseFromMemory ((IntPtr) start, len); +#endif This looks wrong. IntPtr is now an offset from the beginning of the chunk, right? Did you test this on the standard version? -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for compiling System.Web/HttpResponseStream.cs under TARGET_JVM
On Tue, 2005-08-30 at 18:29 +0300, Eyal Alaluf wrote: You are correct. It forced me to make the ByteBucket class unsafe for Mono config, but I hope that difference won't matter in the future. Why not add a method in chunk to send the chunk? Also, please fully test the standard config before committing. It should go without saying that any patch which is not fully inside #if TARGET_JVM should be tested on the standard config -- and especially so if the patch has parts in #if !TARGET_JVM. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Fresh install
On Mon, 2005-08-29 at 15:38 +0100, peter wrote: linux:/home/peter # mono --version Mono JIT compiler version 1.1.8.3, (C) 2002-2005 Novell, Inc and Contributors. www.mono-project.com TLS: normal GC:Included Boehm (with typed GC) SIGSEGV : normal Globalization: normal linux:/home/peter # So have I just lost one package (mono-data-sqlite?) or did I lose some more as well? Without going through each package in detail, it seems that there were 20 to install, but only 13 made it. What do I have to do to recover? I'll try the other channels and post any interesting results. But thanks for spurring me on to have another go. I don't really want to overwrite my system if I can help it. No idea, I've never seen that before. Maybe try removing all mono related packages than installing them all from ours. There are some minor differences in packaging between 9.3 and ours. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Fresh install
On Sun, 2005-08-28 at 23:04 +0100, Paul F. Johnson wrote: For instance, should I install mono from the SuSE installation disks, or should I not do that but rather install mono via red carpet or something? From source. I would *always* recommend from source unless the person does not feel technically up to the task in which case, Uhm, what issues have you found with your packages? I know that we aren't able to support gtk# on a distro the day it comes out. But for mono itself our packages should work flawlessly. OTOH, compiling takes a bit of time and is error prone. red carpet has the most up to date versions (usually) Red Carpet will *always* have the same version as the downloads page has. We were bad about this before the spring when I revamped our build system. It should always be up to date now. Wade and myself have gone to great lengths to make the build system create packages that are easy to use and easy to find. If there is an issue with any of them, please tell us. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [PATCH] Building java profile
On Wed, 2005-08-24 at 09:12 -0700, Ynon Koralek wrote: Hello, This patch enables building (a part of) the framework in the java profile (called net_1_1_java). The java profile is using the standard .sources file. If there is a .net_1_1_java.sources file, it's used instead. For now, it works only on cygwin. If somebody adds a file to the default profile, it should *also* go to java; otherwise, we will end up breaking the build because we don't build the java profile before checkin. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] mkbundle and crosscompiling
On Tue, 2005-08-23 at 10:08 +0200, Matthijs ter Woord wrote: Is it possible to use mkbundle on a 2.6 kernel distro and compile an executable which can run on a 2.4 kernel + glib combination? Compiling something on the glibc post-rh9 and running it pre-rh9 is risky. The version numbers for some functions changed. For example, we know that rh9-built mono packages will *not* run on sles8. I don't think there is any way around this. You *can* build on 2.4 kernels and run on 2.6. (btw, I assume you meant glibc not glib. glib may also have problems. Some of the newer versions use macros to call functions that are only added in newer versions) The safest path is to compile with the *oldest* distro you have and test on *every* distro. This was the only way we felt safe building mono on only one platform. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] cannot create regular file `/.../vbnet.lang': Permission [correctly] denied
On Mon, 2005-08-22 at 06:32 -0400, Steven T. Hatton wrote: /usr/bin/install: cannot create regular file `/opt/gnome/share/gtksourceview-1.0/language-specs/vbnet.lang': Permission denied make[2]: *** [install-extra_langDATA] Error 1 make[2]: Leaving directory `/download/org/go-mono/gtksourceview-sharp' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/download/org/go-mono/gtksourceview-sharp' make: *** [install-recursive] Error 1 IMHO, we should not install these files. Any modern gtksourceview-sharp package will have them (post GNOME 2.6 maybe, though I think nld has a patch). Or maybe we should not make this issue cause the build to fail. Luckily, the newer gtksourceview packages are going to use XDG_DATA_DIRS or something similar so that we don't have to deal with this issue. Sadly though, that is for the GNOME 2.12 timeframe. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] AssemblyName ctor
Hey,
The patch attached implements the new AssemblyName ctor without using
internal calls. Could anybody review it?
+int GetCharNumericValue (char c)
+{
+if (c = (char)0x30 c = (char)0x3B)
+return c - 0x30; // 0-9
+if (c = (char)0x61 c = (char)0x66)
+return c - 0x57; // a-f
1) Why not use '0' rather than (char)0x30
2) What about uppercase hex?
+} catch {
+throw new FileLoadException (The
assembly name is invalid.);
+}
It might be helpful to say catch (Exception e) { throw FileLoadException
(..., e) }, so that the developer gets a possibly helpful message.
+for (int i = 0; i parts.Length; i++) {
foreach (string s in parts);
+ if (String.Compare (parts [i], 0, Version=, 0, 8, true,
CultureInfo.InvariantCulture) == 0)
+version = new Version
(parts [i].Substring (8, parts [i].Length - 8));
If Version= (or any other thing) occurs twice, what happens?
NUnit tests?
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Source list per profile
Alot of us like to do: echo System/MyNewClass.cs blah.sources and sort blah.sources | uniq x; mv x blah.sources which breaks with the xml version... -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] USE_MMAP speed/time tradeoff
On Sat, 2005-08-06 at 23:26 +0200, Michal Moskal wrote: Hello, I noticed slowdown in Nemerle compiler with: 2005-06-20 Gonzalo Paniagua Javier [EMAIL PROTECTED] * configure.in: enabled the use of mmap/munmap for solaris and linux. It seems to help with memory usage. With this patch the compiler is about 10% slower, but uses around 10% less memory. This is all on amd64 box, running 64 bit version of mono. The Nemerle compiler is quite allocation intensive. The working set is about 140M and the running time is about 23s. I wonder if: a) we can introduce --with-mmap configure switch? b) better yet, make the mmap version go as fast as the brk one? Any differences in the oprofile output? Can you try on x86? 10% is a fairly large performance regression. Also, Gonzalo was trying to work on the large file upload setup, which has better solutions (buffering to files, like is done in Whidbey). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] USE_MMAP speed/time tradeoff
On Sun, 2005-08-07 at 00:14 +0200, Michal Moskal wrote: On 8/6/05, Ben Maurer [EMAIL PROTECTED] wrote: I noticed slowdown in Nemerle compiler with: Any differences in the oprofile output? Can you try on x86? The oprofile as well as --profile=default:stat shows that the difference lies in GC, precisely in GC_mark_from, other functions are generally the same. And the difference in GC_mark_from is like this 10%. I can try checking x86 later, but it will require some setup. Anyway the difference should be also seen in mcs bootstrap. Interesting. Maybe the amount of memory mmaped is too small and so you get more GCs? Also, Gonzalo was trying to work on the large file upload setup, which has better solutions (buffering to files, like is done in Whidbey). large file upload? I don't get it. mod_mono/xsp users who want to receive large files... -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] make targets to test mono's sanity?
On Fri, 2005-08-05 at 11:08 +0200, IT2003_1: Morenz, Tino wrote: Hi, as I try to get mono running on a QNX box I need to know whether the compilation is sane (I mean whether everthing works well). atm I use `make distcheck' but it's kind of annoying and time consuming that it always creates the tarball / compiles the system before it actually starts the tests. I've read something about `make test' in mono/tests. What is the difference to the tests run by `make distcheck'? Are there any other test or check targets for make? make check should run (most of) the check part of distcheck. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Check for assembly attributes
On Thu, 2005-08-04 at 00:07 -0500, Carlos Alberto Cortez wrote: This precludes us from using the assembly in mscorlib.dll. It could potentially be useful to use there -- say to let us write nunit tests that poked at internals. I'm not very sure about the scenarios you are thinking in. Could you please show some detailed examples? For example, I add an internal api to corlib called FooParser. I want to write nunit tests, so what I do is make the nunit assembly be able to see corlib's insides. See http://blogs.msdn.com/junfeng/archive/2004/09/14/229254.aspx about how there is support for handling commas in file names. Your code would break under this. Well, I didn't know about that, but IHMO I find it like a very bad practice, and I'm sure that there aren't people out there who like to call their assemblies 'My,Assembly,Version=xx... or something like that. Well, it was important enough to add the feature in msft Also, to test this, I tried to load an assembly named 'Test,Assembly' (using Assembly.Load ()) in both mono and ..NET, and neither could load it successfully. The only way to work with it AFAIK is when you get name of the assembly itself, or use Assembly.LoadFrom. It is a whidbey feature, as mentioned in the article. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Check for assembly attributes
On Thu, 2005-08-04 at 17:15 -0500, Carlos Alberto Cortez wrote: + if (String.CompareOrdinal (values [0], Version) == 0) + version = true; Weren't these case insensitive in your first version? If they are, then you can just use String.Equals, otherwise, i think this call is wrong -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Difference behaviour between Mono and .NET
On Thu, 2005-08-04 at 09:38 +0700, Ernas M. Jamil wrote:
I found there is difference behaviour between Mono and .NET on handling
dataset
that filled from joined query and does not have spesific primary key.
Here is my test case:
--
String connectionString = null;
MySqlConnection con;
try
{
connectionString =
Server=localhost; +
Database=mysql; +
User ID=user; +
Password=password;
con = new MySqlConnection(connectionString);
MySqlDataAdapter myadapter = new MySqlDataAdapter(SELECT t0.* FROM
user t0, db t1 WHERE t0.user = t1.user;,con);
con.Open ();
DataTable dt = new DataTable();
int count = myadapter.Fill(dt);
Console.WriteLine(here count {0},count);
Console.WriteLine(here count {0},dt.Rows.Count);
con.Close();
}
catch (Exception e)
{
Console.WriteLine(exception {0},e);
}
--
On Mono, I got output from test program:
here count 11
here count 6
But on .NET both lines has same number.
Anyone has idea what wrong with that, or I should filed that as bug ?
Sounds like a bug. Could you file it on bugzilla? What would be really
helpful is if you could reproduce it without a database connection. If
you are unable to do that, however, you should provide easy to follow
instructions on how to set up your database.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Check for assembly attributes
On Wed, 2005-08-03 at 20:55 -0500, Carlos Alberto Cortez wrote:
Hey,
A patch is attached, containing a check for InternalsVisibleToAttribute,
when it is applied to an assembly. It reports a warning or shows an
error, just like csc does.
+ if (t.Equals (typeof
(System.Runtime.CompilerServices.InternalsVisibleToAttribute))) {
This precludes us from using the assembly in mscorlib.dll. It could
potentially be useful to use there -- say to let us write nunit tests
that poked at internals.
See http://blogs.msdn.com/junfeng/archive/2004/09/14/229254.aspx about
how there is support for handling commas in file names. Your code would
break under this.
Finally, comparisons should be done with the invariant culture.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] More tests and fixes for them
On Mon, 2005-08-01 at 02:43 -0700, Andrew Skiba wrote: Please review the attached tests and fixes for them. I know the fixes look weird, but that's what dot net appear to do in their sys.drawing. PointF.ToString returns string with space, while Point.ToString returns without space. And the hash code for PointF seem to ignore the y value. GetHashCode does not need to be the same for different impls of the framework. For example, char has a different gethashcode for microsoft and mono. The only thing that we should test in GetHashCode is that x == y implies hash(x) == hash (y). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] RE: [Gc] [PATCH] Race condition when restarting threads
On Mon, 2005-08-01 at 15:09 -0700, Boehm, Hans wrote: I don't quite understand the problem here. If GC_stop_count has just been incremented, then I'm about to send another suspend signal to the thread, and it will have to stop again before we think the world is stopped. My situation is: 1) the thread suspending other threads has done both GC_stop_count ++ and GC_world_is_stopped = TRUE 2) A suspended thread wakes up from sigsuspend (on a random signal) 3) By the time it wakes up, the GC_stop_count has taken effect (as seen by this thread), but GC_world_is_stopped has not 4) The thread thus thinks that the world is being started up again and continues. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] RE: [Gc] [PATCH] Race condition when restarting threads
On Mon, 2005-08-01 at 16:41 -0700, Boehm, Hans wrote: My assumption is that if thread A sends a signal to thread B, then Bs handler sees all memory operations performed by A before the signal was sent. I don't think that's officially guaranteed, but I would be amazed if it weren't true everywhere. Ah, yeah, that probably fixes things. Anyways, not sure what I want to do in the Mono tree for this. We should probably swap out my version of the patch (the one that does context switches). Having a membar feels alot cleaner. Would you mind putting up a pre-7.0a4 for me, so I can see if backporting the patch there and whatever __asm__ is needed for all the platforms. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [Patch] Publisher Policy support
On Sat, 2005-07-30 at 11:53 -0400, Miguel de Icaza wrote: Could you assist Carlos in making this patch work? Yeah, sure. I think he needs to just find a more suitable lock. I think the loader lock would work. I'm not sure why the assembly loading stuff is per-domain anyways. This is a good use for my lock debugger, which is sadly on the hard drive of my laptop which is now getting kernel panics at boot up due to reiser complaining about bad blocks ;-(. Anyways, Carlos, if you have any questions, please ask on irc. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Npgsql assembly versioning
Hey guys, I noticed something the other day. We number our version of Npgsql as 1.0.5000.0 (ie, the same as the version of the .net fx) and build one for the 1.1 and 2.0 profile. However, on Windows, Npgsql is numbered 0.7 and only one version ever gets installed. So, it is impossible to deploy the same binary on Windows and Linux without copying over a private Npgsql in one of the cases (or using some .config file magic on windows). IMHO, we should keep the assembly version of Npgsql the same as it is upstream. If we feel it is necessary, we could use a publisher policy to redirect old versions of Npgsql to the upstream version. I'm not sure how we should handle the 2.0 profile. If we only compile npgsql once, that means we can't put it in lib/mono/1.0, correct? That means that people who expected -r:Npgsql.dll to work will get a suprise. Thoughts? -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 09:32 +0200, Andreas Nahr wrote:
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 1:15 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:42 +0200, Andreas Nahr wrote:
Yes - it would make a lot of sense to put them into a single file.
However
it would come at a cost of up to 2kb of size added to EACH assembly that
uses Consts.
Maybe the *FILE* will be 2 kb, but the metadata added probably won't be.
To add a class with a single const we'd need to add:
If we merge everything into a single file we probably have about 20 consts,
each about 50 chars long.
Depending whether this is saved in the assembly as unicode or ascii (which i
don't know) this should be 1-2kb just for the strings in the string heap.
stuff on the ldstr table is in unicode. That assumes that the 20 consts
never get used, however. If they are used in the code at all, they will
need to be in the ldstr table.
All the fields are NEVER used at runtime, so I hope they do not get loaded
at all ;)
There is no access to these fields. They are only used at compile time, but
not at runtime.
They don't.
In fact I think we could do something really clever to our compiler here,
that would also benefit for a lot of other cases.
AFAIK the compiler can already eliminate dead code. I would propose a
step
that allows the compiler to scan for dead code again AFTER constants are
resolved. This way the compiler would be able to completely eliminate the
Consts Class after compiling. This would also add lots of added value to
other applications. It's quite common to use private consts and
especially
enums to structure the code and make it more readable. With the proposed
compiler function all of these things could be thrown out at
compile-time,
which could help a lot of applications to get smaller.
A cecil based il-to-il optimizer could do that in the future. Of course,
if you really want to look at how can we make teh metadata smaller we
could do a simple obfuscator -- we could rename private / internal
methods/classes to have small names, etc.
There are obfuscators out there that you can use, however that is not
exactly what I mean:
Look at the example:
const string a = Hello ;
const string b = World;
[SomeStringAttribute (a+b)]
private void Out () { }
If I understand thing right we end up having the following strings in the
assembly:
Hello World (as part of the attribute)
Hello , World (in our case these use their own class)
However after compilation the strings Hello and World are never used
anywhere at runtime, so we could delete them.
AFAIK not even the MS compiler is able to do that ;)
That's correct.
Anyways, as I said to Kornel, Feel free to come back with data about
what effect the optimization will have. Otherwise, let's just spend time
on real performance issues with measurable results.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 18:10 +0200, Andreas Nahr wrote: And as you said it will be near to impossible to measure performance gains, because you would need to instrument the OS itself. From Kornel: Note that the things I said earlier in this thread and above are only a discussion about possible optimizations based on theoritical facts not on measurements. Please don't waste time with performance speculation. If you like speculation, try day trading. If we were to hack up the code every time a blind speculation was made, mono would be unmaintainable. 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). 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. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 19:21 +0200, Kornél Pál wrote: 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.) Yeah, for assembly versioning, as much as possible should be shared. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [Patch] Publisher Policy support
On Fri, 2005-07-29 at 22:31 -0400, Miguel de Icaza wrote: Hello Carlos, I'm attaching a patch which adds support for publisher policy files ( http://msdn.microsoft.com/library/default.asp?url=/library/en- us/cpguide/html/cpconcreatingpublisherpolicyfile.asp ), which allows to redirect one assembly version to another. The patch looks good to me. Does anyone have any objections to get this patch in? Locking wise, I am not so sure about this path. It adds a domain lock in the assembly loading code path. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:42 +0200, Andreas Nahr wrote: Yes - it would make a lot of sense to put them into a single file. However it would come at a cost of up to 2kb of size added to EACH assembly that uses Consts. Maybe the *FILE* will be 2 kb, but the metadata added probably won't be. To add a class with a single const we'd need to add: 1) a entry in the classes table 2) an entry in the fields table 3) a constant string in the strings heap. At runtime, the only datastructure that will ever be allocated due to this class is the hashtable that goes from Namespace/Class - class field. I'm not even sure if that gets created for private classes, I'd have to dig into the code. The fields and string heap data gets loaded lazily on the first access. In fact I think we could do something really clever to our compiler here, that would also benefit for a lot of other cases. AFAIK the compiler can already eliminate dead code. I would propose a step that allows the compiler to scan for dead code again AFTER constants are resolved. This way the compiler would be able to completely eliminate the Consts Class after compiling. This would also add lots of added value to other applications. It's quite common to use private consts and especially enums to structure the code and make it more readable. With the proposed compiler function all of these things could be thrown out at compile-time, which could help a lot of applications to get smaller. A cecil based il-to-il optimizer could do that in the future. Of course, if you really want to look at how can we make teh metadata smaller we could do a simple obfuscator -- we could rename private / internal methods/classes to have small names, etc. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:57 +0200, Kornél Pál wrote: BTW is there a way to have a common .sources file because it seems that we are going to have more and more common files that has to be added to the .sources file of each assembly? I think that's a bit excessive ;-). The goal is to make sure that we don't have N versions of something that is likely to change. Since the source file is unlikely to change, that seems a bit silly. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 01:31 +0200, Kornél Pál wrote: This patch is for System.Web.UI.WebControls. If you find any problems regarding the patch itself feel free to comment it but if you imagine any other non-blocking patches that should be done before committing this one I promise that I will propose no more pathes. Gonzalo, who was smart enough to rm -rf /usr/bin on his laptop ;-), says he approves this. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
On Wed, 2005-07-27 at 15:22 +0100, Mike Hearn wrote: * Autopackage supports dependency resolution. Some users on some distros don't have any easily accessible packages for the Mono runtime, or if they do they may not know where to get them. By packaging not only applications but also the runtime and the various Foo# bindings, this problem can be mitigated: distros that ship Mono out of the box don't change and the packages will use whatever is already installed. For users on distros that don't ship it, autopackage can depsolve the runtime onto the users system. We already have a for all distros installer (that uses bitrock). But it'd be really cool to see this use autopackage. I think the best way to start would be from the top down. It'd be nice to do a package of MonoDevelop and then see what can be made easier to do with helpers in autopackage, etc. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] unsigned package mono-jscript-1.1.8.2-0.novell.i586.rpm
On Wed, 2005-07-27 at 00:12 +0300, Anton Andreev wrote: yum install mono-complete ends with: unsigned package mono-jscript-1.1.8.2-0.novell.i586.rpm What should I do? fedora core 4, installing mono 1.1.8.1 We don't sign our packages. You need to tell yum to disable its signature check. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Building mono-tools
On Mon, 2005-07-25 at 22:03 +0100, Paul wrote: ./HtmlRender.cs(64) error CS1503: Argument 1: Cannot convert from `Gecko.WebControl' to `Gtk.Widget' ./HtmlRender.cs(64) error CS1501: No overload for method `Add' takes `1' arguments make[1]: *** [browser.exe] Error 1 make: *** [all-recursive] Error 1 You are using gecko# from svn which uses the gtk#2 stuff. Casts can't be done from v1 to v2. You need *exactly* 0.6 from tarballs. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Building mono-tools
On Mon, 2005-07-25 at 14:06 -0700, Rafael Ferreira wrote: You're are om the 2.0 version of gecko-sharp, you need version 1.0. Am somewhat confused as to why people are even able to get past the configure stage, seeing as we have: PKG_CHECK_MODULES(GECKO_SHARP, gecko-sharp = 0.6) Actually I was working on a patch to make monodoc work with gecko 2.0, does anyone think that it would be worth while? Monodoc uses gtk# 1.0 as of now. Moving to allow gecko# from head means we have to move to gtk# 2.0 Before, we had a mode where mono-tools would build with whatever version of gtk# was installed. However, this caused problems because: * As most of us are developers, we have the 2.0 stuff installed. That means that we compiled against 2.0. When it came time to release, I had to figure out what dependencies were added * It made the build system complicated (if gtk# 2.0 was installed on the jail, rpms would depend on 2.0) So, I reverted this mode and had mono-tools build with gtk# 1.0. You are going to need gtk# 1.0 on your computer anyways; I can't see a reason to bring back that patch. Now, a patch to turn this obscure error into something sensible at configure time would be great. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] FC3 x86_64 RPMs for mono
On Fri, 2005-07-22 at 17:16 +0530, Tarun R wrote: Hello, I want to make x86_64 FC3 RPMs for mono. If I could get the Spec files used to create the FC3 x86 RPMs, it would be very useful. For mono proper, just use any of the SUSE rpms. The rpms can get shared across distros. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-devel-list] The first (attempt to checkin) managed collation patch
On Fri, 2005-07-22 at 03:18 +0900, Atsushi Eno wrote: So, you mean, I should avoid managed resource but acquire those pointers from the runtime via icall, right? Managed resources are loaded as an IntPtrStream. Inside corlib, you can cast to that type and get the IntPtr (possibly adding a call to do that). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] The first (attempt to checkin) managed collation patch
On Fri, 2005-07-22 at 03:51 +0900, Atsushi Eno wrote: Hi, Ben Maurer wrote: On Fri, 2005-07-22 at 03:18 +0900, Atsushi Eno wrote: So, you mean, I should avoid managed resource but acquire those pointers from the runtime via icall, right? Managed resources are loaded as an IntPtrStream. Inside corlib, you can cast to that type and get the IntPtr (possibly adding a call to do that). Is that cast really kind of thing on that I can depend? Yes, sorta. We need to change this class to be called UnmanagedMemoryStream for 2.0 http://msdn2.microsoft.com/library/13e02eft.aspx. This will probably mean that we rename IntPtrStream and make it internal for 1.0. When that gets done, obviously the person will need to change your code. But, I think you can rely on the manifest resource thingy returning this special stream type. Maybe you should add an internal overload that returns the specialized type just to make things feel safer. Btw, an interesting blog on this subject: http://blogs.msdn.com/bclteam/archive/2004/10/18/244171.aspx -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] The first (attempt to checkin) managed collation patch
On Fri, 2005-07-22 at 12:53 +0900, Atsushi Eno wrote:
+ class UnmanagedMemoryStream : Stream {
unsafe byte *base_address;
- int size;
- int position;
+ long size;
+ long position;
It's a bit more efficient so store those as void*. It uses less memory
on x86 boxes. Also, the 32 bit opcodes are shorter (ie, in size += 1,
you can do that with a single inc rather than having to handle
overflow).
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] The first (attempt to checkin) managedcollation patch
On Thu, 2005-07-21 at 00:12 +0200, Kornél Pál wrote: From: Ben Maurer * There are extremely long runs of the same char in many instances * The file seems to have tons of 0 bytes. * There are some runs of sequences: 0002bfb0: 3c00 3d00 3e00 3f00 4000 4100 4200 4300 .=.[EMAIL PROTECTED] 0002bfc0: 4400 4500 4600 4700 4800 4900 4a00 4b00 D.E.F.G.H.I.J.K. 0002bfd0: 4c00 4d00 4e00 4f00 5000 5100 5200 5300 L.M.N.O.P.Q.R.S. 0002bfe0: 5400 5500 5600 5700 5800 5900 5a00 5b00 T.U.V.W.X.Y.Z.[. though they are somewhat smaller than the runs of the same char. I see the problem as the following: If the file contains unicode Unicode charaters it eats disk space but is fast to read thus sorting is fast. If it is compressed but unbuffered sorting is slow and eats CPU. If it's buffered either because it is compressed or just for fun it eats RAM. Compression does not mean `use bzip' in this context. It means change the file format so that we don't need long runs. Compression will quite possibly make things faster: * Reading from disk is SLOW. In the time it takes to access one extra page from the disk, we could have done *tons* of sorts. Please see http://rlove.org/talks/rml_guadec_2005.ppt, slide 3. * Cache misses are slow (but not as slow). So a few extra instructions may well be worth avoiding one. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] malloc and free on CLI
On Sat, 2005-07-16 at 12:36 -0700, Jeyasankar Kottalam wrote: Hello, I'm the student writing GCC-CIL for Mono as part of Google's Summer of Code. How should I implement malloc and free on CLI? I've come up with a couple of ideas, but none of them seem particularly good to me: - P/Invoke to native malloc and free Problem: The binary becomes tied to the details of the underlying platform to pull in a malloc from the appropriate library. Binary portability is lost. Not really. Dllmaps could map from a virtual libc library to the real libc. If you want to be especially clever and make the application run on the msft runtime, the library name should be whatever the ms C runtime is, since windows doesn't have dllmaps. We already do this in Gtk#. One binary can run on MSFT's runtime and the Linux runtime. Also, the data providers we have using p/invoke (eg, sqlite) work on windows, linux and mac. Correct, but I am also writing a partial libc for a couple of reasons: I'd like to be able to test real world applications, and it is also part of the acceptance criteria that I demonstrate a real world C application under Mono. Regardless of whether I write the final implementation, this is an issue that needs to be considered. Depending on the C libraries that the application depends on is likely acceptable when running a real world app. By mapping calls to external libraries to DllImport's we can do some interesting things. Imagine compiling evolution and having it run with mono. glib/gtk+ could still be native code to enhance performance. That being said, an issue to think about: the user might want to compile some of the libraries they depend on with the cil targeting gcc. For example, say you are trying to compile the `svn' binary with gcc-cil. You might also want to compile libsvn_* with gcc-cil, but not compile libaprutil and libxml2 with gcc-cil and just depend on the native C libraries. Yes, I agree. However, I still need a mechanism to implement a heap. Even if porting an existing libc, that libc will need *some* mechanism to get memory from the runtime. What is the recommended way of doing that? I think to get te better berformance you should implement heap functionality natively. But not using P/Invoke because it's inefficient. You should rater use InternalCalls. Use mono/mono/metadata/icall.c and [MethodImplAttribute (MethodImplOptions.InternalCall)]. This will result in a very good performance because there will be no marshaling. Note that however you should implement only necessary functionality in native code becasue it does not take advantage of JIT, optimizations and verifications. And you should not duplicate platform dependent or native code that can be implemented using managed code by calling Class Library functions. Looking forward (in the medium-long term), the way icalls work is going to need to change. For a precise GC to work, we'll need to know exactly which calls hold gc references. icalls will probably need code to interact with safepoints. So, it would seem that something like that is prone to break. Also, using icalls means that you must link with libmono.so, preventing an application from running on the msft runtime. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] RE: [Gc] [PATCH] Race condition when restarting threads
On Mon, 2005-07-11 at 14:15 -0700, Boehm, Hans wrote:
I've attached a different patch, which I think should solve the
problem without additional synchronization and context switches,
at least in the vast majority of cases. (It should solve the
problem in all cases. Additional context switches will be
needed only if the sigsuspend wakes up early, I claim.)
Please let me know if you have any problems with this, or if
this doesn't look right to you. I tested only superficially.
I'll try to test this as soon as I get a chance.
One question, which is probably a case of me not having any clue about
the code:
-do {
- me-stop_info.signal = 0;
- sigsuspend(suspend_handler_mask);/* Wait for signal */
-} while (me-stop_info.signal != SIG_THR_RESTART);
+/* We do not continue until we receive a SIG_THR_RESTART, */
+/* but we do not take that as authoritative. (We may be */
+/* accidentally restarted by one of the user signals we*/
+/* don't block.) After we receive the signal, we use a*/
+/* primitive and expensive mechanism to wait until it's*/
+/* really safe to proceed. Under normal circumstances,*/
+/* this code should not be executed. */
+sigsuspend(suspend_handler_mask);/* Wait for signal */
+while (GC_world_is_stopped GC_stop_count == my_stop_count) {
+GC_brief_async_signal_safe_sleep();
+# if DEBUG_THREADS
+ GC_err_printf0(Sleeping in signal handler);
+# endif
+}
Why can't you just say
do {
sigsuspend (suspend_handler_mask);
} while (GC_world_is_stopped GC_stop_count == my_stop_count);
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] RE: [Gc] [PATCH] Race condition when restarting threads
On Tue, 2005-07-12 at 11:13 -0700, Boehm, Hans wrote: I think I generally also prefer your solution. But it seems to me that it has a very low probability memory ordering issue. If I see GC_world_is_stopped set because I'm trying to stop the world for the next GC, but I still see the old value of GC_stop_count (due to compiler or hardware memory reordering), I think it deadlocks. My ugly version will just pause for 25msecs and then recover. I think I'll go with your version for GC7, where I have a cleaner way of enforcing the memory ordering, and keep my version for 6.6. (This assumes we find no other problems. This stuff is much too subtle.) Your patch had the fields set as volatile, so shouldn't the compiler ensure that the cpu does not reorder the stores? What if you only used one field for both the stop count and world is stopped field (setting the flag for stopped on the highest bit). The value is only modified in one thread at a time, so you don't have to CAS or anything. The cpu would be forbidden from reordering writes (they shouldn't reorder writes to the same field). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-patches] r47151 - in trunk/mono-tools: . docbrowser
Hey Mario,
Just a few comments. First, whenever you do a commit, you need to write
a change log. The ChangeLog file in any directory has the correct
format. If you use emacs, the easiest way to create a new entry is to do
C-x 4 a.
+PKG_CHECK_MODULES(GECKO_SHARP, gecko-sharp=0.6)
+AC_SUBST(GECKO_SHARP_LIBS)
+
This means that gecko# is *required*. I'm not sure if that's what Miguel
wants.
Added: trunk/mono-tools/docbrowser/HtmlRender.cs
Each class should probably have its own file. Not only does this make
things easier to fine, it means that you can make gecko conditional
without any #if tags.
I wonder if these classes/interfaces should be public.
+interface IHtmlRender {
+ // Jump to an anchor of the form a name=
+ void JumpToAnchor (string anchor_name);
...
+ //Render the HTML code given
+ void Render (string HtmlCode);
Your param names aren't consistent. You should use underscore_names
everywhere. (
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-patches] r46899 - in trunk/mcs/class/Managed.Windows.Forms: . Test/System.Windows.Forms
On Mon, 2005-07-04 at 03:12 -0400, Ritvik Mayank wrote: + Assert.AreEqual(System.Windows.Forms.ListBox+ObjectCollection, lb1.Items.ToString(), #7); Please don't do that. The ToString functionality is provided by Object, there's no need to test it. It also prevents any clever tricks (for example, returning a derived class). -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-patches] r46919 - trunk/mcs/mbas/Test/misc
On Mon, 2005-07-04 at 16:10 -0400, Rafael Teixeira wrote: -test-local: WriteOK.exe aspx_temp.dll ctest.exe +test-local: WriteOK.exe aspx_temp.dll test.exe gtk.exe You can't depend on gtk# being installed. This broke buildbot. I've already reverted your changes ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [PATCH] Race condition when restarting threads
Hey,
In a Mono bug report, we noticed a very rare race in the GC when
restarting the world. GC_restart_handler states:
/* Let the GC_suspend_handler() know that we got a SIG_THR_RESTART. */
/* The lookup here is safe, since I'm doing this on behalf */
/* of a thread which holds the allocation lock in order */
/* to stop the world. Thus concurrent modification of the */
/* data structure is impossible.*/
However, this comment is not always true. When starting the world, the
thread that does the restarting does *not* wait for all threads to get
past the point where they need the structures used by the lookup for it
to release the GC_lock.
So the sequence of events looked something like:
* T1 signals T2 to restart the world
* T1 releases the GC_lock
* T3 is a newborn thread and adds itself to the table
* T2 gets the signal and sees a corrupt table because T3 is
concurrently modifying it.
What would end up happening when we experienced the race was either a
deadlock or a SIGSEGV.
The race was extremely rare. It took 1-2 hours to reproduce on an SMP
machine. With the attached patch, it has not segfaulted or hung for 21
hrs.
-- Ben
Index: pthread_stop_world.c
===
--- pthread_stop_world.c (revision 46881)
+++ pthread_stop_world.c (working copy)
@@ -163,6 +163,12 @@
/* to accidentally leave a RESTART signal pending, thus causing us to */
/* continue prematurely in a future round.*/
+/* Tell the thread that wants to start the world that this */
+/* thread has been started. Note that sem_post() is */
+/* the only async-signal-safe primitive in LinuxThreads.*/
+sem_post(GC_suspend_ack_sem);
+
+
#if DEBUG_THREADS
GC_printf1(Continuing 0x%lx\n, my_thread);
#endif
@@ -421,6 +427,7 @@
register GC_thread p;
register int n_live_threads = 0;
register int result;
+int code;
# if DEBUG_THREADS
GC_printf0(World starting\n);
@@ -450,7 +457,21 @@
}
}
}
+
#if DEBUG_THREADS
+GC_printf0 (All threads signaled);
+#endif
+
+for (i = 0; i n_live_threads; i++) {
+ while (0 != (code = sem_wait(GC_suspend_ack_sem))) {
+ if (errno != EINTR) {
+ GC_err_printf1(Sem_wait returned %ld\n, (unsigned long)code);
+ ABORT(sem_wait for handler failed);
+ }
+ }
+}
+
+#if DEBUG_THREADS
GC_printf0(World started\n);
#endif
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mono and Ubuntu 5.10 Release Schedule
On Sun, 2005-07-03 at 12:09 -0500, Mike Kestner wrote: On Sun, 2005-07-03 at 12:16 -0400, Brandon Hale wrote: I've already spoken with Mike, Ben, and Miguel on IRC, but I would appreciate any creative solutions to either API or scheduling issues that you can come up with. Anybody ever tried doing a mono bundle with MD? I assume you are trying to say ignore the fact that gtk# 2.x is unstable, just include it with md. If so, MD could just copy the .dll files as private assemblies. Much easier (and smaller!) than bundling. However, we are planning to ship gtk# 2.x with Mono 1.2 as a package (like 1.0 and 1.0 were), right? It'd be a shame not to see us ship one half of the package. All that tseng really needs is to know that by Aug. Xth, Gtk# 2.x will be reasonably API frozen. I think its pretty clear that 1.2 will be way before the Ubuntu final release. We just need to make sure that we are frozen early enough so that they feel comfortable using our code. Imagine what kind of mess it would be if Ubuntu shipped Gtk+ 2.7.5. That's the kind of mess we'll be facing if we make it hard for them to ship Gtk# 2. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] RE: Mono Installation Question
On Fri, 2005-07-01 at 13:35 +0930, Kent Boogaart wrote: Thanks for the suggestions guys. Unfortunately, I'm not any closer to getting this resolved. If I try updating the RPMs rather than installing I get: # rpm -Uvh glibc-common-2.3.2-27.9.7vfs3.i386.rpm error: failed dependencies glibc 2.3.2 conflicts with glibc-common-2.3.2-27.9.7vfs3 glibc-common = 2.2.4-26 is needed by glibc-2.2.4-26 The rpms we create are for systems with a glibc that is newer than the one in RH9. If your OS is older than that (as your rhel is), you are basically on your own. You'll need to build from source. -- Ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-devel-list] Re: [Mono-patches] r46615 - trunk/mcs/class/System.Data/Test/System.Data
On Tue, 2005-06-28 at 11:16 +0300, Eyal Alaluf wrote: Hi, Ben. Can you send me Kosta the list of failures you have? I don't recall these tests below failing and perhaps something does not work well on your side. I mostly got stuff like: 2) MonoTests_System.Data.DataSetTest2.ReadXml_Strm : System.ArgumentOutOfRangeException : 1 is not in a range between 1 and . I don't have a complete list here. If you revert the changes I made, you can see what is failing. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: [Mono-patches] r46615 - trunk/mcs/class/System.Data/Test/System.Data
On Tue, 2005-06-28 at 19:51 +0300, Eyal Alaluf wrote:
Hi, Ben.
I believe that we have an issue to resolve here. I never got this particular
error and I believe that you have a problem on your side. Specifically, I
don't get any failures like that for the following tests:
- [Category (NotWorking)]
public void ReadXml_Strg()
- [Category (NotWorking)]
public void ReadXml_Strm()
- [Category (NotWorking)]
public void ReadXml_ByTextReader()
- [Category (NotWorking)]
public void ReadXml_ByXmlReader()
[EMAIL PROTECTED] System.Data]$ svn di
Index: Test/System.Data/DataSetTest2.cs
===
--- Test/System.Data/DataSetTest2.cs(revision 46656)
+++ Test/System.Data/DataSetTest2.cs(working copy)
@@ -1851,7 +1851,7 @@
}
[Test]
- [Category (NotWorking)]
+ //[Category (NotWorking)]
public void ReadXml_Strg()
{
string sTempFileName =
tmpDataSet_ReadWriteXml_43894.xml ;
[EMAIL PROTECTED] System.Data]$ make run-test
ok=:; make run-test-recursive || ok=false; make run-test-local || ok=false; $ok
make[1]: Entering directory `/home/benm/msvn/mcs/class/System.Data'
make[1]: Leaving directory `/home/benm/msvn/mcs/class/System.Data'
make[1]: Entering directory `/home/benm/msvn/mcs/class/System.Data'
MONO_PATH=../../class/lib/default:$MONO_PATH
/home/benm/msvn/mono/runtime/mono-wrapper ../../class/lib/default/mcs.exe
-d:NET_1_1 -d:ONLY_1_1 -debug /target:library /out:System.Data_test_default.dll
/r:../../class/lib/default/System.Data.dll
-r:../../class/lib/default/nunit.framework.dll
-r:../../class/lib/default/nunit.core.dll
-r:../../class/lib/default/nunit.util.dll /nowarn:649 /nowarn:169 /nowarn:219
/nowarn:168 /nowarn:1595 /r:mscorlib.dll /r:../../class/lib/default/System.dll
/r:System.Xml.dll /r:System.EnterpriseServices.dll /r:Mono.Data.Tds.dll
/nowarn:618 @../../build/deps/System.Data_test_default.dll.response
Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(257) warning
CS0162: Unreachable code detected
Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(265) warning
CS0162: Unreachable code detected
Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(269) warning
CS0162: Unreachable code detected
Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(273) warning
CS0162: Unreachable code detected
Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(277) warning
CS0162: Unreachable code detected
Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(281) warning
CS0162: Unreachable code detected
Test/System.Data.Tests.Mainsoft/GHTUtils/DbTypeParameter.cs(285) warning
CS0162: Unreachable code detected
Compilation succeeded - 7 warning(s)
ok=:; \
MONO_PATH=../../class/lib/default::$MONO_PATH
/home/benm/msvn/mono/runtime/mono-wrapper --debug
../../class/lib/default/nunit-console.exe /output:TestResult-default.log
/exclude:NotWorking,ValueAdd,CAS,InetAccess /xml:TestResult-default.xml
System.Data_test_default.dll || ok=false; \
sed '1,/^Tests run: /d' TestResult-default.log; \
$ok
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.11.1Mono Version: 1.1.4322.573
Excluded categories: NotWorking,ValueAdd,CAS,InetAccess
..N..N..N.N.N.N.NNN..N...NN..F..
Tests run: 1131, Failures: 1, Not run: 12, Time: 12.614229 seconds
Failures:
1) MonoTests_System.Data.DataSetTest2.ReadXml_Strg :
System.ArgumentOutOfRangeException : 1 is not in a range between 1 and .
Parameter name: year
in [0x000f2]
Re: [Mono-devel-list] [PATCH] System.Activator
On Tue, 2005-06-28 at 20:55 +0100, Elliott Draper wrote: Hi guys, This is a simple patch that implements the generic Activator.CreateInstance method found in the .Net framework v2.0, within Mono (NET_2_0). It will allow code written under .Net v2.0 using the method, to take advantage of the same method under Mono without code change. The full method signature is: public static T CreateInstanceT(); Great patch! I added it (with a bit of style fix up) to svn. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
