Re: [Mono-dev] Build problems on Solaris 9/sparc
Hi, Jason Downs [EMAIL PROTECTED] writes: I've been trying to get mono 1.1.8.3 built on Solaris 9/sparc. It's not going very well. The first problem encountered is when the build process attempts to use mcs for the first time. mcs is there, and is a working .exe, but it appears to be *invoking* it wrong (note the usage line): [...] make[3]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' make profile-do--default--all profile-do--net_2_0--all make[4]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' make PROFILE=basic all make[5]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' make[6]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' usage: mcs [-cdpVz] [-a string] [-n name] file ... make[6]: *** [build/deps/basic-profile-check.exe] Error 1 make[6]: Leaving directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs' *** The compiler 'mcs' doesn't appear to be usable. *** Falling back to using pre-compiled binaries. Be warned, this may not work. This is expected. make[6]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/jay' make all-local make[7]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/jay' gcc -DSKEL_DIRECTORY=\/usr/local/share/jay\ -g -O2 -c -o closure.o closure.c [...] I've went through all of the various Makefile fragments looking for what could be the problem, but I've not found it. Perhaps unsurprisingly, the build then eventually fails while compiling the classes: [...] make[8]: Entering directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/class/Mono.Security' make[8]: *** No rule to make target `Mono.Math.Prime.Generator/SequentialSearchPrimeGeneratorBase.cs', needed by `../../class/lib/net_1_1_bootstrap/Mono.Security.dll'. Stop. make[8]: Leaving directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/class/Mono.Security' make[7]: *** [do-all] Error 2 make[7]: Leaving directory `/usr/local/src/build/mono-1.1/mono-1.1.8.3/mcs/class/Mono.Security' make[6]: *** [all-recursive] Error 1 [...] Anyone have any ideas why this will not build? It's just Solaris 9 w/ GNU, nothing particularly special about the environment. Using gcc-3.4.4. Hmm, for some reason, your tarball or your tar is broken. I suspect that you used the Solaris 'tar' program on your machine to extract the source from the tarball. Try using 'pax' or 'cpio' or GNU tar instead. - Hari ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [GMCS] unreviewed generics patches
Hi, I've been very busy with the debugger the last couple of weeks, so I didn't notice your patches until you sent them to me again in personal mail. They should now all be in SVN (expect the BindGenericTypes - MakeGenericType issue, I'm currently working on that). If I missed anything, please lemme know. There's also a status report bug #75982 - if there is anything generics-related which needs to go into 1.1.9, please add it there. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [GMCS] unreviewed generics patches
On 9/5/05, Martin Baulig [EMAIL PROTECTED] wrote: They should now all be in SVN (expect the BindGenericTypes - MakeGenericType issue, I'm currently working on that). If I missed anything, please lemme know. Please make sure, you also commit monop.patch. There's also a status report bug #75982 - if there is anything generics-related which needs to go into 1.1.9, please add it there. Hm, the reflection sizes patch you applied unfortunately wasn't the last one. The missing change is: Index: reflection.c === --- reflection.c(revision 49449) +++ reflection.c(working copy) @@ -9333,7 +9333,7 @@ MONO_ARCH_SAVE_REGS; - p = buf = g_malloc (size = 30 + na * 30); + p = buf = g_malloc (size = 50 + na * 50); mono_metadata_encode_value (0x07, p, p); mono_metadata_encode_value (na, p, p); Strangely this only shown up when using debug Nemerle builds. Anyway I'll be trying to produce some dynamic buffer patch here soon (but probably not before 1.1.9). -- Michal Moskal, http://nemerle.org/~malekith/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Collections.Generic.{Stack, Queue} API updates
Updates based on the VS.Net 2005 August CTP The patch looks good to me. 2005-09-04 David Waite [EMAIL PROTECTED] * Queue.cs,Stack.cs: Mark as serializable, change TrimToSize to TrimExcess, Mark enumerator as serializable * QueueTest.cs, StackTest.cs: updated to match API changes ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Type.GUID patch
Hello, Here’s a patch for the Type.GUID property. It was previously always returning Guid.Empty. It now returns the value of the GuidAttribute specified on the Type, else it returns Guid.Empty. This seems to be the behavior of .Net. Please review and commit, or give me permission to commit. I applied this version, but I noticed that there is a long discussion on the mailing list. If someone cares deeply about changing the semantics for this, am open to take an updated patch. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
I'm trying to get example working on winxp with mono-1.0.5 which only creates a form: Mono 1.0.5 does not have a working Windows.Forms and has been deprecated in favor of Mono 1.1.8. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] header have been already sent ?
I am also getting this exception in my application when I am trying to access a protected page (see attached application). Instead of redirecting to the login page the exception is thrown and a Unauthorized page is shown. There are a few other things that are not working anymore: + ValidationSummary does not seem to work (when leaving the name field empty for example) + When adding a namespace that does not exist, I don't get an error. The page just loads forever. For example: %@ Import Namespace=foo % Bernhard - Original Message - Hello, I'm back from my holydays... and i've updated mono from svn... It seems that there are many changes in ASP.NET Many web application that worked before doesn't work now... The first error I experience is an xsp error : We need a test case for this. Something in your code is triggering the HTTP headers to be sent. You can debug this by adding a: Console.WriteLine (Environment.StackTrace) To: mcs/class/System.Web/System.Web/HttpResponse.cs in the method WriteHeaders Send me the output. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list protected.aspx Description: Binary data web.config Description: Binary data login.aspx Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [GMCS] unreviewed generics patches
On Mon, 2005-09-05 at 15:56 +0200, Michal Moskal wrote: On 9/5/05, Martin Baulig [EMAIL PROTECTED] wrote: They should now all be in SVN (expect the BindGenericTypes - MakeGenericType issue, I'm currently working on that). If I missed anything, please lemme know. Please make sure, you also commit monop.patch. There's also a status report bug #75982 - if there is anything generics-related which needs to go into 1.1.9, please add it there. Hm, the reflection sizes patch you applied unfortunately wasn't the last one. The missing change is: Hello, they're now both in SVN. Martin Index: reflection.c === --- reflection.c(revision 49449) +++ reflection.c(working copy) @@ -9333,7 +9333,7 @@ MONO_ARCH_SAVE_REGS; - p = buf = g_malloc (size = 30 + na * 30); + p = buf = g_malloc (size = 50 + na * 50); mono_metadata_encode_value (0x07, p, p); mono_metadata_encode_value (na, p, p); Strangely this only shown up when using debug Nemerle builds. Anyway I'll be trying to produce some dynamic buffer patch here soon (but probably not before 1.1.9). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Win32 build broken since r49459
Hi, I am unable to build mcs tree since r49459 updates. I used the following command line, but the result is the same with just 'make': $ make EXTERNAL_MCS=/usr/local/bin/mcs EXTERNAL_RUNTIME=/usr/local/bin/mono basic profile compiles but then I get the following error: MONO_PATH=../class/lib/basic:$MONO_PATH /mono/mono/runtime/mono-wrapper ../cl ass/lib/basic/mcs.exe /nologo /optimize -d:NET_1_1 -d:ONLY_1_1 /debug+ /debug:f ull -target:exe -out:mcs.exe cs-parser.cs @../build/deps/mcs.exe.response The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `C:\Mono\mono\mono\mini\lib\mono\1.0\mscorl ib.dll' directory. make[7]: *** [../class/lib/net_1_1_bootstrap/mcs.exe] Error 1 I think this is originating from the build system. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Remove UnmanagedType_80
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? Kornél RemoveUnmanagedType_80.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Win32 build broken since r49459
Hi, I just reverted r49459. Hari was trying to fix another build problem at that time, but seems like it brought another problem. Atsushi Eno Kornél Pál wrote: Hi, I am unable to build mcs tree since r49459 updates. I used the following command line, but the result is the same with just 'make': $ make EXTERNAL_MCS=/usr/local/bin/mcs EXTERNAL_RUNTIME=/usr/local/bin/mono basic profile compiles but then I get the following error: MONO_PATH=../class/lib/basic:$MONO_PATH /mono/mono/runtime/mono-wrapper ../cl ass/lib/basic/mcs.exe /nologo /optimize -d:NET_1_1 -d:ONLY_1_1 /debug+ /debug:f ull -target:exe -out:mcs.exe cs-parser.cs @../build/deps/mcs.exe.response The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `C:\Mono\mono\mono\mini\lib\mono\1.0\mscorl ib.dll' directory. make[7]: *** [../class/lib/net_1_1_bootstrap/mcs.exe] Error 1 I think this is originating from the build system. Kornél ___ 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] [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] Win32 build broken since r49459
El dt 06 de 09 del 2005 a les 03:11 +0900, en/na Atsushi Eno va escriure: Hi, I just reverted r49459. Hari was trying to fix another build problem at that time, but seems like it brought another problem. These are the problems that I was hitting this morning. Thanks for looking into this. When it is fixed I can also test it on Win32. Jordi, -- Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com Homepage and LiveJournal at http://www.softcatala.org/~jmas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] Generic Array.Sort
Hello, yes, it has a good performance. But we have a problem, because the runtime has a problem comparing generic types. See: http://bugzilla.ximian.com/show_bug.cgi?id=75889 After this is solved, we can apply the patch. Carlos. El lun, 05-09-2005 a las 11:27 -0400, Ben Maurer escribió: Hey, On Thu, 2005-08-18 at 20:45 -0500, Carlos Alberto Cortez wrote: I've attached a patch containing the impl for the generic versions of Array.Sort. What's the status of this patch? I am thinking that the performance of this is probably good enough that we can get it in. IIRC, there were no comments other than my performance based ones on the list. -- 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
Hi, There should not be problem about this as we don't use methods that use ArraySubType in our bootstrap assemblies. This means that if you use old mcs it will compile it without errors or warnings but will emit bugous (I4 instead of 80) metadata. This is not a problem as the assembiles that are installed and used to build class status pages are built using the latest mcs so they will have correct metadata. Kornél - Original Message - From: Ben Maurer [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, September 05, 2005 10:41 PM Subject: 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Time zone problems with DateTime.Parse (patch and bug)
I've been having some fun problems with time zones when reading timestamps from strings using DateTime.ParseExact and its wrappers. Behavior of both of these bugs seems consistent between current SVN on Linux (Ubuntu Hoary) and 1.1.8 on Windows XP SP2, set for US Pacific time. My test cases work correctly on .NET 1.1 on the XP box. First, The DateTimeStyles.AdjustToUniversal flag is ignored for times formatted like '2005-09-05T22:29:00Z', so the return value is in local time even though you asked for universal. Test case and patch for that: http://bugzilla.ximian.com/show_bug.cgi?id=75995 Second, conversion to local time seems to handle daylight saving time transitions incorrectly. Here in PDT/PST, in the autumn we transition from UTC-7 to UTC-8 at 2am local time, but reading in UTC timestamps with Mono's DateTime.Parse I find it switches at 2am *UTC*, several hours earlier. Test case: http://bugzilla.ximian.com/show_bug.cgi?id=75985 I think the problem here is that the internal DateTime(bool,long) constructor calls tz.GetUtcOffset(this) with the UTC time to get the timezone offset before applying it to get local time, but that function expects a local time to determine if DST is active. A bit of a chicken-and-egg problem, perhaps... ;) (It's not actually possible to determine if an unmarked local time is in daylight saving time or not for all cases. During the autumn transition an entire hour occurs twice in the local time sequence: once in DST and again in standard time. The second hour will end up aliased to the first if you try to do round-trip conversions without keeping the local timezone with the time.) -- brion vibber (brion @ pobox.com) signature.asc Description: OpenPGP digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Marshal Variable length structure Array in Mono
Quick question: does anybody know of a standard Win32, POSIX, or
GLib/GTK/Gnome-related function that uses variable length structures?
I'd like to use one as a canonical example in the Marshaling guide:
http://www.mono-project.com/Interop_with_Native_Libraries
More complete answer below...
On Fri, 2005-09-02 at 09:02 -0400, Yogendra Thakur wrote:
Hi ,
I want to marshal following C structure .
[C]
struct Foo
{
int First;
int Second;
};
struct FooList
{
int Count;
Foo List[1];
};
void GetFooList(struct * FooList fList);
I am doing it following way
[C#]
[StructLayout(LayoutKind.Sequential)]
class Foo
{
public Int32 First;
public Int32 Second;
}
Personally, I would suggest using a struct to alleviate GC pressure, but
a class will also work.
[StructLayout(LayoutKind.Sequential)]
class FooList
{
public Int32 Count;
private IntPtr list;//pointer to first
public Foo[] Foos
{
// HOW TO DO THIS
Short answer: you don't. Not like that, anyway.
You shouldn't do things like this because you need to keep marshaling as
a logically separate activity: when invoking unmanaged code you allocate
an unmanaged representation, and when the unmanaged code returns you
convert it into a managed representation. Trying to keep the unmanaged
and managed representations identical can be problematic, especially in
this case where the unmanaged representation is so unusual.
}
}
My problem is how to form objects from IntPtr and return as Foo[].
(If i directly use Marshal.PtrToStruct(list,typeof(Foo)); it throws
object reference not set to object while access Foo.First.)
I googled about it and I found a solution which uses kernel32.dll and
uses GlobalFree, GlobalAlloc API's.
I'm not sure why anyone would need to P/Invoke into kernel32.dll, since
the GlobalAlloc-related APIs are exposed directly on
System.Runtime.InteropServices.Marshal.
Attached is sample code to deal with variable length structures.
Compile and run with:
$ gcc -g -shared -o libvlist.so vlist.c
$ mcs -debug+ vlist.cs
$ mono vlist.exe
vlist.c contains two canonical exports: GetFooList() takes an IN-OUT
pointer to a FooList structure, which allows some data (the Count in
this case) to be passed in by the caller. AllocFooList() takes a double
pointer to a FooList structure, allocating and filling the variable
length structure.
From the C# side of things, GetFooList() is more complicated because a
variable-length structure needs to be manually allocated -- you can't
rely on the default P/Invoke marshaler to do this for you, as it doesn't
know how. This is done within FooList.ToIntPtr(), which allocates
unmanaged memory using Marshal.AllocHGlobal() and fills that memory
using Marshal.StructureToPtr(). Note the use of FooListMarshal, since
the FooList type can't be properly marshaled (since it contains extra
book-keeping information to simplify things). Once an unmanaged
variable-length structure is allocated we can call GetFooList(), which
will fill our structure. FooList.FillFromIntPtr reads the unmanaged
variable-length structure and fills the current FooList instance with
the appropriate data.
AllocFooList() is simpler to deal with, mostly because you don't need to
manually construct a variable-length structure; you instead just need to
read it, making it 1/2 as difficult as the GetFooList() case.
- Jon
/* variable-count list at end of structure */
/* compile as: gcc -g -shared -o libvlist.so vlist.c */
#include stdlib.h
#include stdio.h
struct Foo {
int First;
int Second;
};
struct FooList {
int Count;
struct Foo List[0];
};
void
GetFooList (struct FooList *fList)
{
int i;
for (i = 0; i fList-Count; ++i) {
int n = i+1;
fList-List[i].First = n;
fList-List[i].Second = n*n;
}
}
void
AllocFooList (struct FooList **pfList)
{
const int NUM_ENTRIES = 5;
int i;
*pfList = malloc (sizeof(struct FooList) + NUM_ENTRIES*(sizeof (struct Foo)));
(*pfList)-Count = NUM_ENTRIES;
for (i = 0; i NUM_ENTRIES; ++i) {
int n = i+1;
(*pfList)-List[i].First = n;
(*pfList)-List[i].Second = n*n*n;
}
}
static void
print_foo_list (struct FooList *pfList)
{
int i;
printf (Count: %i\n, pfList-Count);
for (i = 0; i pfList-Count; ++i) {
printf ( Elem: {%i, %i}\n, pfList-List[i].First, pfList-List[i].Second);
}
}
int
main ()
{
struct FooList* list;
int i;
printf (GetFooList\n);
list = malloc(sizeof(struct FooList) + 4*(sizeof (struct Foo)));
list-Count = 4;
GetFooList (list);
print_foo_list (list);
free (list);
printf (AllocFooList\n);
AllocFooList (list);
print_foo_list (list);
free (list);
}
// variable length list processing
//
// Compile with: mcs -debug+ vlist.cs
using System;
using System.Runtime.InteropServices;
[StructLayout (LayoutKind.Sequential)]
class Foo
{
public int First;
public int Second;
}
class FooList
{
int count;
Foo[] list;
public
Re: [Mono-dev] .NET Remoting: Upload of a file from a Win32 MS .NET client to a Linux Mono .NET server.
On 9/5/05, Yngve Zackrisson [EMAIL PROTECTED] wrote:
On Fri, 2005-09-02 at 23:15, Sunny wrote:
Sorry, replied off the list, here is a copy:
Not sure you got it right.
I want to upload data (transfer a file from the client to the server).
It does not matter. If you have a remoting call, and you pass a Stream
over, the Stream.Read method will pass the buffer in both directions,
so you will double the traffic.
In your case, I would make my server method to look like:
public void UploadFileChunk(byte[] buffer)
{
//add this byte array to FileOut ...
}
And from the client just loop through your fileIn, sending chunks
to the server and update your progress bar in the loop.
This is a good article on the topic:
http://www.genuinechannels.com/Content.aspx?id=23type=1
I had a refferens to that in my post :-).
Sorry, I did not read it. And still can not find it. Anyway ...
I gona test the approach suggested by Robert Jordan.
It is similar to your approach.
Tanks
Yngve Zackrisson.
--
Svetoslav Milenov (Sunny)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] header have been already sent ?
Hello, [ Gonzalo, can you review if revision 49519 is correct? ] I am also getting this exception in my application when I am trying to access a protected page (see attached application). Instead of redirecting to the login page the exception is thrown and a Unauthorized page is shown. Thanks for the test case, this is what I needed. I have committed a fix to SVN for accessing protected.aspx and it now takes me to the login.aspx page, could you please try the latest version from SVN? I could not understand your other issues, could you provide a test case that fails? Miguel. There are a few other things that are not working anymore: + ValidationSummary does not seem to work (when leaving the name field empty for example) + When adding a namespace that does not exist, I don't get an error. The page just loads forever. For example: %@ Import Namespace=foo % Bernhard - Original Message - Hello, I'm back from my holydays... and i've updated mono from svn... It seems that there are many changes in ASP.NET Many web application that worked before doesn't work now... The first error I experience is an xsp error : We need a test case for this. Something in your code is triggering the HTTP headers to be sent. You can debug this by adding a: Console.WriteLine (Environment.StackTrace) To: mcs/class/System.Web/System.Web/HttpResponse.cs in the method WriteHeaders Send me the output. Miguel ___ 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 -- Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
