[Mono-dev] S390
Hi there! The Mono S390 works on Linux 390, isn't it? Ok, my question is: can a mono app running on a 390 virtual machine access resources on other partitions or in the real host? We'd considering giving support to host users using mono too... Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ask for backport on mono 1.2.5 branch
Le vendredi 31 août 2007 à 17:00 +0200, Miguel de Icaza a écrit :
Hello,
In the actual release, a simple ASP.NET with a ListBox Control
don't
work, viewstate deserialization problem...
sigh.We made tons of preview releases to get people a chance to
check stuff against 1.2.5.
We have been doing them for more than a month now. Our largest
release
cycle.
Miguel.
Hello
I understand, but most of our team was on holydays during this
period...
(i think you should not choose holydays period for testing period...)
Thanks for the backport, i promise that i'll check preview release next
time!
Hubert
This problem as been fixed in the trunk by :
2007-08-30 Igor Zelmanovich [EMAIL PROTECTED]
* ListControl.cs: fixed selected items state management.
Could this be backported to the mono 1.2.5 branch?
Here's a test case for this problem :
Default.aspx:
%@ Page Language=C# Inherits=TestViewState.Default %
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html
head
titleDefault/title
/head
body
form id=form1 runat=server
asp:Button id=button1 runat=server /
asp:ListBox id=drpSociete runat=server CssClass=TextBox200
Width=200px Visible=True
Rows=1/asp:ListBox
/form
/body
/html
Default.aspx.cs :
// Default.aspx.cs created with MonoDevelop
// User: hubert at 15:02 31/08/2007
//
// To change standard headers go to
Edit-Preferences-Coding-Standard Headers
//
using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data;
namespace TestViewState
{
public class Default : Page
{
protected ListBox drpSociete;
protected override void OnLoad(EventArgs e)
{
if (!IsPostBack){
drpSociete.Items.Add(bouh);
drpSociete.Items.Add(bah);
}
}
}
}
Click two times on the button and you'll obtain :
Server Error in '/' Application
__
Index is less than 0 or more than or equal to the list count.
Parameter name: index 0
Description: Error processing request.
Error Message: HTTP 500. System.ArgumentOutOfRangeException: Index
is
less than 0 or more than or equal to the list count. Parameter
name:
index 0
Stack Trace:
System.ArgumentOutOfRangeException: Index is less than 0 or more
than or equal to the list count.
Parameter name: index
0
at System.Collections.ArrayList.get_Item (Int32 index) [0x0]
at System.Web.UI.WebControls.ListItemCollection.get_Item (Int32
index) [0x0]
at System.Web.UI.WebControls.ListControl.LoadViewState
(System.Object savedState) [0x0]
at System.Web.UI.Control.LoadViewStateRecursive (System.Object
savedState) [0x0]
at System.Web.UI.Control.LoadViewStateRecursive (System.Object
savedState) [0x0]
at System.Web.UI.Control.LoadViewStateRecursive (System.Object
savedState) [0x0]
at System.Web.UI.Page.LoadPageViewState () [0x0]
at System.Web.UI.Page.InternalProcessRequest () [0x0]
at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext
context) [0x0]
Thanks in advance!
___
Ce message et les ventuels documents joints peuvent contenir des
informations confidentielles.
Au cas o il ne vous serait pas destin, nous vous remercions de bien
vouloir le supprimer et en aviser immdiatement l'expditeur. Toute
utilisation de ce message non conforme sa destination, toute
diffusion
ou publication, totale ou partielle et quel qu'en soit le moyen est
formellement interdite.
Les communications sur internet n'tant pas scurises, l'intgrit de
ce
message n'est pas assure et la socit mettrice ne peut tre tenue
pour
responsable de son contenu.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Ce message et les �ventuels documents joints peuvent contenir des informations
confidentielles.
Au cas o� il ne vous serait pas destin�, nous vous remercions de bien vouloir
le supprimer et en aviser imm�diatement l'exp�diteur. Toute utilisation de ce
message non conforme � sa destination, toute diffusion ou publication, totale
ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'�tant pas s�curis�es, l'int�grit� de ce
message n'est pas assur�e et la soci�t� �mettrice ne peut �tre tenue pour
responsable de son contenu.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Warnings in mono 1.2.5
Hi! I am running a vanilla mono 1.2.5 on Suse 10.0. My app (Amazon S3 backup utility) occasionally (like 1 in 20 runs) produces warnings: WARNING **: _wapi_thread_abandon_mutexes: error looking up thread handle 0x408 WARNING **: _wapi_thread_set_termination_details: error looking up thread handle (nil) Despite the warnings, app works fine. My app mostly uses synchronous HttpWebRequests, no threading. Any ideas what might be the cause? I considered filing a bug, but I cannot provide any simpe testcase yet, so I decided to ask here first. Cheers, Michał Ziemski ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] I have another bug in class Using
mcs\statement.cs
in Class Using:
// protected override void CloneTo (CloneContext clonectx, Statement t)
// {
// Using target = (Using) t;
//if (expression_or_block is Expression)
//target.expression_or_block =
((Expression)expression_or_block).Clone(clonectx);
//else
// error--- target.expression_or_block = ((Statement)
expression_or_block).Clone (clonectx);
// } line 4670,4685 expression_or_block is either a Expression or a
DictionaryEntry, not a Statement.
lei.min gmx
2007-08-29
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bug #81924 On big endian ARM IXP425 system: System.ArgumentException: Size is too big
Hi, I have updated bugzilla bug #81924 to include 2 patches. 1st patch fixes the big endian issue in inssel-float.brg that allows JIT soft floats to be read correctly. This allows the float calculation in hashtable.cs to no longer assert and therefore, mono no longer crashes. It is a blocker fix for big endian systems using JIT soft floats. 2nd patch is to fix the configure script (via configure.in) so that no FPU support for ARM can be selected. This is a Debian fix for ARM. This is my 1st post, please can someone explain the process of getting these patches merged to trunk ? I tried reassigning the bug back to Paolo Molaro, did I do the correct thing ? Thanks, Regards, Dean. MontaVista Software Ltd. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Who broke master pages in trunk :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 31, 2007, at 4:58 AM, R. Tyler Ballance wrote: I'm checking out the 1.2.5 tag from SVN just to double check that the release didn't contain the regression, I'll report back if it does. For what it's worth, the tagged release of 1.2.5 doesn't have this issue, so it's a recently committed regression I'm assuming Mono JIT compiler version 1.2.5 (/tags/mono-1-2-5/ r85094) Cheers, - -R. Tyler Ballance -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG2A5FA2GmJ0VpG78RAmEOAJ0RLwM3/Q4OrgbKhuYPzkcidIVaCQCguvqe dic2BaNwqETakMnVv0sLJ3E= =AnFh -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Warnings in mono 1.2.5
I've also seen these in previous releases... - Original Message - From: Michał Ziemski [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Monday, September 03, 2007 9:12 AM Subject: [Mono-dev] Warnings in mono 1.2.5 Hi! I am running a vanilla mono 1.2.5 on Suse 10.0. My app (Amazon S3 backup utility) occasionally (like 1 in 20 runs) produces warnings: WARNING **: _wapi_thread_abandon_mutexes: error looking up thread handle 0x408 WARNING **: _wapi_thread_set_termination_details: error looking up thread handle (nil) Despite the warnings, app works fine. My app mostly uses synchronous HttpWebRequests, no threading. Any ideas what might be the cause? I considered filing a bug, but I cannot provide any simpe testcase yet, so I decided to ask here first. Cheers, Michał Ziemski ___ 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] ask for backport on mono 1.2.5 branch
Hi,
Ooops after further investigation, it seems that this fix is not enough
to fix this problem... I'm investigating to find out the revision
number needed
Le vendredi 31 août 2007 à 15:51 +0200, Robert Jordan a écrit :
Hi,
Hubert FONGARNAND wrote:
In the actual release, a simple ASP.NET with a ListBox Control
don't
work, viewstate deserialization problem...
This problem as been fixed in the trunk by :
2007-08-30 Igor Zelmanovich [EMAIL PROTECTED]
* ListControl.cs: fixed selected items state management.
It's r85048:
http://lists.ximian.com/pipermail/mono-patches/2007-August/099919.html
Robert
Could this be backported to the mono 1.2.5 branch?
Here's a test case for this problem :
Default.aspx:
%@ Page Language=C# Inherits=TestViewState.Default %
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html
head
titleDefault/title
/head
body
form id=form1 runat=server
asp:Button id=button1 runat=server /
asp:ListBox id=drpSociete runat=server
CssClass=TextBox200
Width=200px Visible=True
Rows=1/asp:ListBox
/form
/body
/html
Default.aspx.cs :
// Default.aspx.cs created with MonoDevelop
// User: hubert at 15:02 31/08/2007
//
// To change standard headers go to
Edit-Preferences-Coding-Standard
Headers
//
using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data;
namespace TestViewState
{
public class Default : Page
{
protected ListBox drpSociete;
protected override void OnLoad(EventArgs e)
{
if (!IsPostBack){
drpSociete.Items.Add(bouh);
drpSociete.Items.Add(bah);
}
}
}
}
Click two times on the button and you'll obtain :
Server Error in '/' Application
Index is less than 0 or more than or equal to the list count.
Parameter
name: index 0
Description: Error processing request.
Error Message: HTTP 500. System.ArgumentOutOfRangeException: Index
is
less than 0 or more than or equal to the list count. Parameter
name:
index 0
Stack Trace:
System.ArgumentOutOfRangeException: Index is less than 0 or more
than or equal to the list count.
Parameter name: index
0
at System.Collections.ArrayList.get_Item (Int32 index) [0x0]
at System.Web.UI.WebControls.ListItemCollection.get_Item (Int32
index) [0x0]
at System.Web.UI.WebControls.ListControl.LoadViewState
(System.Object savedState) [0x0]
at System.Web.UI.Control.LoadViewStateRecursive (System.Object
savedState) [0x0]
at System.Web.UI.Control.LoadViewStateRecursive (System.Object
savedState) [0x0]
at System.Web.UI.Control.LoadViewStateRecursive (System.Object
savedState) [0x0]
at System.Web.UI.Page.LoadPageViewState () [0x0]
at System.Web.UI.Page.InternalProcessRequest () [0x0]
at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext
context) [0x0]
Thanks in advance!
___
Ce message et les éventuels documents joints peuvent contenir des
informations confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de
bien vouloir le supprimer et en aviser immédiatement l'expéditeur.
Toute utilisation de ce message non conforme à sa destination, toute
diffusion ou publication, totale ou partielle et quel qu'en soit le
moyen est formellement interdite.
Les communications sur internet n'étant pas sécurisées, l'intégrité
de ce message n'est pas assurée et la société émettrice ne peut être
tenue pour responsable de son contenu.
___
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
___
Ce message et les �ventuels documents joints peuvent contenir des informations
confidentielles.
Au cas o� il ne vous serait pas destin�, nous vous remercions de bien vouloir
le supprimer et en aviser imm�diatement l'exp�diteur. Toute utilisation de ce
message non conforme � sa destination, toute diffusion ou publication, totale
ou
[Mono-dev] More ODBC questions: AutoCommit and BeginTransaction
Hi all
I am not posting a bug, because I have no idea if this is a bug. Perhaps this
is the intended way:
For ODBC connections, the default mode is autocommit: Each statement is
followed by an commit, done by the driver, client side. This can be disabled
programmatically.
When an ODBC transaction is created in mono, we change the attributes in
OdbcTransaction.cs:
51 internal OdbcTransaction(OdbcConnection conn,
IsolationLevel isolationlevel)
52 {
53 // Set Auto-commit (102) to false
54 OdbcReturn
ret=libodbc.SQLSetConnectAttr(conn.hDbc, OdbcConnectionAttribute.AutoCommit,
IntPtr.Zero, 0);
We have to do that, obviously, but my question is wheter mono should
reestablish the state of autocommit upon completion of the transaction?
Currently it does not, but is this to be expected? I think, from my reading
that it is, but would very much like a confirmation.
Currently I am not able to check out the behavoiur using MS .NET.
Thanks,
Regards
Mads
--
Med venlig hilsen/Regards
Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] class status
Hi all, Just a small thing to do : May someone change in the xml of the status for the svn from http://svn.myrealbox.com/viewcvs/trunk to http://anonsvn.mono-project.com/viewcvs/trunk/ because when we do ctrl+click on the class status page we have error. There is another issue because the winform adresse is Managed.winformswhereas must be System.winforms. But not sure that it is solvable. thanks, bye Olivier ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [System.IO.Ports] How to configure the serial port?
Hello all! i just subscribed the list, this post is related to: http://lists.ximian.com/pipermail/mono-devel-list/2007-August/024670.html Take a look at chronojump code: http://gnome.org/projects/chronojump http://svn.gnome.org/viewcvs/chronojump/trunk/ specially: chronopic.cs library that connects to the chronopic (serial port) http://svn.gnome.org/viewcvs/chronojump/trunk/chronopic.cs chronojump_mini.cs little terminal software that gets data from serial port using chronopic.cs http://svn.gnome.org/viewcvs/chronojump/trunk/src/chronojump_mini.cs I hope it helps, bye ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] class status
Hello, Just a small thing to do : May someone change in the xml of the status for the svn from http://svn.myrealbox.com/viewcvs/trunk to http://anonsvn.mono-project.com/viewcvs/trunk/ This should soon be taken care of. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Big Arrays, Many Changes --- Request for Advice
Folks: I was porting a small test application that was written in C# that allocated an array with a large number of elements ( 2^32). While it compiled and ran in Visual Studio's C# under WindowsXP-64bit without a hitch, when I compiled and ran it under mcs/mono (1.2.4) on the same hardware, but booted up under Fedora7-x86_64, I ran into a few problems. Digging into it a bit, I discovered that: 1) MCS assumed that the arguments to NEWARR were always U4 or I4, which does not seem to be the case as far as ECMA-335v4. 2) MONO assumes that array lengths and bounds can always be represented as guint32's, [ like mono_array_new_specific (MonoVTable *vtable, guint32 n) ] Would folks object to a series of patches to: A) Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of OpCodes.Conv_Ovf_U4/I4 for array size arguments, B) Modify mono/metadata/object.h to change the base type for array lengths/bounds to XXX instead of guint32, C) Change mono/metadata/object.c to change the functions that create/ access arrays to take XXX instead of guint32 length/bounds arguments. Also perhaps update some of the lower level object allocation functions to use XXX as needed. D) Modify the execution of NEWARR be able to deal with I/U native types. No doubt something in the JIT needs tweaking as well. E) Double check that array indexing not only takes native int types, but uses them right. F) Add a few new test cases for large array allocation. G) Whatever else needs to be done that I'll bump into after I try making the above changes and realize what I forgot. Warnings of known hazards gratefully accepted. My big question is what the right type for the size ought to be? I've seen int, size_t, gsize, and guint32 used in Mono. I suspect that int and guint32 are wrong from a portability perspective, but would prefer that someone more intimately involved with Mono to say if guint or gsize or size_t were preferred. I'm guessing Bug 81774 is related to this as well. BTW, is this too big for a newby to tackle? --Luis F. Ortiz Follower of the Selfish Way ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
Hello, I don't have an answer to your problem, but I did have another question. I can't find a link to the documentation in msdn, but I thought arrays were limited to 2 GB in the .Net runtime (even on 64-bit). Do you not see this behavior? http://blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx Thanks, Jonathan On 9/3/07, Luis F. Ortiz [EMAIL PROTECTED] wrote: Folks: I was porting a small test application that was written in C# that allocated an array with a large number of elements ( 2^32). While it compiled and ran in Visual Studio's C# under WindowsXP-64bit without a hitch, when I compiled and ran it under mcs/mono (1.2.4) on the same hardware, but booted up under Fedora7-x86_64, I ran into a few problems. Digging into it a bit, I discovered that: 1) MCS assumed that the arguments to NEWARR were always U4 or I4, which does not seem to be the case as far as ECMA-335v4. 2) MONO assumes that array lengths and bounds can always be represented as guint32's, [ like mono_array_new_specific (MonoVTable *vtable, guint32 n) ] Would folks object to a series of patches to: A) Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of OpCodes.Conv_Ovf_U4/I4 for array size arguments, B) Modify mono/metadata/object.h to change the base type for array lengths/bounds to XXX instead of guint32, C) Change mono/metadata/object.c to change the functions that create/ access arrays to take XXX instead of guint32 length/bounds arguments. Also perhaps update some of the lower level object allocation functions to use XXX as needed. D) Modify the execution of NEWARR be able to deal with I/U native types. No doubt something in the JIT needs tweaking as well. E) Double check that array indexing not only takes native int types, but uses them right. F) Add a few new test cases for large array allocation. G) Whatever else needs to be done that I'll bump into after I try making the above changes and realize what I forgot. Warnings of known hazards gratefully accepted. My big question is what the right type for the size ought to be? I've seen int, size_t, gsize, and guint32 used in Mono. I suspect that int and guint32 are wrong from a portability perspective, but would prefer that someone more intimately involved with Mono to say if guint or gsize or size_t were preferred. I'm guessing Bug 81774 is related to this as well. BTW, is this too big for a newby to tackle? --Luis F. Ortiz Follower of the Selfish Way ___ 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] Mono 1.2.5 for Solaris 10/x86 binaries
Hi, I have made available for download Mono 1.2.5 for Solaris 10/x86 binaries at: http://tenkatext.sourceforge.net/redist/mono-1.2.5-solaris-10-x86-binary.tar .gz http://tenkatext.blogspot.com I would love to collaborate with the Mono team on maintaining similar binary packages for future versions too. Best Regards, Cetin Sert INF 521, 4-6-2 69120 Heidelberg Germany http://tenkatext.sourceforge.net/contact ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
