Selective Logging patch

Hi,

	Here is an update for mini of the selective logging patch. I've also updated the man page.

Prepare the beers gonzalo :))

Jerome.

IPv6 patch

Hi monoers,

Here are some patches to allow IPv6 connectivity in mono applications. This is a preliminary patch that
breaks the .NET 1.0 compatibility (At least until the NET_1_1 define is not defined).

Right now, everything seems to work fine in both IPv4 and IPv6. XSP works in IPv6 mode smoothly and so is 
remoting. I will provide test cases soon.

I'd like to point out the fact that using only the first element of the IPHostEntry.AddressList property is
not a correct behavior and might lead to incorrect connections. Some parts of the mcs tree are based on that.

Attached with this post two patches: one for mono and the other for mcs. I've added the
IPv6MulticastOptions.cs file and a description of the modifications applied by patches.

Please feel free to test theses modifications.

Thanks,
Jerome.

(From Jerome LABAN, 2003/06/01)

socket-io.c:

	* convert_to_mono_family: Added InterNetworkV6
	* convert_sockopt_level_and_name: Added socket IPv6 options convertions
	* ves_icall_System_Net_Sockets_Socket_Socket_internal: Added AF_INET6 handling
	* create_object_from_sockaddr: Added creation of SocketAddress from sockaddr_in6
	* ves_icall_System_Net_Sockets_Socket_LocalEndPoint_internal: 
		Generalized function to handle sockaddr_in and sockaddr_in6

Re: AW: GC/Memory allocation performance

On 05/30/03 Marcus wrote:
> Doesn't Boehm's GC have a compacting mode? I know that SRC Modula-3 (and its 
> descendants) for over 10 years have used a Boehm GC that is generational, 
> incremental, and compacting.

The standard Boehm GC can do some form of incremental/generational
collectiong (but no compacting), but enabling it in mono always results
in a SEGV in libgc's code for me. It may still be a mono issue, I didn't
investigate it. That support also relies on trapping SIGSEGV that mono
uses too to handle null ref exceptions, so it may not be possible to
deal with it anyway.
Enabling it for the C microbenchmark makes the numbers worse, though,
from 0.95 to 1.2 for the statically compiled version.

lupus

--

-- 
-----------------------------------------------------------------
lupus <at> debian.org                                     debian/rules
lupus <at> ximian.com                             Monkeys do it better

Re: AW: GC/Memory allocation performance

                                            Hi,

  During incremental GC, the heap is write protected, which
causes
system calls like read() to fail if they get passed a
pointer to memory
inside the heap. This happens in the current io-layer code.
Even if
this is fixed, enabling incremental GC only shortens GC
pauses, but
leads to longer total time spent doing GC. 

            bye

                      Zoltan

Paolo Molaro <lupus <at> ximian.com> írta:

> On 05/30/03 Marcus wrote:
> > Doesn't Boehm's GC have a compacting mode? I know that
SRC Modula-3 (and its 
> > descendants) for over 10 years have used a Boehm GC that
is generational, 
> > incremental, and compacting.
> 
> The standard Boehm GC can do some form of
incremental/generational
> collectiong (but no compacting), but enabling it in mono
always results

mcs compilation problems

Hello!

After doing

make clean

I can't compile mcs from cvs.
I set MONO_PATH to directory where I have *.dll files and then

make -f makefile.gnu

but got output shown in the attachement "error-mcs" - make finds mcs.exe
just in mcs/mcs/ directory.

Then I copied mcs.exe to mcs/mcs/ and tried again, but got output shown
in the "error-nunit".
There are a lot of "Unhandled Exception: System.NullReferenceException:
A null value was found where an object instance was required" messages
and finally "touch: getting attributes of `../nunit-console.exe': No
such file or directory" error.

Copying of nunit-console.exe to the mcs/nunit20/ directory doesn't help
too, because compilation takes next portion of errors (see "error").

What's wrong?

Thanks!
Best regards, dim.

GetHashCode () differences from Microsoft

Hey guys,

As you may know, I am running the Rotor Test Suite (found under
/test/bcl/system in the sscli directory). I noticed that there are many
differences between our GetHashCode methods and the ones in Microsoft's
corlib.dll. This causes many of the Rotor tests to fail. Some examples
of items that are failing are the GUID stuff and the char tests.

It would be helpful for my testing to change our implementation to use
the same methods as Rotor to obtain the hashcode of structures. This is
not hard to do, especially since the license to Rotor allows us to take
a look at the way they do it, take pseudo code notes, and make an
implementation of our own. Does anyone have any strong feelings (either
way), about this issue? Could I get an OK/Not OK from a few of the
Ximian people? Of course, I am volunteering to make these changes, and
would be happy to have my code reviewed.

-- Ben

Re: [Mono-winforms-list] SWF failed to start in Linux-Mandrake 9.1

