[Mono-announce-list] Mono 1.1.17 has been released.
Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code JavaScript code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now features an abstract Unix end point in addition to Unix End Points [Alp Toker]. XML Land Fixed XmlSchemaSet and XmlSchemaCollection problem across multiple namespaces [Atsushi Enomoto] Important Bug Fixes Dynamic linking of Mono is now possible in applications that were using the TLS (open office) [Zoltan Varga]. Newly created AppDomains no longer inherit the list of loaded assemblies from the main domain. This has an important side-effect, to get XSP and mod_mono running, you must install the latest versions of it (released in this iteration), older versions will not work [Lluis Sanchez]. A number of missing pieces of System.IO.Ports have been implemented (ReadChar, ReadLine, BytesToRead, BytesToWrite, ReadTo, return USB tty
Re: [Mono-docs-list] Wiki: Sorting some FAQ's
Hi, do you referre to the http://mono-project.com/User:ValentinSawadski#ThreadsBeginnersGuide part of the page? If so, thanks for the link but as said in the article I won't focus on a certain GUI or any other toolkit component since that stuff can be used in a wide range of scenarious. Kind Regards, Valentin. On Monday 28 August 2006 22:07, you wrote: Hey, In addition a first draft of the new FAQ page can be seen here: http://mono-project.com/User:ValentinSawadski (You have to scroll down a little bit, the article is below the second horizontal line.) Interesting stuff; You might want to consider linking to: http://www.mono-project.com/Responsive_Applications ___ Mono-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
[Mono-winforms-list] [PATCH] ListView sorting fixes
Hi,
I've attached a patch that fixes some issues in the way sorting was
implemented for ListView.
All changes are accompanied by unit tests that pass in Mono 1.0/2.0 and
MS.NET 1.1/2.0.
I made my changes bug-compatible with MS as I think it's the only way to
ensure our implementations keep matching non-bug changes in MS.NET in
the near future. But this is just my opinion. Of course there are limits
to this bug-compatibility, but in this case they don't cause much harm.
The bugs I came across in MS.NET are:
- .NET 1.1: once set, modifying Sorting does not have any effect for
SmallIcon and LargeIcon views unless a custom IComparer is set. This is
fixed in .NET 2.0.
- .NET 2.0: setting Sorting to None also discards the custom IComparer,
if set.
Is it ok to send patches to this list or should they go to the
devel-list ?
If you want me to submit a bug report (with repro), just let me know.
Gert
PS. Don't be alarmed by the size of the patch, most of it are unit
tests ;-)
Index: Test/System.Windows.Forms/ChangeLog
===
--- Test/System.Windows.Forms/ChangeLog (revision 64514)
+++ Test/System.Windows.Forms/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2006-08-29 Gert Driesen [EMAIL PROTECTED]
+
+ * ListViewTest.cs: Added test for bug #79076. Added tests for
+ sorting bug fixes.
+
2006-08-21 Carlos Alberto Cortez [EMAIL PROTECTED]
* ComboBoxTest.cs: Add tests for CB.ObjectCollection
Index: Test/System.Windows.Forms/ListViewTest.cs
===
--- Test/System.Windows.Forms/ListViewTest.cs (revision 64514)
+++ Test/System.Windows.Forms/ListViewTest.cs (working copy)
@@ -8,9 +8,11 @@
//
using System;
-using System.Windows.Forms;
+using System.Collections;
using System.Drawing;
using System.Reflection;
+using System.Windows.Forms;
+
using NUnit.Framework;
namespace MonoTests.System.Windows.Forms
@@ -80,10 +82,10 @@
myform.Controls.Add (mylistview);
mylistview.BeginUpdate ();
for(int x = 1 ; x 5000 ; x++){
-mylistview.Items.Add (Item + x.ToString());
+mylistview.Items.Add (Item + x.ToString());
}
mylistview.EndUpdate ();
- }
+ }
[Test]
public void ClearTest ()
@@ -112,7 +114,7 @@
myform.Controls.Add (mylistview);
mylistview.BeginUpdate ();
for(int x = 1 ; x 5000 ; x++) {
-mylistview.Items.Add (Item + x.ToString());
+mylistview.Items.Add (Item + x.ToString());
}
mylistview.EndUpdate ();
mylistview.EnsureVisible (4999);
@@ -132,5 +134,1120 @@
Assert.IsTrue (r.Height 0, #35e);
Assert.IsTrue (r.Width 0, #35f);
}
+
+ [Test]
+ public void bug79076 ()
+ {
+ ListView entryList = new ListView ();
+ entryList.Sorting = SortOrder.Descending;
+
+ entryList.BeginUpdate ();
+ entryList.Columns.Add (Type, 100, HorizontalAlignment.Left);
+
+ ListViewItem item = new ListViewItem (new string [] { A });
+ entryList.Items.Add (item);
+ item = new ListViewItem (new string [] { B });
+ entryList.Items.Add (item);
+ }
+
+ [Test]
+ public void Sort_Details_NotCreated ()
+ {
+ AssertSortNoIcon_NotCreated (View.Details);
+ }
+
+ [Test]
+ public void Sort_Details_Created ()
+ {
+ AssertSortNoIcon_Created (View.Details);
+ }
+
+ [Test]
+ public void Sort_LargeIcon_Created ()
+ {
+ AssertSortIcon_Created (View.LargeIcon);
+ }
+
+ [Test]
+ public void Sort_LargeIcon_NotCreated ()
+ {
+ AssertSortIcon_NotCreated (View.LargeIcon);
+ }
+
+ [Test]
+ public void Sort_List_NotCreated ()
+ {
+ AssertSortNoIcon_NotCreated (View.List);
+ }
+
+ [Test]
+ public void Sort_List_Created ()
+ {
+ AssertSortNoIcon_Created (View.List);
+ }
+
+ [Test]
+ public void Sort_SmallIcon_Created ()
+ {
+ AssertSortIcon_Created (View.SmallIcon);
+ }
+
+ [Test]
+ public void Sort_SmallIcon_NotCreated ()
+ {
+ AssertSortIcon_NotCreated (View.SmallIcon);
+ }
+
+#if NET_2_0
+ [Test]
+ public void Sort_Tile_Created ()
+ {
+ AssertSortNoIcon_Created (View.Tile);
+ }
+
+ [Test]
+ public void Sort_Tile_NotCreated ()
+ {
+ AssertSortNoIcon_NotCreated (View.Tile);
+ }
+#endif
+
+ private void AssertSortIcon_Created (View view)
+ {
+ int compareCount = 0;
+
+ Form form = new Form ();
+ ListView lvw = CreateListView (view);
+ form.Controls.Add (lvw);
+ Assert.IsNull (lvw.ListViewItemSorter, #A);
+
+ form.Show ();
+
+ Assert.IsNull (lvw.ListViewItemSorter, #B1);
+ Assert.AreEqual (B, lvw.Items [0].Text, #B2);
+ Assert.AreEqual (A, lvw.Items [1].Text, #B3);
+ Assert.AreEqual (C, lvw.Items [2].Text, #B4);
+
+ lvw.Sorting = SortOrder.None;
+ Assert.IsNull (lvw.ListViewItemSorter, #C1);
+ Assert.AreEqual (B, lvw.Items [0].Text, #C2);
+ Assert.AreEqual (A, lvw.Items [1].Text, #C3);
+ Assert.AreEqual (C, lvw.Items [2].Text, #C4);
+
+ lvw.Sorting = SortOrder.Descending;
+ Assert.IsNotNull (lvw.ListViewItemSorter, #D1);
+ Assert.AreEqual (C,
Re: [Mono-winforms-list] NullReferenceException calling SWF.Control.set_AccessibleRole
I did some digging through the Infragistics code that I mentioned in my first e-mail and I do not see any class that overrides AccessibleObject. This UltraToolBarsDockArea extends and abstract called UltraControlBase, which itself extends
SWF.Control. Neither of the Ultra classes overrides the Accessibility methods.The InitControlStyles method that results in the NullRef exception is more or less doing this: if (!base.DesignMode) {
if (this.isPopupArea) { base.AccessibleRole = AccessibleRole.MenuPopup; } else { base.AccessibleRole =
AccessibleRole.Grouping; } }In .NET 1.1 that should go to:public AccessibleRole AccessibleRole{ set { if (!Enum.IsDefined(typeof(AccessibleRole), value))
{ throw new InvalidEnumArgumentException(value, (int) value, typeof(AccessibleRole)); } this.Properties.SetInteger(Control.PropAccessibleRole, (int) value);
}}But in MWF.Control, as I'm sure you know, it's doing:public AccessibleRole AccessibleRole { set { AccessibilityObject.role=value; }That doesn't look like a problem unless the AccessibleObject is for some reason not getting initialized before the set.
I also tried running this on Mono 1.1.6 and it basically gave me the same exception with the addition of:in (wrapper stfld) System.Object:__stfld_wrapper_System.Int32 (object,intptr,intptr,intptr,int)
I don't know enough about the Mono code to say whether that is meaningful, although I do wonder if the AccessibleRole property has a problem with the value.If you have any thoughts on additional things I can look at or additional data I can provide please let me know. At this point this appears to be an incompatibility with Mono, but I certainly don't have enough evidence to say there's a bug here.
Thanks,NickOn 8/28/06, Rafael Teixeira [EMAIL PROTECTED] wrote:
Looking at our code, I would say that the only chance of happening anull reference error is if the control that UltraToolbarsDockArea istrying to set the AccessibleRole (presumbaly itself) redefines(overrides) the method:
protected virtual AccessibleObject CreateAccessibilityInstance() {return new Control.ControlAccessibleObject(this);}With one that is not able to return a new AcessibleObject-compatible
instance, for some other cause.Good luck,On 8/24/06, Nick Thorpe [EMAIL PROTECTED] wrote: Hi all, I'm trying to get a 3rd party GUI library (Infragistics NetAdvantage)
working with Mono 1.1.16.1. When I run our application it dies almost instantly with this exception:Unhandled Exception: System.NullReferenceException: Object reference not
set to an instance of an object at System.Windows.Forms.Control.set_AccessibleRole (AccessibleRole value) [0x0] at Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea.InitControlStyles
() [0x0] at Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea..ctor () [0x0] at (wrapper remoting-invoke-with-check) Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea:.ctor
() at PSOMA.Form1.InitializeComponent () [0x0] at PSOMA.Form1..ctor () [0x0] at (wrapper remoting-invoke-with-check) PSOMA.Form1:.ctor () at PSOMA.Form1.Main () [0x0]
I checked the CIL to see if the library was using something outside of .NET, but it looks pretty standard and is seems to be failing at this call: IL_0098:call instance void
[System.Windows.Forms]System.Windows.Forms.Control::set_AccessibleRole(valuetype [System.Windows.Forms]System.Windows.Forms.AccessibleRole) I don't know enough about SWF to say whether this is a bug, or if these
libraries are doing something unsupported. If anyone has any input on the problem I'd appreciate it. Thanks, Nick
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] NullReferenceException calling SWF.Control.set_AccessibleRole
Please DO NOT post decompiled code to this, or any other mono related
list.
On Wed, 2006-08-30 at 10:50 -0700, Nick Thorpe wrote:
I did some digging through the Infragistics code that I mentioned in
my first e-mail and I do not see any class that overrides
AccessibleObject. This UltraToolBarsDockArea extends and abstract
called UltraControlBase, which itself extends SWF.Control. Neither of
the Ultra classes overrides the Accessibility methods.
The InitControlStyles method that results in the NullRef exception is
more or less doing this:
if (!base.DesignMode)
{
if (this.isPopupArea)
{
base.AccessibleRole = AccessibleRole.MenuPopup;
}
else
{
base.AccessibleRole = AccessibleRole.Grouping;
}
}
In .NET 1.1 that should go to:
public AccessibleRole AccessibleRole
{
set
{
if (!Enum.IsDefined(typeof(AccessibleRole), value))
{
throw new InvalidEnumArgumentException(value,
(int) value, typeof(AccessibleRole));
}
this.Properties.SetInteger(Control.PropAccessibleRole,
(int) value);
}
}
But in MWF.Control, as I'm sure you know, it's doing:
public AccessibleRole AccessibleRole {
set {
AccessibilityObject.role=value;
}
That doesn't look like a problem unless the AccessibleObject is for
some reason not getting initialized before the set.
I also tried running this on Mono 1.1.6 and it basically gave me the
same exception with the addition of:
in (wrapper stfld) System.Object:__stfld_wrapper_System.Int32
(object,intptr,intptr,intptr,int)
I don't know enough about the Mono code to say whether that is
meaningful, although I do wonder if the AccessibleRole property has a
problem with the value.
If you have any thoughts on additional things I can look at or
additional data I can provide please let me know. At this point this
appears to be an incompatibility with Mono, but I certainly don't have
enough evidence to say there's a bug here.
Thanks,
Nick
On 8/28/06, Rafael Teixeira [EMAIL PROTECTED] wrote:
Looking at our code, I would say that the only chance of
happening a
null reference error is if the control that
UltraToolbarsDockArea is
trying to set the AccessibleRole (presumbaly itself) redefines
(overrides) the method:
protected virtual AccessibleObject
CreateAccessibilityInstance() {
return new
Control.ControlAccessibleObject(this);
}
With one that is not able to return a new
AcessibleObject-compatible
instance, for some other cause.
Good luck,
On 8/24/06, Nick Thorpe [EMAIL PROTECTED] wrote:
Hi all,
I'm trying to get a 3rd party GUI library (Infragistics
NetAdvantage)
working with Mono 1.1.16.1. When I run our application it
dies almost
instantly with this exception:
Unhandled Exception: System.NullReferenceException: Object
reference not
set to an instance of an object
at System.Windows.Forms.Control.set_AccessibleRole
(AccessibleRole value) [0x0]
at
Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea.InitControlStyles
() [0x0]
at
Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea..ctor
() [0x0]
at (wrapper remoting-invoke-with-check)
Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea:.ctor
()
at PSOMA.Form1.InitializeComponent () [0x0]
at PSOMA.Form1..ctor () [0x0]
at (wrapper remoting-invoke-with-check) PSOMA.Form1:.ctor
()
at PSOMA.Form1.Main () [0x0]
I checked the CIL to see if the library was using something
outside of .NET,
but it looks pretty standard and is seems to be failing at
this call:
IL_0098: call instance void
[System.Windows.Forms]System.Windows.Forms.Control::set_AccessibleRole(valuetype
[System.Windows.Forms]System.Windows.Forms.AccessibleRole)
I don't know enough about SWF to say whether this is a bug,
or if these
libraries are doing something unsupported. If anyone has any
input on the
problem I'd appreciate it.
Thanks,
Nick
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
Re: [Mono-winforms-list] NullReferenceException callingSWF.Control.set_AccessibleRole
You did not just post decompiled Microsoft code, did you?
You just killed any chance of anyone who read your message fixing that
function.
Do not post decompiled code to the list. Do not decompile MS code if you're
involved with fixing MWF, or even making suggestions on how to fix bugs you
encounter.
Peter
-Original Message-
From: Nick Thorpe [EMAIL PROTECTED]
To: Rafael Teixeira [EMAIL PROTECTED]
Cc: mono-winforms-list@lists.ximian.com
Date: Wednesday, August 30, 2006 13:50
Subject: Re: [Mono-winforms-list] NullReferenceException
callingSWF.Control.set_AccessibleRole
I did some digging through the Infragistics code that I mentioned in my
first e-mail and I do not see any class that overrides AccessibleObject.
This UltraToolBarsDockArea extends and abstract called UltraControlBase,
which itself extends SWF.Control. Neither of the Ultra classes overrides
the
Accessibility methods.
The InitControlStyles method that results in the NullRef exception is more
or less doing this:
if (!base.DesignMode)
{
if (this.isPopupArea)
{
base.AccessibleRole = AccessibleRole.MenuPopup;
}
else
{
base.AccessibleRole = AccessibleRole.Grouping;
}
}
In .NET 1.1 that should go to:
public AccessibleRole AccessibleRole
{
set
{
if (!Enum.IsDefined(typeof(AccessibleRole), value))
{
throw new InvalidEnumArgumentException(value, (int)
value, typeof(AccessibleRole));
}
this.Properties.SetInteger(Control.PropAccessibleRole, (int)
value);
}
}
But in MWF.Control, as I'm sure you know, it's doing:
public AccessibleRole AccessibleRole {
set {
AccessibilityObject.role=value;
}
That doesn't look like a problem unless the AccessibleObject is for some
reason not getting initialized before the set.
I also tried running this on Mono 1.1.6 and it basically gave me the same
exception with the addition of:
in (wrapper stfld)
System.Object:__stfld_wrapper_System.Int32(object,intptr,intptr,intptr,int)
I don't know enough about the Mono code to say whether that is meaningful,
although I do wonder if the AccessibleRole property has a problem with the
value.
If you have any thoughts on additional things I can look at or additional
data I can provide please let me know. At this point this appears to be an
incompatibility with Mono, but I certainly don't have enough evidence to
say
there's a bug here.
Thanks,
Nick
On 8/28/06, Rafael Teixeira [EMAIL PROTECTED] wrote:
Looking at our code, I would say that the only chance of happening a
null reference error is if the control that UltraToolbarsDockArea is
trying to set the AccessibleRole (presumbaly itself) redefines
(overrides) the method:
protected virtual AccessibleObject CreateAccessibilityInstance()
{
return new Control.ControlAccessibleObject(this);
}
With one that is not able to return a new AcessibleObject-compatible
instance, for some other cause.
Good luck,
On 8/24/06, Nick Thorpe [EMAIL PROTECTED] wrote:
Hi all,
I'm trying to get a 3rd party GUI library (Infragistics NetAdvantage)
working with Mono 1.1.16.1. When I run our application it dies almost
instantly with this exception:
Unhandled Exception: System.NullReferenceException: Object reference
not
set to an instance of an object
at System.Windows.Forms.Control.set_AccessibleRole
(AccessibleRole value) [0x0]
at
Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea.InitControlStyles
() [0x0]
at
Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea..ctor
() [0x0]
at (wrapper remoting-invoke-with-check)
Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea:.ctor
()
at PSOMA.Form1.InitializeComponent () [0x0]
at PSOMA.Form1..ctor () [0x0]
at (wrapper remoting-invoke-with-check) PSOMA.Form1:.ctor ()
at PSOMA.Form1.Main () [0x0]
I checked the CIL to see if the library was using something outside of
.NET,
but it looks pretty standard and is seems to be failing at this call:
IL_0098: call instance void
[System.Windows.Forms
]System.Windows.Forms.Control::set_AccessibleRole(valuetype
[System.Windows.Forms]System.Windows.Forms.AccessibleRole)
I don't know enough about SWF to say whether this is a bug, or if these
libraries are doing something unsupported. If anyone has any input on
the
problem I'd appreciate it.
Thanks,
Nick
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] NullReferenceException calling SWF.Control.set_AccessibleRole
Hi Nick,
First, I think you can't disclose such details of infragistics and
.NET code, that you may be obtaining from disassembling their
assemblies. I'm quite sure their licenses prohibit it.
For what I can help...
But in MWF.Control, as I'm sure you know, it's doing:
public AccessibleRole AccessibleRole {
set {
AccessibilityObject.role=value;
}
That doesn't look like a problem unless the AccessibleObject is for some
reason not getting initialized before the set.
AcessibilityObject is here a get acessor that lazily creates on first
usage such object using the protected virtual method
CreateAccessibilityInstance to do so, that is why I asked if it was
overriden, as the default implementation simply creates an instance of
the Control.ControlAccessibleObject class, and therefore it never
should return a null (it would throw some other exception if bad
things wen't wrong on creating it).
You could try to put breakpoints by running MWF on .NET/VS, or use
some tracing or console messages while running on Mono to help
pinpoint the location of the probable out-of-order initialization or
race condition.
The good thing about Mono is that you have the sources, so it may be
easier to find the problem and to devise/propose a solution...
:)
--
Rafael Monoman Teixeira
---
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. George Bernard Shaw
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] Weird issues reading pixels of jpg file on osx
When attempting to read the pixel bytes of a jpg on osx (using the
1.1.17 build just released) I am getting different results on windows
versus osx. Does anybody have any ideas why I am getting these
different results? Any information is very appreciated.
Dan
The code being used is as follows:
Bitmap bmp = new Bitmap(file.jpg);
BitmapData bmpdata = bmp.LockBits(new Rectangle(0,0,bmp.Width,
bmp.Height),ImageLockMode.ReadOnly,PixelFormat.Format24bppRgb);
unsafe{
byte* scandata = (byte*) bmpdata.Scan0;
for(int i=0; i30; i++){
Console.WriteLine(scandata[i]);
}
}
and the results using mono on windows are:
187
144
77
187
144
77
186
144
75
188
143
75
188
144
73
189
145
74
192
147
74
192
147
74
192
150
75
191
149
74
while the results on osx are:
255
255
255
255
255
77
255
255
255
255
77
255
255
255
144
75
255
143
75
255
255
73
255
188
255
255
188
144
255
189
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Weird issues reading pixels of jpg file on osx
Hello Dan,
Did the same code worked on a previous version of Mono ? (if so which
version ?) or are you testing this for the first time ?
Because I recently fixed many endian issues affecting Mac OS X (and
other architectures). It is possible that one of them has broken
something else :-(
I'll try to build a similar test case using one of the embedded bitmap
files we have in the unit tests and see how to bots reacts to it.
On Wed, 2006-08-30 at 15:56 -0700, Dan Shryock wrote:
When attempting to read the pixel bytes of a jpg on osx (using the
1.1.17 build just released) I am getting different results on windows
versus osx. Does anybody have any ideas why I am getting these
different results? Any information is very appreciated.
Dan
The code being used is as follows:
Bitmap bmp = new Bitmap(file.jpg);
BitmapData bmpdata = bmp.LockBits(new Rectangle(0,0,bmp.Width,
bmp.Height),ImageLockMode.ReadOnly,PixelFormat.Format24bppRgb);
unsafe{
byte* scandata = (byte*) bmpdata.Scan0;
for(int i=0; i30; i++){
Console.WriteLine(scandata[i]);
}
}
and the results using mono on windows are:
187
144
77
187
144
77
186
144
75
188
143
75
188
144
73
189
145
74
192
147
74
192
147
74
192
150
75
191
149
74
while the results on osx are:
255
255
255
255
255
77
255
255
255
255
77
255
255
255
144
75
255
143
75
255
255
73
255
188
255
255
188
144
255
189
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
Sebastien Pouliot [EMAIL PROTECTED]
Blog: http://pages.infinit.net/ctech/
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] [Mono-list] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
I've responded separately to Jon because I find his comments inflammatory.
The SULF project you reference predates the FUSE low-level API and
even the latest couple kernel interface revisions. You could have
found out about much newer code, and perhaps learned something about
FUSE itself through a number of routes:
1. ask about the state of SULF. I would not have recommended starting
with this defunct project, nor recommended referencing it as an
alternative.
2. search FUSE mailing list for C# related announcements (and language
binding discussions in general)
3. search this Mono list for FUSE related announcements
regards,
Valient
On 8/29/06, Jonathan Pryor [EMAIL PROTECTED] wrote:
Mono.Fuse is a binding for the FUSE library, permitting user-space
file systems to be written in C#.
Why?
===
I read Robert Love's announcement of beaglefs, a FUSE program that
exposes Beagle searches as a filesystem. My first thought: Why
wasn't that done in C# (considering that the rest of Beagle is C#)?
What about SULF?
===
Stackable User-Level Filesystem, or SULF
(http://arg0.net/users/vgough/sulf/), is a pre-existing FUSE binding
in C#, started by Valient Gough in 2004.
Mono.Fuse has no relation to SULF, for two reasons:
1. It goes to great efforts to avoid a Mono.Posix.dll dependency,
duplicating Mono.Unix.Native.Stat (Fuse.Stat),
Mono.Unix.Native.Statvfs (Fuse.StatFS), and many methods from
Mono.Unix.Native.Syscall (Fuse.Wrapper).
2. I don't like the SULF API. (Not that I spent a great deal of
time looking at it, but what I did see I didn't like.)
3. SULF wraps the FUSE kernel-level interface, while Mono.Fuse
wraps the higher level libfuse C interface
I find (1) the most appalling, if only because I'm the Mono.Posix
maintainer and I'd like to see my work actually used. :-)
Once I started writing Mono.Fuse, I discovered a good reason to avoid
Mono.Posix: it's currently impossible to use from outside of Mono.
I figured this would be a good opportunity to rectify that, making it
easier for additional libraries to build upon the Mono.Posix
infrastructure.
Implementation:
==
Mono.Fuse requires patches to the mcs mono modules, changes which
need to be proposed (hence this email) and discussed.
mono:
The biggest problem with the mono module is that no headers are
installed, making it difficult to make use of libMonoPosixHelper.so.
Changes:
- Modify `configure' to generate a mono-config.h file, installed as
$libdir/mono/include/mono-config.h. (Basic idea borrowed from
GLib's $libdir/glib-2.0/include/glibconfig.h).
- Add a mono-posix-helper.pc file
- Install the files $includedir/mono/posix/helper.h and
$includedir/mono/posix/map.h.
map.h is the current map.h file generated by make-map.exe, with some
major additions (detailed in the mcs section).
helper.h is the main include file, which includes map.h and declares
all types/functions which cannot be generated by make-map.exe.
mono-config.h is necessary because it needs to contain
platform-specific macros. In particular, Linux needs:
int
Mono_Posix_ToStat (struct statvfs *to, struct Mono_Posix_Helper *to);
while OS X and *BSD need:
int
Mono_Posix_ToStat (struct statfs *to, struct Mono_Posix_Helper *to);
Note `struct statvfs' vs. `struct statfs'. The mono/posix/helper.h
header needs to paper over the difference, and thus needs to know
which type the platform prefers. helper.h thus looks like:
#ifdef MONO_HAVE_STATVFS
struct statvfs;
int Mono_Posix_ToStatvfs (struct statvfs *from,
struct Mono_Posix_Statvfs *to);
#endif
#ifdef MONO_HAVE_STATFS
struct statfs;
int Mono_Posix_ToStatvfs (struct statfs *from,
struct Mono_Posix_Statvfs *to);
#endif
One of MONO_HAVE_STATVFS or MONO_HAVE_STATFS would be defined in
mono-config.h.
mcs:
---
There are two major changes:
* The addition of one public attributes to the API:
// targets Class, Delegate, Enum, Field, Struct
class Mono.Unix.Native.MapAttribute {
public MapAttribute ();
public MapAttribute (string nativeType);
public string NativeType {get;}
public string NativeSymbolPrefix {get; set;}
}
* A major revamp to make-map.exe
The Map and MapHeader attributes are public so that make-map.exe can
use a publically exposed API for code generation purposes which can be
used by other libraries (Mono.Fuse makes use of these changes).
Make-map.exe can also generate structure declarations and delegate
declarations in addition to P/Invoke function declarations,
allowing for a better, automated interface between C and C#.
Previously, [Map] could only be used on enumerations.
Now, [Map] can be used on classes, structures, delegates, to create
a C declaration of the C# type, suitable for P/Invoke purposes, e.g.
[Map] struct Stat {public
Re: [Mono-dev] Mono 1.1.17 has been released.
Miguel de Icaza wrote: Mono 1.1.17 has been released. [...] The following bugs were fixed on this release: I made a list of the bugs fixed that contains a little more info than only the number: http://www.frijters.net/mono-bugs-fixed-1.1.17.html Regards, Jeroen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash.Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming,what would even be better then write once, run anywhere, iswrite for any purpose, write once, run anywhereand unfortunately mono has not provided a means to use it as a browserplugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE.Until this can occur, a programmer still has to Java or (active xplugin), to achieveweb page integration.Unfortunately not having this is a huge barrier to some people adopting mono.Providing this (as even MS .Net doesn't seem to provide web page pluginability of .Net) would put Mono over the top, and likely bring many morecontributors on board making Mono grow much faster. -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then its easy enough just to make a gui for both web and desktop using asp/gtk whatever. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieveweb page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
You should take note that mono-service based program doesn't work with this version... Le mardi 29 aot 2006 16:43 -0400, Miguel de Icaza a crit : Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code _javascript_ code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now features an abstract Unix end point in addition to Unix End Points [Alp Toker]. XML Land Fixed XmlSchemaSet and XmlSchemaCollection problem across multiple namespaces [Atsushi Enomoto] Important Bug Fixes Dynamic linking of Mono is now possible in applications that were using the TLS (open office) [Zoltan Varga]. Newly created AppDomains no longer inherit the list of loaded assemblies from the main domain. This has an important side-effect, to get XSP and mod_mono running, you must install the latest versions of it (released in this iteration), older versions will not work [Lluis Sanchez]. A
Re: [Mono-dev] Mono 1.1.17 has been released.
On Wed, August 30, 2006 09:58, ted leslie wrote: [snip] when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. Whilst I haven't put an awful lot of thought into it, can there be a middle ground between 'ActiveX'-style browser apps and install-only apps? For example, instead of installing an app, or allowing ActiveX-Mono for want of a better term, you might add a decrypting (public) key to your keyring for the application you wish to run. The 'add key' dialog might resemble the pop-up you will see if you try to access a secure website, whose keys were not created by a central certification authority. This would hopefully allow applications encrypted with the correct private key to run, and only those applications. Any others will be blocked by default. (To be honest, I'd be happy if all browser plugins worked in this way, flash especially. Thank you, FlashBlock.) This could be backed up, by limiting the Mono runtime which runs embedded in the browser, to 'sand-box' the application. However, I can only see this being useful in a corporate setting, with many people hot-desking or working from home, yet needing to access applications in the same environment, wherever they are, and without really installing a number of applications beforehand. Even then, there are probably better methods to achieve the same end result. I have been involved with many projects, and the clients always have the same needs. The audience goes to a web site, and you want to make your sale QUICK (or viral growth), say its a podcast client, a community collaboration tool, casino games, whatever, and the clients don't want to hear about a install executable, or a pokey asp.net sol'n, they want, when i boils down to it, an active X plugin (vb, c, c++ depending on needs) (or Java), and it just runs right there, no fuss no muss. Programmers don't think twice about installing a gtk app, 99+% of web users will not touch it with a ten foot pole. They will move on to the next casino, or community collaboration tool that just works right there, and yes many times now, you can find it to be flash, but lets not even go there and discuss the use of flash. I am just saying, it would be nice if Mono answered everyones needs (w.r.t the general places that you deploy programs - i.e. stand alone apps, ajax, asp.net, scripts/command line, and lastly browser plugins ), and filled this rather HUGE void (all be it a particularly commercial one). -tl On Wed, 2006-08-30 at 08:11 +0100, damien churchill wrote: __ From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then itâs easy enough just to make a gui for both web and desktop using asp/gtk whatever. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl ___ 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
Re: [Mono-dev] Mono 1.1.17 has been released.
The thread is about a language (platform) allowing one to do most anything, adding Flash to the mix immediately defeats the purpose. I use asp.net, great for many things when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. I have been involved with many projects, and the clients always have the same needs. The audience goes to a web site, and you want to make your sale QUICK (or viral growth), say its a podcast client, a community collaboration tool, casino games, whatever, and the clients don't want to hear about a install executable, or a pokey asp.net sol'n, they want, when i boils down to it, an active X plugin (vb, c, c++ depending on needs) (or Java), and it just runs right there, no fuss no muss. Programmers don't think twice about installing a gtk app, 99+% of web users will not touch it with a ten foot pole. They will move on to the next casino, or community collaboration tool that just works right there, and yes many times now, you can find it to be flash, but lets not even go there and discuss the use of flash. I am just saying, it would be nice if Mono answered everyones needs (w.r.t the general places that you deploy programs - i.e. stand alone apps, ajax, asp.net, scripts/command line, and lastly browser plugins ), and filled this rather HUGE void (all be it a particularly commercial one). -tl On Wed, 2006-08-30 at 08:11 +0100, damien churchill wrote: __ From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then it’s easy enough just to make a gui for both web and desktop using asp/gtk whatever. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl ___ 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] [gnome-db] GDA/GNOME-DB in Mono
it would be better probably if you send mono questions to the gtk-sharp
list. They'll be able to help better than us. In fact, we have the mono
bindings in our source tree because they were moved from GTK#, so it
would be nice to have them working.
On Tue, 2006-08-22 at 19:25 -0500, Daniel Espinosa wrote:
Ok for today the Gda bindings to Mono doesn't exist becouse a *bug* in
GDA before 1.2.x series; but for today GDA and GNOME-DB has be powered
with GValue instead of GdaValue (that couses the that *bug*), this is
a development version toward the 2.0 release, now I thing could work
but I have a lot of issues to make test it:
GDA#:
- In the code generated by GTK#, doesn't generate a init function for
GDA (gda_init), then you can't use the library (like in GLib), now
then I copied a Aplication.cs file from Gnome-Db# that implements it,
and modify the MakeFile.am to include in the DLL used by MonoDevelop,
now I have this function and can init
- After that I need to Run the main loop (like GTK) to manage GDA's
GObject events and do my program work in a function called as an
argument of the Run function, the function created by codegenerator is
this:
Gda.Main.Run(Gda.InitFunc init_func)
and InitFunc is defined as:
namespace Gda {
using System;
public delegate void InitFunc();
}
Does any one could help me about how do I define a custum InitFunc to
make my program run *inside* the main loop and how to pass it as an
argument to Gda.InitFunc?
In the Gda documentation, you call a init function in order to run
your program with a correctly initated libgda.
GNOME-DB#:
- In CVS, the current gnomedb-sharp is broken becouse it doesn't
generated any code and ofcourse any DLL to use in MonoDevelope.
- I modifed some errors in MakeFile.am and configure.in, and now the
code is generated but the compiler sends the following messages:
generated/Form.cs(11,20): error CS8025: Parsing error
generated/Grid.cs(11,20): error CS8025: Parsing error
generated/Layout.cs(11,22): error CS8025: Parsing error
generated/Matrix.cs(11,22): error CS8025: Parsing error
generated/Server.cs(11,22): error CS8025: Parsing error
Does any one know what it means?
The code generated in (11,20) is (a coma ','):
#region Autogenerated code
public class Grid, GnomeDb.DataWidget {
~Grid()
{
Dispose();
}
(.)
--
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (entrámite, pero para los
cuates: LIBRE)
___
gnome-db-list mailing list
gnome-db-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-db-list
--
Rodrigo Moya [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] gendarme: nant build files
Why not use .net prebuild? It can generate nant, vs2003, vs2005, monodevelop, and sharpdevelop projects/solutions from a single xml definition. This cuts down maintenance of project files quite tremendously. It is here: http://sourceforge.net/projects/dnpb/ This can be used during tarball creation or deployment to generate all the necessary project files automatically. Cheers! Curtis. On Monday 28 August 2006 14:39, Sebastien Pouliot wrote: Hello Christian, On Mon, 2006-08-28 at 23:13 +0200, Christian Birkl wrote: Since i'm a windows user (I don't believe I've said this loud) it is really hard for me to run the Makefile based build. Using the Makefile should work using cygwin (and I can't believe I'm suggesting cygwin to someone ;-) Also MonoDevelop is just available for *nis (last time i checked) so no chance for us windows developers to build gendarme out of the box. I get your point with the outdating - but currently as a windows developer you just get the source and need to manually create either VS projects or nant build files. By providing at least nant build files one may easier begin patching gendarme than without. I understand this issue, which is why I'm open to a third build system. But, like I said, I don't have any NAnt knowledge myself so someone else needs to step up for it ;-) Why ? because once this is in SVN/tarballs people will expect it to be maintained (even if I write use at your own risk in the README). Since I'm not that involved in other projects - how do other handle this issue with build files? I suspect they each build their own project file (e.g. in VS.NET) and yes this is clearly inefficient. Now one of my computers is a WinXP box with VS.NET 2005, so I may take the time to create a VS.NET solution in the future as, somehow, it make sense test-wise and commit it into SVN (if there is demand for it). But I'm still open to a contributor-supported NAnt build ;-) Christian 2006/8/28, Sebastien Pouliot [EMAIL PROTECTED]: Hello Christian, On Mon, 2006-08-28 at 22:47 +0200, Christian Birkl wrote: Hello all, attached a NAnt build file for build and running gendarme. Two things bug me currently which should be corrected by someone who has more experiences with nant build files: We already have 2 build systems (Makefile and MonoDevelop) for Gendarme. I don't mind adding a third one, but I don't want to maintain it ;-) Will you maintain it ? (*) (*) which also means that it will get deleted if it gets outdated and not updated for a while (i.e. after I get angry few emails about it ;-) - Mono.Cecil location must be specified as property (a dynamic lookup in gac/pkg-config would be nice) - same with nunit.framework if you want to run the unit tests. I don't know much about NAnt myself. Maybe Gert could help you with this ? Thanks p.s. let fix those issues before committing the build file (as I *really* want running the unit tests to be as easy as possible). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 1.1.17 ASP.NET Problem
Hi, I did hold out some hope that 1.1.17 would address this, but it seems not. :( If you use Namespace=xx in an aspx file, the mono asp.net parser expects an Assembly attribute to accompany it. With ASP.NET 2.0 this isn't required as code gets automagically compiled. This problem is currently stopping people wanting to run ASP.NET 2.0 code on mono. I wouldn't mind taking a look at fixing / developing this myself, but could do with some direction as to whether it's already being worked on. I know I've posted this problem before, but I can't seem to get any feedback on it. Can someone point me in the right direction? Thanks, Nick H ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
On Wed, 2006-08-30 at 10:20 +0100, Ben O'Steen wrote: when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. Whilst I haven't put an awful lot of thought into it, can there be a middle ground between 'ActiveX'-style browser apps and install-only apps? Yes. It's called ClickOnce deployment, requires Code Access Security, and won't be happening with Mono anytime before 2.0 (iirc). Also, it should be noted that .NET 1.0 allowed you to use SWF components as if they were ActiveX controls. I forget the details, but it only required Internet Explorer and a .NET 1.0+ installation on the client. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
On Tue, 2006-08-29 at 23:12 -0700, Valient Gough wrote: I've responded separately to Jon because I find his comments inflammatory. The only inflammatory bit was saying that I didn't like the SULF API. Which is about as inflammatory as saying Java collections suck (no language integration like System.Array integration System.Collections.IList), that System.Windows.Forms sucks, and that System.Diagnostics.EventLog sucks... The SULF project you reference predates the FUSE low-level API and even the latest couple kernel interface revisions. You could have found out about much newer code, and perhaps learned something about FUSE itself through a number of routes: As I asked in your separate message, *where* is this new SULF you reference? Furthermore, the SULF project I referenced makes use of the FUSE low-level API, at least that's what the ChangeLog and associated web site says The Fuse.dll library communicates with the FUSE kernel module, which would be the low-level FUSE API... 1. ask about the state of SULF. I would not have recommended starting with this defunct project, nor recommended referencing it as an alternative. The SULF site I referenced (http://arg0.net/users/vgough/sulf/) is the top-most linked site at the time I was searching. The SULF site I referenced is *still* the site listed in the FUSE Wiki: http://fuse.sourceforge.net/wiki/index.php/LanguageBindings Short of emailing you, I have no idea how I was supposed to find anything more recent, especially since these older sites, which presumably you still control, could have been updated to at least say this has been deprecated, please see the newer library _here_. BTW, this would *still* be a good idea. 3. search this Mono list for FUSE related announcements Searching my multi-year mono-list history for all messages with FUSE in the subject brings up: Re: [Mono-list] mod_mono MAKE confused on Apache version - obvious match for fuse as a substring, not relevant [Mono-list] ANN: Linux filesystems in C# (FUSE wrapper) - Dated May 12, 2005, by Valient Gough [EMAIL PROTECTED] - References http://pobox.com/~vgough/sulf - ...which redirects to http://arg0.net/users/vgough/sulf/ A *new* search (this morning) also brings up fusewrapper, http://arg0.net/wiki/fusewrapper, so I assume this is the newer library BTW, I see no messages with fusewrapper in the subject on either mono-list or mono-devel-list. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
On Wed, 2006-08-30 at 10:20 +0100, Ben O'Steen wrote: On Wed, August 30, 2006 09:58, ted leslie wrote: [snip] when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. Whilst I haven't put an awful lot of thought into it, can there be a middle ground between 'ActiveX'-style browser apps and install-only apps? For example, instead of installing an app, or allowing ActiveX-Mono for want of a better term, you might add a decrypting (public) key yikes to your keyring for the application you wish to run. The 'add key' dialog might resemble the pop-up you will see if you try to access a secure website, whose keys were not created by a central certification authority. This would hopefully allow applications encrypted with the correct private key yikes (again) For the record, you encrypt with a public key, not a private key. But you're probably talking about signature, not encryption (which is done with a private key). Couldn't resist ;-) Sebastien to run, and only those applications. Any others will be blocked by default. (To be honest, I'd be happy if all browser plugins worked in this way, flash especially. Thank you, FlashBlock.) This could be backed up, by limiting the Mono runtime which runs embedded in the browser, to 'sand-box' the application. However, I can only see this being useful in a corporate setting, with many people hot-desking or working from home, yet needing to access applications in the same environment, wherever they are, and without really installing a number of applications beforehand. Even then, there are probably better methods to achieve the same end result. I have been involved with many projects, and the clients always have the same needs. The audience goes to a web site, and you want to make your sale QUICK (or viral growth), say its a podcast client, a community collaboration tool, casino games, whatever, and the clients don't want to hear about a install executable, or a pokey asp.net sol'n, they want, when i boils down to it, an active X plugin (vb, c, c++ depending on needs) (or Java), and it just runs right there, no fuss no muss. Programmers don't think twice about installing a gtk app, 99+% of web users will not touch it with a ten foot pole. They will move on to the next casino, or community collaboration tool that just works right there, and yes many times now, you can find it to be flash, but lets not even go there and discuss the use of flash. I am just saying, it would be nice if Mono answered everyones needs (w.r.t the general places that you deploy programs - i.e. stand alone apps, ajax, asp.net, scripts/command line, and lastly browser plugins ), and filled this rather HUGE void (all be it a particularly commercial one). -tl On Wed, 2006-08-30 at 08:11 +0100, damien churchill wrote: __ From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then it’s easy enough just to make a gui for both web and desktop using asp/gtk whatever. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and
Re: [Mono-dev] gendarme: nant build files
Hey, It's funny how many build system suggestions you can get. A few more days and we will have more (possible) build system than rules for gendarme ;-) However it's a little sad when I compare this number with the offers to maintaining (versus just naming a tool, or dropping a patch) the new build system(s) :-( Now I can't image what the email would have looked like if I had said that I wasn't open to a third *contributor-maintained* build system... ;-) Sebastien p.s. Nothing personal Curtis, I'm just realigning the thread ;-) On Tue, 2006-08-29 at 01:02 -0700, Curtis Wensley wrote: Why not use .net prebuild? It can generate nant, vs2003, vs2005, monodevelop, and sharpdevelop projects/solutions from a single xml definition. This cuts down maintenance of project files quite tremendously. It is here: http://sourceforge.net/projects/dnpb/ This can be used during tarball creation or deployment to generate all the necessary project files automatically. Cheers! Curtis. On Monday 28 August 2006 14:39, Sebastien Pouliot wrote: Hello Christian, On Mon, 2006-08-28 at 23:13 +0200, Christian Birkl wrote: Since i'm a windows user (I don't believe I've said this loud) it is really hard for me to run the Makefile based build. Using the Makefile should work using cygwin (and I can't believe I'm suggesting cygwin to someone ;-) Also MonoDevelop is just available for *nis (last time i checked) so no chance for us windows developers to build gendarme out of the box. I get your point with the outdating - but currently as a windows developer you just get the source and need to manually create either VS projects or nant build files. By providing at least nant build files one may easier begin patching gendarme than without. I understand this issue, which is why I'm open to a third build system. But, like I said, I don't have any NAnt knowledge myself so someone else needs to step up for it ;-) Why ? because once this is in SVN/tarballs people will expect it to be maintained (even if I write use at your own risk in the README). Since I'm not that involved in other projects - how do other handle this issue with build files? I suspect they each build their own project file (e.g. in VS.NET) and yes this is clearly inefficient. Now one of my computers is a WinXP box with VS.NET 2005, so I may take the time to create a VS.NET solution in the future as, somehow, it make sense test-wise and commit it into SVN (if there is demand for it). But I'm still open to a contributor-supported NAnt build ;-) Christian 2006/8/28, Sebastien Pouliot [EMAIL PROTECTED]: Hello Christian, On Mon, 2006-08-28 at 22:47 +0200, Christian Birkl wrote: Hello all, attached a NAnt build file for build and running gendarme. Two things bug me currently which should be corrected by someone who has more experiences with nant build files: We already have 2 build systems (Makefile and MonoDevelop) for Gendarme. I don't mind adding a third one, but I don't want to maintain it ;-) Will you maintain it ? (*) (*) which also means that it will get deleted if it gets outdated and not updated for a while (i.e. after I get angry few emails about it ;-) - Mono.Cecil location must be specified as property (a dynamic lookup in gac/pkg-config would be nice) - same with nunit.framework if you want to run the unit tests. I don't know much about NAnt myself. Maybe Gert could help you with this ? Thanks p.s. let fix those issues before committing the build file (as I *really* want running the unit tests to be as easy as possible). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] FireFox plugin/ClickOnce was: Mono 1.1.17 has been released.
Hello Ted, On Wed, 2006-08-30 at 00:44 -0400, ted leslie wrote: ... write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Yes, this feature would be a nice one and, as Jon said in another email, ClickOnce [1] would too be a nice feature. And I can quickly think, even without caffeine, about a few more ;-) Unfortunately not having this is a huge barrier to some people adopting mono. and while it may be a huge barrier to some people [2] I definitively don't think this is a *huge* barrier in the general (current or would be) community. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. Let me rephrase this the way I see it: Providing this would put Mono on par with Java and IE/.NET and likely requires many more contributors on board, making Mono grow in a new direction. Feel free to disagree as this is only my humble opinion ;-) Don't misunderstand me, I *want* this, I even want it *now* (if wishing helps ;-) but I don't think it will attract many more contributors (!= users) or make Mono grow much faster. Still I like your enthusiasm :) [1] A full implementation CAS isn't a hard requirement to both features. Applying digital signatures and limiting execution to FullTrust|Nothing (i.e. no execution) would be a limited but valid (and useful) implementation (although I personally prefer the full/complete one ;-) [2] Those people are invited to contribute, directly or indirectly, to Mono. Alternatively they should speak louder when similar discussions happens on the mailing-list. -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Jonathan Pryor wrote: On Wed, 2006-08-30 at 10:20 +0100, Ben O'Steen wrote: when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. Whilst I haven't put an awful lot of thought into it, can there be a middle ground between 'ActiveX'-style browser apps and install-only apps? Yes. It's called ClickOnce deployment, requires Code Access Security, and won't be happening with Mono anytime before 2.0 (iirc). Also, it should be noted that .NET 1.0 allowed you to use SWF components as if they were ActiveX controls. I forget the details, but it only required Internet Explorer and a .NET 1.0+ installation on the client. Not only as if they were ActiveX controls. MS.NET's S.W.F.Controls are in fact ActiveX controls. They implement the required COM interfaces and are embeddable by several ActiveX containers (IE, MFC, etc.). The only difference to plain ActiveX controls is the new embedding host of the Internet Explorer. The host knows about MS.NET, its type activation, the CAS, and it is apparently more secure than ActiveX alone (I hope so ;-). About Mono's plugin: w/out a working CAS it's grossly negligent to even think about an implementation that allows the execution of assemblies from untrusted sources. Even if they were signed with God's own key, they still were insecure to execute. Let's not beat this dead horse again. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
On Wed, 2006-08-30 at 14:45 +0200, Robert Jordan wrote: About Mono's plugin: w/out a working CAS it's grossly negligent to even think about an implementation that allows the execution of assemblies from untrusted sources. Even if they were signed with God's own key, they still were insecure to execute. Let's not beat this dead horse again. He's dead Jim... huh I meant, it's not dead yet Robert ;-) Seriously there are, at least, three reasons to implement this. First, divide and conquer. It can be done in parallel with the CAS implementation (and related tasks). There seems to be little to gain from having it without CAS, however there's also little gain in completing CAS if there's no applications that can take advantage of it. Second, there are scenarios where FullTrust|Nothing is a valid choice. In fact this is what people do when manually downloading and executing any application (mono or not). So it all comes down to the untrusted source and, like any kind of application, this isn't a problem for everyone. E.g. Company A deploys FireFox (on top of Linux, of course ;-) and a mono-plugin configured to accept signed applications (i.e. assemblies) from Company A only. In this case this is an (non-existing) technological choice to deploy corporate applications yet it totally avoid the untrusted source problem. Third, this could be the idea of fun to somebody and I feel obligated to encourage such individuals ;-) -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Sebastien Pouliot wrote: On Wed, 2006-08-30 at 14:45 +0200, Robert Jordan wrote: About Mono's plugin: w/out a working CAS it's grossly negligent to even think about an implementation that allows the execution of assemblies from untrusted sources. Even if they were signed with God's own key, they still were insecure to execute. Let's not beat this dead horse again. He's dead Jim... huh I meant, it's not dead yet Robert ;-) Seriously there are, at least, three reasons to implement this. First, divide and conquer. It can be done in parallel with the CAS implementation (and related tasks). There seems to be little to gain from having it without CAS, however there's also little gain in completing CAS if there's no applications that can take advantage of it. Sorry, I exaggerated a little bit. Of course this could be done in parallel. Second, there are scenarios where FullTrust|Nothing is a valid choice. Indeed, but since we were speaking about a generic browser plugin, low trust is rather the usual trust level. See JavaScript, Java Plugin, Flash. Company A deploys FireFox (on top of Linux, of course ;-) and a mono-plugin configured to accept signed applications (i.e. assemblies) from Company A only. In this case this is an (non-existing) technological choice to deploy corporate applications yet it totally avoid the untrusted source problem. Ok, that's a subset of the CAS. Third, this could be the idea of fun to somebody and I feel obligated to encourage such individuals ;-) Of course. I didn't intend to yell stop energy :-) Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Hello, You should take note that mono-service based program doesn't work with this version... As I pointed out in the bug you filed, am unable to reproduce the problem; Please update the bug. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 ASP.NET Problem
Hello, This problem is currently stopping people wanting to run ASP.NET 2.0 code on mono. Please file a bug report. This problem is stopping ASP.NET 2.0 users, but this is not the only problem that will stop them, there are plenty more. I wouldn't mind taking a look at fixing / developing this myself, but could do with some direction as to whether it's already being worked on. Some work is being done by the Mainsoft guys, to keep an eye, you might want to read their patches. I know I've posted this problem before, but I can't seem to get any feedback on it. Can someone point me in the right direction? Download Mono, make sure you can build it, and then start looking at mcs/class/System.Web for the failure/limitation, fix the bug, then submit a patch. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Le mercredi 30 aot 2006 11:17 -0400, Miguel de Icaza a crit: Hello, You should take note that mono-service based program doesn't work with this version... As I pointed out in the bug you filed, am unable to reproduce the problem; Please update the bug. I've talk with Robert Jordan, and he doesn't understant why you can't reproduce the bug... He can reproduce the bug, and we've find the solution, he's making a patch in order to place mono-service.exe into the GAC (like XSP) ___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
Re: [Mono-dev] Mono 1.1.17 has been released.
Hubert FONGARNAND wrote: I've talk with Robert Jordan, and he doesn't understant why you can't reproduce the bug... He can reproduce the bug, and we've find the solution, he's making a patch in order to place mono-service.exe into the GAC (like XSP) I've made an addendum to that bug report. I think it should be possible to avoid installing everything to the GAC by making liberal use of codeBase declarations in the machine.config file instead. Of course, I guess it's six one way, half a dozen the other; either way, you still have to sign the assembly. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gendarme: nant build files
Hi Sebastien, It's funny how many build system suggestions you can get. A few more days and we will have more (possible) build system than rules for gendarme ;-) I sympathize. NUnit has three different builds: VS2003, VS2005 and NAnt. I'm constantly forgetting to update one of them. Jamie is working on an MsBuild option, which may or may not end up replacing the VS options. People keep asking for other things, but darned few of them offer to actually do the work. OTOH, Curtis seems to be suggesting that the question needs to be reformulated... Why not have a single source from which different builds can be created? I have no idea whether .net prebuild would help me or just give me a fifth build option, but it's intriguing enough an idea that I plan to take a look. Of course, the best of both worlds - for eithe of us - would be for someone to actually create the solution and contribute it. :-) Charlie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
Trimmed the CC list to only include mono-devel-list.
On 08/29/06 Jonathan Pryor wrote:
Once I started writing Mono.Fuse, I discovered a good reason to avoid
Mono.Posix: it's currently impossible to use from outside of Mono.
I figured this would be a good opportunity to rectify that, making it
easier for additional libraries to build upon the Mono.Posix
infrastructure.
[...]
The biggest problem with the mono module is that no headers are
installed, making it difficult to make use of libMonoPosixHelper.so.
This is for a good reason. libMonoPosixHelper.so is an internal
implementation detail, it is not a good library to export for a million
reasons and no header should be installed for it. It would be a
compatibility nightmare.
Changes:
- Modify `configure' to generate a mono-config.h file, installed as
$libdir/mono/include/mono-config.h. (Basic idea borrowed from
GLib's $libdir/glib-2.0/include/glibconfig.h).
- Add a mono-posix-helper.pc file
- Install the files $includedir/mono/posix/helper.h and
$includedir/mono/posix/map.h.
map.h is the current map.h file generated by make-map.exe, with some
major additions (detailed in the mcs section).
helper.h is the main include file, which includes map.h and declares
all types/functions which cannot be generated by make-map.exe.
mono-config.h is necessary because it needs to contain
platform-specific macros. In particular, Linux needs:
Sorry, but there is no way to grab the mono-config.h name for this.
mcs:
---
There are two major changes:
* The addition of one public attributes to the API:
// targets Class, Delegate, Enum, Field, Struct
class Mono.Unix.Native.MapAttribute {
public MapAttribute ();
public MapAttribute (string nativeType);
public string NativeType {get;}
public string NativeSymbolPrefix {get; set;}
}
* A major revamp to make-map.exe
I don't think these changes are appropriate for mcs/. The Map attribute
and make-map.exe are hacks that are tolerated only because they are used
only internally. Exposing them for public use would only create
comaptibility issues: they are not tools that can be maintained with the
needed API and ABI stability required by a mono release.
If people need them, they can always make a copy and include them in their
own tarball outside of the mcs module.
1. What Mono seems to do, with the GAC in $prefix/lib no matter
what the architecture:
/usr/lib/mono-fuse/Mono.Fuse.dll
/usr/lib64/libMonoFuseHelper.so
2. Be consistent, and toss everything in @libdir@:
/usr/lib64/mono-fuse/Mono.Fuse.dll
/usr/lib64/libMonoFuseHelper.so
We should very likely do this.
Thanks.
lupus
--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FireFox plugin/ClickOnce was: Mono 1.1.17 has been released.
Hello Michael, On Wed, 2006-08-30 at 11:31 -0500, Michael Schurter wrote: Sebastien Pouliot wrote: Hello Ted, On Wed, 2006-08-30 at 00:44 -0400, ted leslie wrote: ... write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Yes, this feature would be a nice one and, as Jon said in another email, ClickOnce [1] would too be a nice feature. And I can quickly think, even without caffeine, about a few more ;-) I'm sorry if you've already been over this before: but does anyone actually use ClickOnce? I had never seen it in the wild but fx 2.0 is still quite young (wrt to design/development/deployment of new applications). Anyway I always suspected it's main goal (or target audience) was for application deployment on intranet or, perhaps, an extranet between highly trusted partners. The only time I've even seen it mentioned (outside of this mailing list) was on Microsoft's site. I was forced to use it to download some application, and I remember having so much trouble trying to get ClickOnce to work (even with IE on Windows) that I eventually gave up. I understand how in-browser apps (like Flash ActiveX) are appealing, but what is the use case for ClickOnce over the standard Click Twice it takes to run a normal application? (First click download, second click to run.) I recall two: The first is CAS. Click Twice == Full Trust (i.e. like all local application), while ClickOnce application can have their own restrictions. The second is automatic updates (and policies around that). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 ASP.NET Problem
Visual Studio.net is an IDE which automatically adds references to many assemblies in the project file. Mono/XSP/mcs are not an IDE; they are the CLI runtime, web server, and C# compiler. This can be compared to Microsoft's CLR/IIS/csc. Have you tried building your ASP.NET projects without the help of Visual Studio.net? Another words, build and run everything from the commmand-line? You can try it. It will help you learn a lot of what's going on behind-the-scenes. Visual Studio.net does a lot of things for you. Mono's IDE would be MonoDevelop or SharpDevelop or XDevelop. There maybe even an Visual Studio.net add-in that let's you build and run on Mono. --- Nick Hoddinott [EMAIL PROTECTED] wrote: Hi, I did hold out some hope that 1.1.17 would address this, but it seems not. :( If you use Namespace=xx in an aspx file, the mono asp.net parser expects an Assembly attribute to accompany it. With ASP.NET 2.0 this isn't required as code gets automagically compiled. This problem is currently stopping people wanting to run ASP.NET 2.0 code on mono. I wouldn't mind taking a look at fixing / developing this myself, but could do with some direction as to whether it's already being worked on. I know I've posted this problem before, but I can't seem to get any feedback on it. Can someone point me in the right direction? Thanks, Nick H ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gendarme: nant build files
Hello Charlie, On Wed, 2006-08-30 at 09:03 -0700, Charlie Poole wrote: Hi Sebastien, It's funny how many build system suggestions you can get. A few more days and we will have more (possible) build system than rules for gendarme ;-) I sympathize. NUnit has three different builds: VS2003, VS2005 and NAnt. I'm constantly forgetting to update one of them. Jamie is working on an MsBuild option, which may or may not end up replacing the VS options. People keep asking for other things, but darned few of them offer to actually do the work. OTOH, Curtis seems to be suggesting that the question needs to be reformulated... Why not have a single source from which different builds can be created? True, it does sounds useful. At least if we can commit the Makefile into SVN (along with the prebuild files) and not require an additional dependency on yet another tool. However it doesn't give me any knowledge about it or how to use it. I already have very limited knowledge about makefiles and learning a new build-tool isn't really a top priority at the moment. I have no idea whether .net prebuild would help me or just give me a fifth build option, but it's intriguing enough an idea that I plan to take a look. Please share your findings :-) Learning by example is much easier ;-) Of course, the best of both worlds - for eithe of us - would be for someone to actually create the solution and contribute it. :-) *and* maintain it, or ensure it's easily maintainable by others. But I see your (and Curtis) point so here's a little change: I'm open to a third, contributor-maintained, build system for Gendarme *or* a new build system that will: (a) replace the existing ones (Makefile and MonoDevelop); (b) won't require a new dependency for Linux end users, which may compile Gendarme from source or SVN; (c) will be simpler/faster to maintain (for me) as the two current ones (which is, right now, pretty simple and fast). -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gendarme: nant build files
Hi Sebastien, I have no idea whether .net prebuild would help me or just give me a fifth build option, but it's intriguing enough an idea that I plan to take a look. Please share your findings :-) Learning by example is much easier ;-) I will. Now I only have to find the time to do it. :-) Of course, the best of both worlds - for eithe of us - would be for someone to actually create the solution and contribute it. :-) *and* maintain it, or ensure it's easily maintainable by others. Yes... one always hopes that a contribution comes with the contributor attached, but it isn't always so. But I see your (and Curtis) point so here's a little change: I'm open to a third, contributor-maintained, build system for Gendarme *or* a new build system that will: (a) replace the existing ones (Makefile and MonoDevelop); (b) won't require a new dependency for Linux end users, which may compile Gendarme from source or SVN; (c) will be simpler/faster to maintain (for me) as the two current ones (which is, right now, pretty simple and fast). This is a very useful discussion for me, since I'm trying to understand what changes are needed in order to begin distributing NUnit on an equal basis for both MS.Net and Mono. But that's getting off the topic of gendarme, so I'll save it for another thread. :-) Charlie -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Distributed Unit Testing
Hi Pablo, This looks pretty cool! Mono could probably use this, since there are so many test, and we (the NUnit team) would be interested to hear more about it as well. We're looking at similar things, but your ideas are welcome - and so are you and your code! Have you actually modified NUnit? Looking solely at the zips, because I'm a little pressed for time right now, it appears that you build on top of NUnit, rather than actually modifying it. If you are modifying it, I'm hoping you use some non-conflicting version number scheme, to avoid confusion. In fact, if you give out any modified assemblies, renaming them would probably be better, since it makes it obvious that there is a change. This may seem like a small thing, but if you have ever dealt with bug reports on an unidentified version of your code, you'll understand. One thing, since you're distributing nunit and log4net, you should put the the license files from each product into your zips. If you are actually modifying NUnit, there's a notice of attribution that you're supposed to include as well - see the license. I have downloaded the source and I'll give it a try in my next idle moment. :-) Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of pablosantosluac Sent: Wednesday, August 30, 2006 9:21 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Distributed Unit Testing Hi, We needed to test our software on a distributed scenario. We have developed an small extension to NUnit. We think maybe somebody can find it interesting, so we have published the source code, an example and a short description at our website. You can find it at pnunit.codicesoftware.com. Hope you find it interesting. pablo ___ 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] gendarme: request for globalization
Hi all,
after talking to Sebastien about another issue I'd like to see changed the topic globalization came up. I think I found a solution which may bring globalization to gendarme with just a few changes and also fixing the other issue I had :-).
The attached patch is an example translation which supportsrule information for Gendarme.Rules.Portability in english and german. The design follows using System.ResourceManager and the commonly used
MyType.CULTURE.resx resources. Each rule will get it's own resx file which stores its localized strings in this format:
Key: Value
Rule.Name: Name
Rule.Problem: Problem
Rule.Solution: Solution
Rule.Uri: Uri
Msg.MyFirstKey: MyFirstTest
Msg.MySecondKey: MySecondKey
In order to fit this into the gendarme framework I've extended IRule with a property named ResourceManager ResourceManager { get; } which every rule needs to implement. This returns the resource manager for this rule.
Since my knowledge about globalization is very limited I googled a bit around to find out what other applications do. It seems using resx files is a best practice (according to MS). But I'd like to here how other mono projects handle this issue and what might fit best into gendarme's framework.
Christian
Index: framework/IRule.cs
===
--- framework/IRule.cs (revision 64515)
+++ framework/IRule.cs (working copy)
@@ -28,11 +28,14 @@
using System;
using System.Collections;
+using System.Resources;
+
using Mono.Cecil;
namespace Gendarme.Framework {
public interface IRule {
+ ResourceManager ResourceManager { get; }
}
public interface IAssemblyRule : IRule {
Index: framework/RuleInformationManager.cs
===
--- framework/RuleInformationManager.cs (revision 64515)
+++ framework/RuleInformationManager.cs (working copy)
@@ -30,13 +30,15 @@
using System.IO;
using System.Collections;
using System.Xml;
+using System.Resources;
+using System.Reflection;
namespace Gendarme.Framework {
public class RuleInformationManager {
- private static Hashtable rules;
- private static Hashtable infos;
+ private static Hashtable rules = new Hashtable();
+ private static Hashtable infos = new Hashtable();
static RuleInformationManager ()
{
@@ -46,99 +48,40 @@
{
}
- static private XmlDocument LoadAssemblyRulesInformations
(string filename)
+ static public RuleInformation GetRuleInformation (IRule rule)
{
- XmlDocument doc = null;
- if (rules == null) {
- rules = new Hashtable ();
- } else {
- doc = (XmlDocument) rules[filename];
- }
+ if (rule == null)
+ throw new ArgumentNullException(rule);
- if (doc == null) {
- doc = new XmlDocument ();
- if (File.Exists (filename)) {
- doc.Load (filename);
- }
- rules[filename] = doc;
- }
- return doc;
- }
+ Type type = rule.GetType();
- static private string GetAttribute (XmlElement xel, string name)
- {
- XmlAttribute xa = xel.Attributes[name];
- if (xa == null)
- return String.Empty;
- return xa.Value;
- }
+ RuleInformation ri = (infos[type.FullName] as
RuleInformation);
+ if (ri != null)
+ return ri;
- static private string GetSubElement (XmlElement xel, string
name)
- {
- if (xel.ChildNodes.Count 0) {
- foreach (XmlElement child in xel.ChildNodes) {
- if (child.Name == name)
- return child.InnerText;
- }
+ ResourceManager rm = rule.ResourceManager;
+ if (rm == null) {
+ throw new NullReferenceException (string.Format
+ (The rule {0} doesn't supply a
resource manager., type.FullName));
}
- return String.Empty;
- }
- static private RuleInformation LoadRuleInformations
(XmlDocument doc, string name)
- {
-
Re: [Mono-dev] Help with garbled email headers when adding attachment
Hi Vladimir, Can you give us more details about why are telling the headers go wild? From the little you show, the headers look normal for an email with attachments. Such emails must be of the multipart variety, and each attachment has it's own headers prepended to them and are separated from each other by the boundary lines. Some email clients send the original text in the main-block, but some others do the alternate block, as the one your example shows. So please be more specific, for instance: What email-client are you trying to read the sent messages? Because it may be the email-client who is failling to decode a valid message..., And so you can try to use other email-clients (web like gmail or desktop like evolution) to compare... :) On 8/29/06, Vladimir Lushnikov [EMAIL PROTECTED] wrote: Hi, I have looked at trunk implementation and it seems that it's marked as a todo item. However, it has been marked over 5 months as that, so re-sending to mono-devel. If I knew the standard I would be happy to implement the functionality in mono, but I wouldn't be using the classes if I did that. Could someone help me out please? Thank you, Vladimir Lushnikov On 8/28/06, Vladimir Lushnikov [EMAIL PROTECTED] wrote: Hi, I'm trying to send an email with mono using smtp. If I send one normally, I get the following: --- Subject: Mail test MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Message-Id: . Date: Mon, 28 Aug 2006 15:33:16 -0700 (PDT) This is a mail test br /This is a newline --- However, as soon as I add an attachment, headers go wild: ---Subject: Hotbackup r22 MIME-Version: 1.0 Content-Type: multipart/mixed; charset=us-ascii; boundary=--boundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014 Message-Id: . Date: Mon, 28 Aug 2006 15:43:44 -0700 (PDT) boundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014 content-type: multipart/alternative content-transfer-encoding: quoted-printable This is a mail test br /This is a newline boundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014 content-type: multipart/alternative content-transfer-encoding: base64 SGVsbG8sIHdvcmxkLi4uCg== --- My code is: // Create the file attachment for this e-mail message. Attachment data = new Attachment(file.FullName, MediaTypeNames.Application.Octet); // Add time stamp information for the file. ContentDisposition disposition = data.ContentDisposition; disposition.CreationDate = File.GetCreationTime(file.FullName ); disposition.ModificationDate = File.GetLastWriteTime(file.FullName); disposition.ReadDate = File.GetLastAccessTime(file.FullName); mail.Attachments.Add(data); Where mail is MailMessage object, file is a FileInfo object. I am using gmcs and trunk build (from yesterday). All help would be appreciated. Regards, Vladimir Lushnikov -- Vladimir Vlad# Lushnikov http://www.vladsharp.com - The Crests of Reason - Journey to a better object... -- Vladimir Vlad# Lushnikov http://www.vladsharp.com - The Crests of Reason - Journey to a better object... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Hi! Interesting discussion; see inline, Sebastien Pouliot wrote: Second, there are scenarios where FullTrust|Nothing is a valid choice. In fact this is what people do when manually downloading and executing any application (mono or not). So it all comes down to the untrusted source and, like any kind of application, this isn't a problem for everyone. E.g. Company A deploys FireFox (on top of Linux, of course ;-) and a mono-plugin configured to accept signed applications (i.e. assemblies) from Company A only. In this case this is an (non-existing) technological choice to deploy corporate applications yet it totally avoid the untrusted source problem. Actually, if this example could be achieved, it would very possible that, in my particular case, my company be interested in it for the Linux-side of the ClickOnce technologies we are deploying, so I guess I am not a rare case and many other people would benefit from it too. BTW: I suppose you already know about this extension [1]. Has anyone tried it out? What would prevent it for working with Mono (either in Win32 or Linux)? Regards, Andrés [ knocte ] [1] http://www.softwarepunk.com/ffclickonce/ -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Distributed Unit Testing
Hi, This looks pretty cool! Mono could probably use this, since there are so many test, and we (the NUnit team) would be interested to hear more about it as well. We're looking at similar things, but your ideas are welcome - and so are you and your code! Please, feel free to use it... :-) Have you actually modified NUnit? Looking solely at the zips, because I'm a little pressed for time right now, it appears that you build on top of NUnit, rather than actually modifying it. Well, now that you say, if I remember correctly I made an small modification in order to be able to launch an individual test... But I don't really remember! (It was last January). I will check it tomorrow and let you know. But yes, when I said modified I should have said extended or something else... If you are modifying it, I'm hoping you use some non-conflicting version number scheme, to avoid confusion. In fact, if you give out any modified assemblies, renaming them would probably be better, since it makes it obvious that there is a change. This may seem like a small thing, but if you have ever dealt with bug reports on an unidentified version of your code, you'll understand. Yes, yes. You're right. I will check and let you know. One thing, since you're distributing nunit and log4net, you should put the the license files from each product into your zips. If you are actually modifying NUnit, there's a notice of attribution that you're supposed to include as well - see the license. Right. Good to know. Sorry. Well, I think pnunit will run on top of standard NUnit. If not I will let you know the changes, but as far as I remember we are just building on top. I will include the license files of both products on the zip files. Sorry again... :-( I have downloaded the source and I'll give it a try in my next idle moment. :-) Ok, let me know. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of pablosantosluac Sent: Wednesday, August 30, 2006 9:21 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Distributed Unit Testing Hi, We needed to test our software on a distributed scenario. We have developed an small extension to NUnit. We think maybe somebody can find it interesting, so we have published the source code, an example and a short description at our website. You can find it at pnunit.codicesoftware.com. Hope you find it interesting. pablo ___ 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] Distributed Unit Testing
licenses included in zip files: license.rft for NUnit and license.txt for log4net - Original Message - From: Charlie Poole [EMAIL PROTECTED] To: 'pablosantosluac' [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Sent: Wednesday, August 30, 2006 9:30 PM Subject: RE: [Mono-dev] Distributed Unit Testing Hi Pablo, This looks pretty cool! Mono could probably use this, since there are so many test, and we (the NUnit team) would be interested to hear more about it as well. We're looking at similar things, but your ideas are welcome - and so are you and your code! Have you actually modified NUnit? Looking solely at the zips, because I'm a little pressed for time right now, it appears that you build on top of NUnit, rather than actually modifying it. If you are modifying it, I'm hoping you use some non-conflicting version number scheme, to avoid confusion. In fact, if you give out any modified assemblies, renaming them would probably be better, since it makes it obvious that there is a change. This may seem like a small thing, but if you have ever dealt with bug reports on an unidentified version of your code, you'll understand. One thing, since you're distributing nunit and log4net, you should put the the license files from each product into your zips. If you are actually modifying NUnit, there's a notice of attribution that you're supposed to include as well - see the license. I have downloaded the source and I'll give it a try in my next idle moment. :-) Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of pablosantosluac Sent: Wednesday, August 30, 2006 9:21 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Distributed Unit Testing Hi, We needed to test our software on a distributed scenario. We have developed an small extension to NUnit. We think maybe somebody can find it interesting, so we have published the source code, an example and a short description at our website. You can find it at pnunit.codicesoftware.com. Hope you find it interesting. pablo ___ 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] gendarme: request for globalization
Hello Christian, after talking to Sebastien about another issue I'd like to see changed the topic globalization came up. I think I found a solution which may bring globalization to gendarme with just a few changes and also fixing the other issue I had :-). The attached patch is an example translation which supports rule information for Gendarme.Rules.Portability in english and german. The design follows using System.ResourceManager and the commonly used MyType.CULTURE.resx resources. Each rule will get it's own resx file which stores its localized strings in this format: I appreciate the effort to get some internationalization setup in place, but this is something that we need to decide in a larger context. The files that you provided in XML seem way too bloated for what they are supposed to do, and I would rather go down the path of using something like GetText instead. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Hello Andrés, On Wed, 2006-08-30 at 22:46 +0200, Andrés G. Aragoneses [ knocte ] wrote: Hi! Interesting discussion; see inline, Sebastien Pouliot wrote: Second, there are scenarios where FullTrust|Nothing is a valid choice. In fact this is what people do when manually downloading and executing any application (mono or not). So it all comes down to the untrusted source and, like any kind of application, this isn't a problem for everyone. E.g. Company A deploys FireFox (on top of Linux, of course ;-) and a mono-plugin configured to accept signed applications (i.e. assemblies) from Company A only. In this case this is an (non-existing) technological choice to deploy corporate applications yet it totally avoid the untrusted source problem. Actually, if this example could be achieved, it would very possible that, in my particular case, my company be interested in it for the Linux-side of the ClickOnce technologies we are deploying, so I guess I am not a rare case and many other people would benefit from it too. Quite interesting! Can you elaborate more (publicly or privately) on your plans ? BTW: I suppose you already know about this extension [1]. Has anyone tried it out? First time I heard of it, but I'll definitively have a good look at it. What would prevent it for working with Mono (either in Win32 or Linux)? Win32: Mono hosting interfaces are different from MS ones. Linux: Hosting + other win32 calls. Regards, Andrés [ knocte ] [1] http://www.softwarepunk.com/ffclickonce/ -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patches
Hi, As I have been packaging apps for Fedora Extras, I seem to have gathered patch files so that the applications are properly architecture agnostic. Currently, I have patches for... boo ikvm monodebugger monodevelop monodoc xsp The alterations mean that on a native 64 bit box, libraries and dlls are correctly installed to /usr/lib64 instead of /usr/lib Is this the correct list to post them to? TTFN Paul -- Bist Du meine Mutter? - das leere kind signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
On Wed, 2006-08-30 at 18:07 +0200, Paolo Molaro wrote:
The biggest problem with the mono module is that no headers are
installed, making it difficult to make use of libMonoPosixHelper.so.
This is for a good reason. libMonoPosixHelper.so is an internal
implementation detail, it is not a good library to export for a million
reasons and no header should be installed for it. It would be a
compatibility nightmare.
I'm not entirely sure I see the compatibility nightmare. Nor do I see
the million reasons. The only reasons I can think of is that there
are some symbols which should be removed (e.g. the old Mono.Posix
namespace functions such as wifexited and helper_Mono_Posix_Stat).
Regardless, here's the scenario I'm trying to solve: MonoFuseHelper is a
C library which has functions which register with FUSE. The
MonoFuseHelper functions invoke delegates registered by Mono.Fuse.dll,
e.g.
/* Within MonoFuseHelper */
static int
mfh_getattr (const char *path, struct stat *stat)
{
/* invoke delegate registered by Mono.Fuse.dll */
return _mfh_get_private_data()-getattr (path,
what_to_pass_here?);
}
The question is this: what should MonoFuseHelper pass to Mono.Fuse.dll?
There are two answers:
(1) Translate the native types into the managed types within
MonoFuseHelper, then invoke the Mono.Fuse.dll callback:
/* stat(2) */
static int
mfh_getattr (const char *path, struct stat *stat)
{
struct Mono_Posix_Stat _stat;
Mono_Posix_ToStat (stat, _stat);
int r= _mfh_get_private_data()-getattr (path, _stat);
Mono_Posix_FromErrno (r, r);
return -r;
}
(The Errno translation negation is because FUSE methods need to return
-errno on error.)
Pro:
- Requires fewer P/Invoke transitions, as all type conversions are
done in native code before invoking managed code (calling into
MonoPosixHelper).
- More efficient (due to above).
Con:
- Requires that MonoPosixHelper headers be installed so that the
Mono.Posix types functions are accessible.
(2) Don't translate in native code, but just forward them to managed
code for translation within Mono.Fuse.dll:
/* stat(2) */
static int
mfh_getattr (const char *path, struct stat *stat)
{
return _mfh_get_private_data()-getattr (path, stat);
}
Managed code must then do everything:
private static int _OnGetFileAttributes (string path, IntPtr b)
{
Stat s;
NativeConvert.Copy (b, out s);
Errno e = OnGetFileAttributes (path, out s);
return - NativeConvert.FromErrno (e);
}
Pro:
- Doesn't require installing any headers for MonoPosixHelper.
Con:
- Requires more P/Invoke transitions.
- One P/Invoke transition to call NativeConvert.FromErrno
(done for each delegate invoked).
- One P/Invoke transition for each parameter that needs to
be converted (e.g. converting the IntPtr into a Stat, above).
- Requires adding several new methods to
Mono.Unix.Native.NativeConvert to copy structures between managed
and native (e.g. the NativeConvert.Copy() method used above).
I implemented solution (1) for efficiency reasons -- why invoke extra
P/Invoke calls when they can be avoided?
So I implemented (2) for comparison. The result: to copy a 1
byte file using `cat':
Average Copy Time
Solution 1: 4.8362s
Solution 2: 4.8613s
Since FUSE reads file contents in 4KB chunks, there is an average
overhead of .25us/call using (2).
So my efficiency concerns are likely overblown, and doing everything
from managed code will have acceptable performance.
mono-config.h is necessary because it needs to contain
platform-specific macros. In particular, Linux needs:
Sorry, but there is no way to grab the mono-config.h name for this.
I'm sorry, but I don't understand this comment.
There are two major changes:
* The addition of one public attributes to the API:
\\\
// targets Class, Delegate, Enum, Field, Struct
class Mono.Unix.Native.MapAttribute {
public MapAttribute ();
public MapAttribute (string nativeType);
public string NativeType {get;}
public string NativeSymbolPrefix {get; set;}
}
* A major revamp to make-map.exe
I don't think these changes are appropriate for mcs/. The Map attribute
and make-map.exe are hacks that are tolerated only because they are used
only internally. Exposing them for public use would only create
comaptibility issues: they are not tools that can be maintained with the
needed API and ABI stability required by a mono release.
I'm still not sure I see the compatibility issues.
Regardless, it sounds like you don't want
Re: [Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
So, let's say I want to develop a filesystem to be integrated with our
software: should I use SULF or should I wait for Mono.Fuse?
- Original Message -
From: Jonathan Pryor [EMAIL PROTECTED]
To: Paolo Molaro [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Sent: Thursday, August 31, 2006 3:51 AM
Subject: Re: [Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
On Wed, 2006-08-30 at 18:07 +0200, Paolo Molaro wrote:
The biggest problem with the mono module is that no headers are
installed, making it difficult to make use of libMonoPosixHelper.so.
This is for a good reason. libMonoPosixHelper.so is an internal
implementation detail, it is not a good library to export for a million
reasons and no header should be installed for it. It would be a
compatibility nightmare.
I'm not entirely sure I see the compatibility nightmare. Nor do I see
the million reasons. The only reasons I can think of is that there
are some symbols which should be removed (e.g. the old Mono.Posix
namespace functions such as wifexited and helper_Mono_Posix_Stat).
Regardless, here's the scenario I'm trying to solve: MonoFuseHelper is a
C library which has functions which register with FUSE. The
MonoFuseHelper functions invoke delegates registered by Mono.Fuse.dll,
e.g.
/* Within MonoFuseHelper */
static int
mfh_getattr (const char *path, struct stat *stat)
{
/* invoke delegate registered by Mono.Fuse.dll */
return _mfh_get_private_data()-getattr (path,
what_to_pass_here?);
}
The question is this: what should MonoFuseHelper pass to Mono.Fuse.dll?
There are two answers:
(1) Translate the native types into the managed types within
MonoFuseHelper, then invoke the Mono.Fuse.dll callback:
/* stat(2) */
static int
mfh_getattr (const char *path, struct stat *stat)
{
struct Mono_Posix_Stat _stat;
Mono_Posix_ToStat (stat, _stat);
int r= _mfh_get_private_data()-getattr (path, _stat);
Mono_Posix_FromErrno (r, r);
return -r;
}
(The Errno translation negation is because FUSE methods need to return
-errno on error.)
Pro:
- Requires fewer P/Invoke transitions, as all type conversions are
done in native code before invoking managed code (calling into
MonoPosixHelper).
- More efficient (due to above).
Con:
- Requires that MonoPosixHelper headers be installed so that the
Mono.Posix types functions are accessible.
(2) Don't translate in native code, but just forward them to managed
code for translation within Mono.Fuse.dll:
/* stat(2) */
static int
mfh_getattr (const char *path, struct stat *stat)
{
return _mfh_get_private_data()-getattr (path, stat);
}
Managed code must then do everything:
private static int _OnGetFileAttributes (string path, IntPtr b)
{
Stat s;
NativeConvert.Copy (b, out s);
Errno e = OnGetFileAttributes (path, out s);
return - NativeConvert.FromErrno (e);
}
Pro:
- Doesn't require installing any headers for MonoPosixHelper.
Con:
- Requires more P/Invoke transitions.
- One P/Invoke transition to call NativeConvert.FromErrno
(done for each delegate invoked).
- One P/Invoke transition for each parameter that needs to
be converted (e.g. converting the IntPtr into a Stat, above).
- Requires adding several new methods to
Mono.Unix.Native.NativeConvert to copy structures between managed
and native (e.g. the NativeConvert.Copy() method used above).
I implemented solution (1) for efficiency reasons -- why invoke extra
P/Invoke calls when they can be avoided?
So I implemented (2) for comparison. The result: to copy a 1
byte file using `cat':
Average Copy Time
Solution 1: 4.8362s
Solution 2: 4.8613s
Since FUSE reads file contents in 4KB chunks, there is an average
overhead of .25us/call using (2).
So my efficiency concerns are likely overblown, and doing everything
from managed code will have acceptable performance.
mono-config.h is necessary because it needs to contain
platform-specific macros. In particular, Linux needs:
Sorry, but there is no way to grab the mono-config.h name for this.
I'm sorry, but I don't understand this comment.
There are two major changes:
* The addition of one public attributes to the API:
\\\
// targets Class, Delegate, Enum, Field, Struct
class Mono.Unix.Native.MapAttribute {
public MapAttribute ();
public MapAttribute (string nativeType);
public string NativeType {get;}
public string NativeSymbolPrefix {get; set;}
}
* A major revamp to make-map.exe
I don't think these changes are appropriate for mcs/. The Map attribute
and make-map.exe are hacks that are tolerated only because they are used
only internally. Exposing them for public use would only create
comaptibility issues: they are not tools that can be maintained with the
needed API and ABI stability required by a mono release.
I'm still not sure I see the
Re: [Mono-dev] Mono 1.1.17 ASP.NET Problem
Daniel, How is this relevant to Nick's post? Visual Studio has nothing at all to do with the App_Code compilation that occurs in ASP.NET 2.0... I would say it is advisable to properly read someone's message before responding and making all kinds of assumptions. -- Thomas Johansen On 31/08/2006, at 3:23 AM, Daniel Morgan wrote: Visual Studio.net is an IDE which automatically adds references to many assemblies in the project file. Mono/XSP/mcs are not an IDE; they are the CLI runtime, web server, and C# compiler. This can be compared to Microsoft's CLR/IIS/csc. Have you tried building your ASP.NET projects without the help of Visual Studio.net? Another words, build and run everything from the commmand-line? You can try it. It will help you learn a lot of what's going on behind-the-scenes. Visual Studio.net does a lot of things for you. Mono's IDE would be MonoDevelop or SharpDevelop or XDevelop. There maybe even an Visual Studio.net add-in that let's you build and run on Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
I've responded separately to Jon because I find his comments inflammatory.
The SULF project you reference predates the FUSE low-level API and
even the latest couple kernel interface revisions. You could have
found out about much newer code, and perhaps learned something about
FUSE itself through a number of routes:
1. ask about the state of SULF. I would not have recommended starting
with this defunct project, nor recommended referencing it as an
alternative.
2. search FUSE mailing list for C# related announcements (and language
binding discussions in general)
3. search this Mono list for FUSE related announcements
regards,
Valient
On 8/29/06, Jonathan Pryor [EMAIL PROTECTED] wrote:
Mono.Fuse is a binding for the FUSE library, permitting user-space
file systems to be written in C#.
Why?
===
I read Robert Love's announcement of beaglefs, a FUSE program that
exposes Beagle searches as a filesystem. My first thought: Why
wasn't that done in C# (considering that the rest of Beagle is C#)?
What about SULF?
===
Stackable User-Level Filesystem, or SULF
(http://arg0.net/users/vgough/sulf/), is a pre-existing FUSE binding
in C#, started by Valient Gough in 2004.
Mono.Fuse has no relation to SULF, for two reasons:
1. It goes to great efforts to avoid a Mono.Posix.dll dependency,
duplicating Mono.Unix.Native.Stat (Fuse.Stat),
Mono.Unix.Native.Statvfs (Fuse.StatFS), and many methods from
Mono.Unix.Native.Syscall (Fuse.Wrapper).
2. I don't like the SULF API. (Not that I spent a great deal of
time looking at it, but what I did see I didn't like.)
3. SULF wraps the FUSE kernel-level interface, while Mono.Fuse
wraps the higher level libfuse C interface
I find (1) the most appalling, if only because I'm the Mono.Posix
maintainer and I'd like to see my work actually used. :-)
Once I started writing Mono.Fuse, I discovered a good reason to avoid
Mono.Posix: it's currently impossible to use from outside of Mono.
I figured this would be a good opportunity to rectify that, making it
easier for additional libraries to build upon the Mono.Posix
infrastructure.
Implementation:
==
Mono.Fuse requires patches to the mcs mono modules, changes which
need to be proposed (hence this email) and discussed.
mono:
The biggest problem with the mono module is that no headers are
installed, making it difficult to make use of libMonoPosixHelper.so.
Changes:
- Modify `configure' to generate a mono-config.h file, installed as
$libdir/mono/include/mono-config.h. (Basic idea borrowed from
GLib's $libdir/glib-2.0/include/glibconfig.h).
- Add a mono-posix-helper.pc file
- Install the files $includedir/mono/posix/helper.h and
$includedir/mono/posix/map.h.
map.h is the current map.h file generated by make-map.exe, with some
major additions (detailed in the mcs section).
helper.h is the main include file, which includes map.h and declares
all types/functions which cannot be generated by make-map.exe.
mono-config.h is necessary because it needs to contain
platform-specific macros. In particular, Linux needs:
int
Mono_Posix_ToStat (struct statvfs *to, struct Mono_Posix_Helper *to);
while OS X and *BSD need:
int
Mono_Posix_ToStat (struct statfs *to, struct Mono_Posix_Helper *to);
Note `struct statvfs' vs. `struct statfs'. The mono/posix/helper.h
header needs to paper over the difference, and thus needs to know
which type the platform prefers. helper.h thus looks like:
#ifdef MONO_HAVE_STATVFS
struct statvfs;
int Mono_Posix_ToStatvfs (struct statvfs *from,
struct Mono_Posix_Statvfs *to);
#endif
#ifdef MONO_HAVE_STATFS
struct statfs;
int Mono_Posix_ToStatvfs (struct statfs *from,
struct Mono_Posix_Statvfs *to);
#endif
One of MONO_HAVE_STATVFS or MONO_HAVE_STATFS would be defined in
mono-config.h.
mcs:
---
There are two major changes:
* The addition of one public attributes to the API:
// targets Class, Delegate, Enum, Field, Struct
class Mono.Unix.Native.MapAttribute {
public MapAttribute ();
public MapAttribute (string nativeType);
public string NativeType {get;}
public string NativeSymbolPrefix {get; set;}
}
* A major revamp to make-map.exe
The Map and MapHeader attributes are public so that make-map.exe can
use a publically exposed API for code generation purposes which can be
used by other libraries (Mono.Fuse makes use of these changes).
Make-map.exe can also generate structure declarations and delegate
declarations in addition to P/Invoke function declarations,
allowing for a better, automated interface between C and C#.
Previously, [Map] could only be used on enumerations.
Now, [Map] can be used on classes, structures, delegates, to create
a C declaration of the C# type, suitable for P/Invoke purposes, e.g.
[Map] struct Stat {public
Re: [Mono-list] [Mono-dev] Mono 1.1.17 has been released.
You should take note that mono-service based program doesn't work with this version... Le mardi 29 aot 2006 16:43 -0400, Miguel de Icaza a crit : Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code _javascript_ code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now features an abstract Unix end point in addition to Unix End Points [Alp Toker]. XML Land Fixed XmlSchemaSet and XmlSchemaCollection problem across multiple namespaces [Atsushi Enomoto] Important Bug Fixes Dynamic linking of Mono is now possible in applications that were using the TLS (open office) [Zoltan Varga]. Newly created AppDomains no longer inherit the list of loaded assemblies from the main domain. This has an important side-effect, to get XSP and mod_mono running, you must install the latest versions of it (released in this iteration), older versions will not work [Lluis Sanchez]. A
Re: [Mono-list] Mono 1.1.17 has been released.
After i compiled 1.1.17 i get 500 service unavailable The most strange is that i don't have error in the apache's error log Anyone noticed this or know how to fix it? Jorge - Original Message - From: Miguel de Icaza [EMAIL PROTECTED] To: mono-list@lists.ximian.com; Mono Announce mono-announce-list@lists.ximian.com; mono-devel-list@lists.ximian.com Sent: Tuesday, August 29, 2006 9:43 PM Subject: [Mono-list] Mono 1.1.17 has been released. Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code JavaScript code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now features an abstract Unix end point in addition to Unix End Points [Alp Toker]. XML Land Fixed XmlSchemaSet and XmlSchemaCollection problem across multiple namespaces [Atsushi Enomoto] Important Bug Fixes Dynamic linking of Mono is now possible in applications that were using the TLS (open
Re: [Mono-list] Mono 1.1.17 has been released.
Jorge Bastos wrote: After i compiled 1.1.17 i get 500 service unavailable The most strange is that i don't have error in the apache's error log Anyone noticed this or know how to fix it? You probably forgot to compile and install XSP. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Fw: Mono 1.1.17 has been released.
hum no, the only thing i didn't compiled was mod_mono sinse the version is the same i just compiled again to make sure that i updated xsp i have there warnings, are they relevant? ### /usr/local/bin/mcs -r:System.Web.dll -r:System.Web.Services.dll -r:extensions.dll \ -out:ServiceClient.exe \ ./ServiceClient.cs ./Reference.cs ./Reference.cs(60,4): warning CS0618: `System.Web.Services.Protocols.SoapHeaderAttribute.Required' is obsolete: `This property will be removed from a future version. The presence of a particular header in a SOAP message is no longer enforced' ./Reference.cs(67,4): warning CS0618: `System.Web.Services.Protocols.SoapHeaderAttribute.Required' is obsolete: `This property will be removed from a future version. The presence of a particular header in a SOAP message is no longer enforced' ./Reference.cs(75,4): warning CS0618: `System.Web.Services.Protocols.SoapHeaderAttribute.Required' is obsolete: `This property will be removed from a future version. The presence of a particular header in a SOAP message is no longer enforced' ./Reference.cs(83,4): warning CS0618: `System.Web.Services.Protocols.SoapHeaderAttribute.Required' is obsolete: `This property will be removed from a future version. The presence of a particular header in a SOAP message is no longer enforced' ./Reference.cs(90,4): warning CS0618: `System.Web.Services.Protocols.SoapHeaderAttribute.Required' is obsolete: `This property will be removed from a future version. The presence of a particular header in a SOAP message is no longer enforced' Compilation succeeded - 5 warning(s) ### and for apache's error log: [Wed Aug 30 09:40:30 2006] [notice] Apache/2.0.55 (Debian) mod_mono/1.1.16.1 configured -- resuming normal operations Another mod-mono-server with the same arguments is already running. Another mod-mono-server with the same arguments is already running. Another mod-mono-server with the same arguments is already running. Another mod-mono-server with the same arguments is already running. nothing else apears - Original Message - From: Robert Jordan [EMAIL PROTECTED] To: Mono-list@lists.ximian.com Sent: Wednesday, August 30, 2006 9:14 AM Subject: Re: [Mono-list] Mono 1.1.17 has been released. Jorge Bastos wrote: After i compiled 1.1.17 i get 500 service unavailable The most strange is that i don't have error in the apache's error log Anyone noticed this or know how to fix it? You probably forgot to compile and install XSP. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono 1.1.17 has been released.
A new stable release would be very much appreciated for people using Mono from binary packages like Ubuntu users. There are very important bugfixes since 1.1.13 that would be neccesary for production servers running mod-mono for example. What about declare 1.1.17 or 1.1.16.1 stable? Thanks El mar, 29-08-2006 a las 16:43 -0400, Miguel de Icaza escribió: Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code JavaScript code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now features an abstract Unix end point in addition to Unix End Points [Alp Toker]. XML Land Fixed XmlSchemaSet and XmlSchemaCollection problem across multiple namespaces [Atsushi Enomoto] Important Bug Fixes Dynamic linking of Mono is now possible in applications that were
Re: [Mono-list] [Mono-dev] Mono 1.1.17 has been released.
The thread is about a language (platform) allowing one to do most anything, adding Flash to the mix immediately defeats the purpose. I use asp.net, great for many things when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. I have been involved with many projects, and the clients always have the same needs. The audience goes to a web site, and you want to make your sale QUICK (or viral growth), say its a podcast client, a community collaboration tool, casino games, whatever, and the clients don't want to hear about a install executable, or a pokey asp.net sol'n, they want, when i boils down to it, an active X plugin (vb, c, c++ depending on needs) (or Java), and it just runs right there, no fuss no muss. Programmers don't think twice about installing a gtk app, 99+% of web users will not touch it with a ten foot pole. They will move on to the next casino, or community collaboration tool that just works right there, and yes many times now, you can find it to be flash, but lets not even go there and discuss the use of flash. I am just saying, it would be nice if Mono answered everyones needs (w.r.t the general places that you deploy programs - i.e. stand alone apps, ajax, asp.net, scripts/command line, and lastly browser plugins ), and filled this rather HUGE void (all be it a particularly commercial one). -tl On Wed, 2006-08-30 at 08:11 +0100, damien churchill wrote: __ From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then it’s easy enough just to make a gui for both web and desktop using asp/gtk whatever. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] (no subject)
Hello to the list, i'm new here and my question my be sounding a little bit stupid: Is it possible (at the actual development status of the mono framework) to go and install an msi package with a .net application in it. My question points also in direction windows registry and a workaround if this feature is not supported. I'll miss also a search function to do my my own investigations on the different lists. Best regards Mit freundlichen Grüßen Alexander Nolting Berater System Architekt Contact Centerund Telekommunikation - arvato systems GmbH An der Autobahn Postfach 180 D-33311 Gütersloh http://www.arvato-systems.de [EMAIL PROTECTED] Tel.: +49(5241)80-85409 Fax: +49(5241)80-685409 ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Help with garbled email headers when adding attachment
Hi,I have looked at trunk implementation and it seems that it's marked as a todo item. However, it has been marked over 5 months as that, so re-sending to mono-devel.If I knew the standard I would be happy to implement the functionality in mono, but I wouldn't be using the classes if I did that. Could someone help me out please? Thank you,Vladimir LushnikovOn 8/28/06, Vladimir Lushnikov [EMAIL PROTECTED] wrote:Hi,I'm trying to send an email with mono using smtp. If I send one normally, I get the following:---Subject: Mail testMIME-Version: 1.0Content-Type: text/html; charset=us-ascii Message-Id: .Date: Mon, 28 Aug 2006 15:33:16 -0700 (PDT)This is a mail testbr /This is a newline---However, as soon as I add an attachment, headers go wild:--- Subject: Hotbackup r22MIME-Version: 1.0Content-Type: multipart/mixed; charset=us-ascii; boundary=--boundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014Message-Id: .Date: Mon, 28 Aug 2006 15:43:44 -0700 (PDT) boundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014content-type: multipart/alternativecontent-transfer-encoding: quoted-printableThis is a mail testbr /This is a newlineboundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014 content-type: multipart/alternativecontent-transfer-encoding: base64SGVsbG8sIHdvcmxkLi4uCg==--- My code is: // Create the file attachment for this e-mail message. Attachment data = "" Attachment(file.FullName, MediaTypeNames.Application.Octet); // Add time stamp information for the file. ContentDisposition disposition = data.ContentDisposition; disposition.CreationDate = File.GetCreationTime(file.FullName ); disposition.ModificationDate = File.GetLastWriteTime(file.FullName); disposition.ReadDate = File.GetLastAccessTime(file.FullName); mail.Attachments.Add(data); Where mail is MailMessage object, file is a FileInfo object. I am using gmcs and trunk build (from yesterday).All help would be appreciated.Regards,Vladimir Lushnikov -- Vladimir Vlad# Lushnikov http://www.vladsharp.com - The Crests of Reason - Journey to a better object... -- Vladimir Vlad# Lushnikovhttp://www.vladsharp.com - The Crests of Reason - Journey to a better object... ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Help with garbled email headers when adding attachment
Am 29.08.2006 um 11:11 schrieb Vladimir Lushnikov:Hi,I have looked at trunk implementation and it seems that it's marked as a todo item. However, it has been marked over 5 months as that, so re-sending to mono-devel.If I knew the standard I would be happy to implement the functionality in mono, but I wouldn't be using the classes if I did that. Could someone help me out please?If you quoted correctly, then the newline after a MIME boundary and before the "Content-Type" is wrong; also after the last part the end is missing - should be "--", boundary name, "--".Andreas Thank you,Vladimir LushnikovOn 8/28/06, Vladimir Lushnikov [EMAIL PROTECTED] wrote:Hi,I'm trying to send an email with mono using smtp. If I send one normally, I get the following:---Subject: Mail testMIME-Version: 1.0Content-Type: text/html; charset=us-ascii Message-Id: <.>Date: Mon, 28 Aug 2006 15:33:16 -0700 (PDT)This is a mail testThis is a newline---However, as soon as I add an attachment, headers go wild:---Subject: Hotbackup r22MIME-Version: 1.0Content-Type: multipart/mixed; charset=us-ascii; boundary=--boundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014Message-Id: <.>Date: Mon, 28 Aug 2006 15:43:44 -0700 (PDT) boundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014content-type: multipart/alternativecontent-transfer-encoding: quoted-printableThis is a mail testThis is a newlineboundary_0_6ab9cc28-7330-47d7-ad54-569f53fe2014 content-type: multipart/alternativecontent-transfer-encoding: base64SGVsbG8sIHdvcmxkLi4uCg==--- My code is: // Create the file attachment for this e-mail message. Attachment data = "" Attachment(file.FullName, MediaTypeNames.Application.Octet); // Add time stamp information for the file. ContentDisposition disposition = data.ContentDisposition; disposition.CreationDate = File.GetCreationTime(file.FullName ); disposition.ModificationDate = File.GetLastWriteTime(file.FullName); disposition.ReadDate = File.GetLastAccessTime(file.FullName); mail.Attachments.Add(data); Where mail is MailMessage object, file is a FileInfo object. I am using gmcs and trunk build (from yesterday).All help would be appreciated.Regards,Vladimir Lushnikov -- Vladimir "Vlad#" Lushnikov http://www.vladsharp.com - The Crests of Reason - Journey to a better object... -- Vladimir "Vlad#" Lushnikovhttp://www.vladsharp.com - The Crests of Reason - Journey to a better object...___Mono-list maillist - Mono-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
On Tue, 2006-08-29 at 23:12 -0700, Valient Gough wrote: I've responded separately to Jon because I find his comments inflammatory. The only inflammatory bit was saying that I didn't like the SULF API. Which is about as inflammatory as saying Java collections suck (no language integration like System.Array integration System.Collections.IList), that System.Windows.Forms sucks, and that System.Diagnostics.EventLog sucks... The SULF project you reference predates the FUSE low-level API and even the latest couple kernel interface revisions. You could have found out about much newer code, and perhaps learned something about FUSE itself through a number of routes: As I asked in your separate message, *where* is this new SULF you reference? Furthermore, the SULF project I referenced makes use of the FUSE low-level API, at least that's what the ChangeLog and associated web site says The Fuse.dll library communicates with the FUSE kernel module, which would be the low-level FUSE API... 1. ask about the state of SULF. I would not have recommended starting with this defunct project, nor recommended referencing it as an alternative. The SULF site I referenced (http://arg0.net/users/vgough/sulf/) is the top-most linked site at the time I was searching. The SULF site I referenced is *still* the site listed in the FUSE Wiki: http://fuse.sourceforge.net/wiki/index.php/LanguageBindings Short of emailing you, I have no idea how I was supposed to find anything more recent, especially since these older sites, which presumably you still control, could have been updated to at least say this has been deprecated, please see the newer library _here_. BTW, this would *still* be a good idea. 3. search this Mono list for FUSE related announcements Searching my multi-year mono-list history for all messages with FUSE in the subject brings up: Re: [Mono-list] mod_mono MAKE confused on Apache version - obvious match for fuse as a substring, not relevant [Mono-list] ANN: Linux filesystems in C# (FUSE wrapper) - Dated May 12, 2005, by Valient Gough [EMAIL PROTECTED] - References http://pobox.com/~vgough/sulf - ...which redirects to http://arg0.net/users/vgough/sulf/ A *new* search (this morning) also brings up fusewrapper, http://arg0.net/wiki/fusewrapper, so I assume this is the newer library BTW, I see no messages with fusewrapper in the subject on either mono-list or mono-devel-list. - Jon ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [Mono-dev] Mono 1.1.17 has been released.
I just want to say great job to those making mono a real and competitive alternative to the .NET platform, in addition to its incredible cross-platform enabling; being an engineer with .NET technologies, I can say that mono is truly robust and really (finally) provides the write once, run anywhere capability we all have longed for. I salute you, Mr. Cross-platform Enabler! Original Message Subject: [Mono-dev] Mono 1.1.17 has been released. From: Miguel de Icaza [EMAIL PROTECTED] Date: Tue, August 29, 2006 4:43 pm To: mono-list@lists.ximian.com, Mono Announce mono-announce-list@lists.ximian.com, mono-devel-list@lists.ximian.com Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code JavaScript code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now
[Mono-list] Parameters SQLite
Are parameters supported by the Mono.Data.SqliteClient namespace/assembly? I've googled myself silly can can't find an example or statement about this. Just lots of examples of using DataReader. :) Perhaps there is a matrix somewhere of what features are implemented in the various providers? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [Mono-dev] Mono 1.1.17 has been released.
Hello, You should take note that mono-service based program doesn't work with this version... As I pointed out in the bug you filed, am unable to reproduce the problem; Please update the bug. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [Mono-dev] Mono 1.1.17 has been released.
Le mercredi 30 aot 2006 11:17 -0400, Miguel de Icaza a crit: Hello, You should take note that mono-service based program doesn't work with this version... As I pointed out in the bug you filed, am unable to reproduce the problem; Please update the bug. I've talk with Robert Jordan, and he doesn't understant why you can't reproduce the bug... He can reproduce the bug, and we've find the solution, he's making a patch in order to place mono-service.exe into the GAC (like XSP) ___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-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Parameters SQLite
It is my blog, but take a look anyway. http://little.xmtp.net/blog/2005/10/21/proper-data-abstraction-in-net-and-mono-applications/ http://little.xmtp.net/blog/2005/11/22/more-proper-data-abstractions-in-net-and-mono-applications/ The short answer is yes parameters are supported. There are examples at the above URLs. A short example: |IDbCommand idcSelect = conn.CreateCommand(); idcSelect.CommandText = select col from table where [EMAIL PROTECTED]; ||IDataParameter param = idcSelect.CreateParameter(); Cmd.Parameters.Add(param); param.ParameterName = @someting; param.DbType = DbType.String; param.Value = whatever something would equal; | The above is more geared to 1.1, since 2.0 has DbConnection and the ADO2.0 db provider stuff. -- Jay Adam Tauno Williams wrote: Are parameters supported by the Mono.Data.SqliteClient namespace/assembly? I've googled myself silly can can't find an example or statement about this. Just lots of examples of using DataReader. :) Perhaps there is a matrix somewhere of what features are implemented in the various providers? ___ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] XSP2
On Tue, 2006-08-29 at 10:08 +0200, Mats Nilsson wrote: Hi all, Is there some kind of problems in the XSP2 server for Windows? I'm getting broken connections when requesting pages from the server and sometimes a complete lockup which requires a kill of mono process. If you file a bug (see http://www.mono-project.com/Bugs) telling me how to realiably reproduce it, i'll fix it ASAP. -Gonzalo ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