On 2003.06.03 10:56 Mohammad DAMT wrote:
>> So, those warnings should not appear in output :)
> 
> how current and what server?
> I use
> [mdamt <at> gordon mono]$ cat CVS/Root
> :pserver:anonymous <at> anoncvs.go-mono.com:/mono
> 
> I've checked out this morning and yields the same result

for mono-devel-list:
make -f makefile.gnu install did not copy mcs/class/lib/*  to PREFIX/lib
so I have to manually copy all dlls to PREFIX/lib

for mono-winform-list: :D
the same exception still came when I ran the app

[mdamt <at> gordon Coba]$ mono coba.exe
  Unhandled Exception: System.NullReferenceException: A null value was 
found where an object instance was required
in (unmanaged) 00 System.Windows.Forms.Control:.ctor ()
in <0x0000e> 00 System.Windows.Forms.ScrollableControl:.ctor ()
in <0x00014> 00 System.Windows.Forms.ContainerControl:.ctor ()
in <0x00018> 00 System.Windows.Forms.Form:.ctor ()
in <0x0000a> 00 MyFormProject.MainForm:.ctor ()
in <0x00054> 08 MyFormProject.MainForm:.ctor ()
in <0x0001e> 00 MyFormProject.MainForm:Main (string[])

Build problems with SuSE 8.2

I have SuSE 8.2 (FTP version) on a Compaq EVO N800V.
I have tried to build mono and mcs with the use of the instructions on
the download page but with no luck. I also tried the mono-build.sh
script with no success.
pkgconfig and glib is the ones included in the SuSE distribution.

What to do? Whats wrong?
I am no Linux hacker and have little knowlege in gcc, make and those
tools but I have successfully built apps from source before.

=== output from mono-build.sh (the end of it anyway) ===
/usr/bin/install: cannot stat `./System.Web.dll': No such file or
directory
 /usr/bin/install -c -m 644 ./System.Web.Services.dll
/home/a130494/mono-devel/install/lib/System.Web.Services.dll
/usr/bin/install: cannot stat `./System.Web.Services.dll': No such file
or directory
 /usr/bin/install -c -m 644 ./System.Windows.Forms.dll
/home/a130494/mono-devel/install/lib/System.Windows.Forms.dll
/usr/bin/install: cannot stat `./System.Windows.Forms.dll': No such file
or directory
 /usr/bin/install -c -m 644 ./System.Xml.dll
/home/a130494/mono-devel/install/lib/System.Xml.dll
/usr/bin/install: cannot stat `./System.Xml.dll': No such file or
directory
gmake[2]: *** [install-assembliesDATA] Error 1
gmake[2]: Leaving directory `/home/a130494/mono-devel/mono/runtime'
gmake[1]: *** [install-am] Error 2
gmake[1]: Leaving directory `/home/a130494/mono-devel/mono/runtime'
gmake: *** [install-recursive] Error 1

History Lesson : Mono was the first open source .net project? I dont think so.

Dear Mono Hackers,

I was wondering if anyone of you has reviewed the new German book :
"Mono: .NET-kompatible Anwendungen mit dem Open Source-Framework"

http://www.go-mono.com/books.html

It is stating that when the mono project was started,
there was nothing at all. "Am anfang war nichts."

It has no mention of the dotgnu project, or the pnet work done by rhys
before the mono project was started. I was quite suprised about this,
and wrote to the authors who said that the book was reviewed by the
mono team.

It is quite suprising to me that such a grave mistake slipped in. 
I cannot find any mention of the fact that the pnet project was started
first on the web page. There does not seem to be any objective account
of what pnet is or its goals. 

It must be embarassing to allow such mistaken history to be portrayed,
but it seems to be the InformationsPolitik of the Mono project.

I was wondering if anyone cares to comment on this?

thanks,
mike

=====
James Michael DuPont

Re: History Lesson : Mono was the first open source .net project? I dont think so.

On Tue, 2003-06-03 at 14:19, James Michael DuPont wrote:
> Dear Mono Hackers,
> 
> I was wondering if anyone of you has reviewed the new German book :

Yes, I reviewed the book.

> "Mono: .NET-kompatible Anwendungen mit dem Open Source-Framework"
> 
> http://www.go-mono.com/books.html
> 
> It is stating that when the mono project was started,
> there was nothing at all. "Am anfang war nichts."

OK, I will try to translate that section:

------------------------------------------
1.1.1: In the beginning there was nothing

In the beginning there was nothing - approximately this was the
situation until recently. In the meantime Mono developed with high
speed, and the developers implemented more and more functions and
classes.
----------------------------------------

> It has no mention of the dotgnu project, or the pnet work done by rhys
> before the mono project was started. I was quite suprised about this,
> and wrote to the authors who said that the book was reviewed by the
> mono team.