[Mono-docs-list] Altering the MonkeyGuide page
I would like to pull together all the GTK# tutorials, examples and techniques on the wiki as much as possible. What I mean is, I feel it would be good to have a single gateway, which can lead directly onto all of the relevant learning-orientated pages, like short examples, tutorials and guides. To that end I have created this temporary page to organise and link to all the GTK# flavoured tutorials and examples I am aware of: http://www.mono-project.com/BosteenProgramming_With_GTKSharp To make it fit into the Monkeyguide, I would have to adjust the guide layout slightly. A demonstration of this new layout is here: http://www.mono-project.com/BosteenMonkey_Guide My question is this: Should I embed the 'BosteenProgramming_With_GTKSharp' page links into the 'Gtksharp' page? Or should I leave it separate? If noone objects or minds, I'll make the changes to the Monkeyguide on the weekend. Obviously, I am really uncomfortable making any major changes like this without... erm, peer-consent, if you see what I mean, so I would really like to hear back on this, even if all you want to say is 'Yeah, do it' Thanks, Ben ___ Mono-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
Re: [Mono-winforms-list] Weird issues reading pixels of jpg file on osx
Thanks Dan,
I've opened bug #79246 for the LockBits issues which, from the unit
tests I added this morning, appears to affect every type of bitmaps.
FYI the problem that affected the (first two lines of) JPEG bitmaps
doesn't happen on any other type of pictures.
On Thu, 2006-08-31 at 09:02 -0700, Dan Shryock wrote:
Sebastien,
I just ran the code for reading jpegs on the 1.1.14 build on osx and
it had different results that those that I am currently getting, but
they were still not correct. Hope this helps.
Dan
On 1.1.14 it came out as:
255
255
255
255
77
255
255
75
144
255
75
143
255
73
144
255
74
145
255
74
147
255
74
147
255
75
150
255
74
149
On 8/31/06, Sebastien Pouliot [EMAIL PROTECTED] wrote:
Hello Dan,
[please c.c. the mailing-list in your answers]
I found a problem with (most) JPEG files where the first two lines had
some bad values. This is fixed in SVN :-)
However my (new) unit tests using LockBits are all failing - even for
bitmaps. Something else is wrong there :-(
Note that I'm still curious to know if this was working on previous Mac
OS X releases ;-)
On Thu, 2006-08-31 at 08:21 -0700, Dan Shryock wrote:
Hi Sebastien,
Thanks for looking into this. I just tried it on a png file instead
of the jpeg, and I am still seeing different results for the pixel
data.
On windows the first few bytes were as follows:
196
144
73
195
143
72
while on osx they were:
255
144
73
255
255
72
So something similar seems to be affecting png reading as well as jpeg
reading.
Dan
On 8/31/06, Sebastien Pouliot [EMAIL PROTECTED] wrote:
Hello Dan,
It may be unrelated to endian issues (but I still like your answers,
multiple problems are common ;-) as I also found out differences between
Mono on Linux i386 and Windows.
It seems, in my test case, that the first two lines of the decoded jpeg
aren't correct. In the first line all 2nd and 4th bytes are identical,
while on the second line all 3rd and 4th bytes are identical (on the
mono side, the 4th byte being correct). All other lines looks correct
(but needs more investigation).
I'm re-enabling the JpegCodec unit tests (not sure why they were
commented, the ChangeLog says fixed) and adding new test cases.
Thanks for noticing this.
On Wed, 2006-08-30 at 20:08 -0400, Sebastien Pouliot wrote:
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/
--
Sebastien Pouliot [EMAIL PROTECTED]
Blog: http://pages.infinit.net/ctech/
--
Sebastien Pouliot [EMAIL PROTECTED]
Blog: http://pages.infinit.net/ctech/
___
Mono-winforms-list maillist -
Re: [Mono-dev] [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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono on Linux/Alpha
Hi, The patch is now in SVN. Thanks ! Zoltan On 9/1/06, Servey Tikhonov [EMAIL PROTECTED] wrote: Hello Zoltan, Here is another set of patches for mono on Linux/Alpha. The changes are: - Added -mieee option to gcc - Added support for floats (comparing them) - The size of generated code could be more than 32Kb - Internal debug messages are controlled by MONO_ALPHA_DEBUG env. variable - Added LMF support - Support for atomic operations contibuted by Jakub Boqusz [EMAIL PROTECTED] - Fixed exception handling and unwinding - Implemented exception rethrowning As result - 10 tests out of 194 in mono/tests - passed, all tests in mono/mini - passed. The mcs compiler shows help, correcly complains if there is no file to compile, completes parsing stage without visible errors (mcs is ran with --parse option). Regards, Sergey. [EMAIL PROTECTED] Solvo Ltd. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announce: Mono.Fuse 0.2.0 (+ Required mcs mono patches)
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. It has since been replaced
by fusewrapper, http://arg0.net/darcs/fusewrapper.
Mono.Fuse has no relation to SULF or fusewrapper, 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.)
SULF is an inode-based API, while Mono.Fuse is a path-based
API. I think paths are easier to deal with, and Valient Gough
believes inodes are.
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, and mono-tools modules,
changes which need to be proposed and discussed.
mcs:
---
There are two major changes:
* The addition of several new methods public to
Mono.Unix.Native.NativeConvert:
class Mono.Unix.Native.NativeConvert {
public static bool TryCopy (ref Flock source, IntPtr destination);
public static void Copy (ref Flock source, IntPtr destination);
public static bool TryCopy (IntPtr source, out Flock destination);
public static void Copy (IntPtr source, out Flock source);
/* repeat for most other structure types, e.g. Stat, Statvfs,
Pollfd, Timeval, Timezone, Utimbuf... */
}
* class/Mono.Posix/Mono.Unix.Native/make-map.cs has been moved to
mono-tools/create-native-map/src/create-native-map.cs.
Those are the public changes. Internally, MapAttribute has been
revamped considerably, as has create-native-map.exe, but MapAttribute
remains an internal attribute and is not part of the public API.
The new methods on NativeConvert are required to permit extending the
current Mono.Posix infrastructure, so that Mono.Fuse can make use of
Mono.Posix's Stat Statvfs structure copying support (among other
types).
Statvfs is particularly nice, as mono/support/sys-statvfs.c is a
#ifdef-infested scourge, largely by trying to support Linux (statvfs)
and OS X/*BSD (statfs) and make them look identical to managed code.
mono:
create-native-map.exe now has support to generate structure
declarations, to better ensure that managed native structures are
identical (as opposed to doing this by hand).
map-icalls.h has been removed, its contents inserted into map.h.
map.c and map.h have additional methods for copying structures between
managed native representations, e.g. Mono_Posix_ToStat
(native-managed) and Mono_Posix_FromStat (managed-native).
Many of the .c files have been changed to update their prototypes to
match the current create-native-map-generated declarations in map.h,
and to remove the hand-created structure definitions (as
create-native-map.exe generates these now).
A cached version of create-native-map.exe is now kept as
mono/support/create-native-map.exe, so that mono-tools isn't required
to run `make refresh'. The `update-cnm' target updates the cached
program.
Otherwise, no public API changes or additions (since MonoPosixHelper
is considered to be an internal API, any changes aren't public).
mono-tools:
--
Adds create-native-map.exe, and adds a create-native-map.pc file so
that pkg-config can be used to update a cached copy of
create-native-map.exe MapAttribute.cs.
HOWTO:
=
Go to http://www.jprl.com/mono-fuse for the patches and source download.
Apply ``mcs.patch'' to a ``mcs'' checkout, rebuild, and install.
Apply ``mono.patch'' to a ``mono'' checkout, rebuild, and install.
Build ``mono-fuse-0.2.0.tar.gz'' in the standard manner.
Optionally, apply ``mono-tools.patch'' to a ``mono-tools'' checkout,
rebuild, and install.
Questions:
=
- How should we cope with unstable APIs which make use of native
code? The Application Deployment Guidelines [1] don't address
this issue.
For example, the Guidelines stat that
[Mono-dev] xsp2 on debian
Hi, I'm having real difficulty getting mod_mono/xsp2 up and running on Debian (Etch). After experimenting, it appears to be down to a line in machine.config that xsp2 doesn't understand. It's not too clear which line of the configuration is failing so I correct it. Any pointers on what I could look at to get that info? My mono version is the latest in the Debian distribution - 1.1.13.8. beyond-dev1:/home/beyond/htdocs# xsp2 Unhandled Exception: System.InvalidCastException: Cannot cast from source type to destination type. in 0x0003f System.Configuration.ConfigurationManager:get_AppSettings () in 0x7 Mono.XSP.Server:get_AppSettings () in 0x00149 Mono.XSP.Server:Main (System.String[] args) Cheers, Matt ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] IE7 RC1 and browsercaps.ini
Hello
I've written a little aspx page that show a pb with IE7
public class Default : Page
{
protected System.Web.UI.HtmlControls.HtmlForm form1;
protected System.Web.UI.WebControls.Label textBox1;
protected override void OnInit(System.EventArgs a)
{
this.Load+=this.OnLoad;
Console.WriteLine(bonjour);
}
protected void OnLoad(object o,System.EventArgs a)
{
textBox1.Text=Version :+Request.Browser.Version+ +Request.Browser.Browser;
}
}
When i load the page with IE7 : Mono show : Version: Unknown
With MS.NET 1.1 it show IE7
I've notified that browsercaps.ini has entries for IE7
([Mozilla/4.0 (compatible; MSIE 7.0b; *Windows XP*.NET CLR*)*])
but with ethereal (wireshark) i've seen that the new string is ([Mozilla/4.0 (compatible; MSIE 7.0; *Windows XP*.NET CLR*)*])
Here's the patch for browscap.ini
Thanks to commit!
Index: mono/data/browscap.ini
===
--- mono/data/browscap.ini (rvision 64676)
+++ mono/data/browscap.ini (copie de travail)
@@ -13397,6 +13397,40 @@
platform=WinXP
netclr=True
+[Mozilla/4.0 (compatible; MSIE 7.0; *Windows NT 5.1*)*]
+parent=IE 7.0
+platform=WinXP
+
+[Mozilla/4.0 (compatible; MSIE 7.0; *Windows NT 5.1*.NET CLR*)*]
+parent=IE 7.0
+platform=WinXP
+
+[Mozilla/4.0 (compatible; MSIE 7.0; *Windows NT 5.2*)*]
+parent=IE 7.0
+platform=Win2003
+netclr=True
+
+[Mozilla/4.0 (compatible; MSIE 7.0; *Windows NT 5.2*.NET CLR*)*]
+parent=IE 7.0
+platform=Win2003
+
+[Mozilla/4.0 (compatible; MSIE 7.0; *Windows NT 6.0*)*]
+parent=IE 7.0
+platform=WinVI
+
+[Mozilla/4.0 (compatible; MSIE 7.0; *Windows NT 6.0*.NET CLR*)*]
+parent=IE 7.0
+platform=WinVI
+
+[Mozilla/4.0 (compatible; MSIE 7.0; *Windows XP*)*]
+parent=IE 7.0
+platform=WinXP
+
+[Mozilla/4.0 (compatible; MSIE 7.0; *Windows XP*.NET CLR*)*]
+parent=IE 7.0
+platform=WinXP
+netclr=True
+
Default Browser
[*]
___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] xsp2 on debian
Matt Dockerty wrote: I'm having real difficulty getting mod_mono/xsp2 up and running on Debian (Etch). After experimenting, it appears to be down to a line in machine.config that xsp2 doesn't understand. It's not too clear which line of the configuration is failing so I correct it. Any pointers on what I could look at to get that info? My mono version is the latest in the Debian distribution - 1.1.13.8. I had the exact same problem. See this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372281 As of yesterday I still couldn't get xsp2 to work on Debian Etch which is why today I built everything Mono related from source. I'm happy to report xsp2 from the svn-trunk seems to work fine. The Debian Mono Group is doing an excellent job packaging Mono for Etch, so I have no idea why this bug has stayed open for so long. -- Michael Schurter Synthesys Solutions ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono/interpreter/interp.c build problems
Hello all, I'm attempting to bring mono up under a Linux/MIPS environment (Debian if anyone cares), and as the JIT for mips doesn't exist yet, I thought the best thing to do was configure and build an interpreter version first (as recommended). Doing this from the svn head (updated as of 10 minutes ago), yields the following errors (I've manually cut the warnings for clarity): interp.c: In function 'ves_exec_method_with_context': interp.c:2667: error: 'struct MonoVTable' has no member named 'interface_offsets' interp.c:2691: error: 'struct MonoVTable' has no member named 'interface_offsets' interp.c:3957: error: dereferencing pointer to incomplete type interp.c:4004: error: dereferencing pointer to incomplete type I guess my first question is - how up to-date is the interpreter build of mono? Since most of the popular architectures (except MIPS) have JITs, has it been built or tested recently? Thanks in advance, Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono/interpreter/interp.c build problems
Hi, The interpreter is deprecated and is no longer maintained. It will be removed entirely in the (near) future. Zoltan On 9/1/06, Mark E Mason [EMAIL PROTECTED] wrote: Hello all, I'm attempting to bring mono up under a Linux/MIPS environment (Debian if anyone cares), and as the JIT for mips doesn't exist yet, I thought the best thing to do was configure and build an interpreter version first (as recommended). Doing this from the svn head (updated as of 10 minutes ago), yields the following errors (I've manually cut the warnings for clarity): interp.c: In function 'ves_exec_method_with_context': interp.c:2667: error: 'struct MonoVTable' has no member named 'interface_offsets' interp.c:2691: error: 'struct MonoVTable' has no member named 'interface_offsets' interp.c:3957: error: dereferencing pointer to incomplete type interp.c:4004: error: dereferencing pointer to incomplete type I guess my first question is - how up to-date is the interpreter build of mono? Since most of the popular architectures (except MIPS) have JITs, has it been built or tested recently? Thanks in advance, Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono/interpreter/interp.c build problems
Hello, Ah - thanks. Straight on to the JIT port for mips then. ;-) Thx, Mark -Original Message- From: Zoltan Varga [mailto:[EMAIL PROTECTED] Sent: Friday, September 01, 2006 1:20 PM To: Mark E Mason Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] mono/interpreter/interp.c build problems Hi, The interpreter is deprecated and is no longer maintained. It will be removed entirely in the (near) future. Zoltan On 9/1/06, Mark E Mason [EMAIL PROTECTED] wrote: Hello all, I'm attempting to bring mono up under a Linux/MIPS environment (Debian if anyone cares), and as the JIT for mips doesn't exist yet, I thought the best thing to do was configure and build an interpreter version first (as recommended). Doing this from the svn head (updated as of 10 minutes ago), yields the following errors (I've manually cut the warnings for clarity): interp.c: In function 'ves_exec_method_with_context': interp.c:2667: error: 'struct MonoVTable' has no member named 'interface_offsets' interp.c:2691: error: 'struct MonoVTable' has no member named 'interface_offsets' interp.c:3957: error: dereferencing pointer to incomplete type interp.c:4004: error: dereferencing pointer to incomplete type I guess my first question is - how up to-date is the interpreter build of mono? Since most of the popular architectures (except MIPS) have JITs, has it been built or tested recently? Thanks in advance, Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] BUG in TypeDescriptor.GetAttributes : Ignores overriden attributes
The current implementation of TypeDescriptor.GetAttributes ignores
overriden attributes and returns the bottom most in the inheritance
tree. The attached patch fixes that. I have also attached a test case
so you can observe the wrong behaviour. The patch also does whitespace
cleanup.
Please review and commit.
P.S: The fix is this and everything else is just the whitespace cleanup:
=== START ===
protected AttributeCollection GetAttributes (IComponent comp)
{
if (_attributes != null)
return _attributes;
-
+
bool cache = true;
object[] ats = _infoType.GetCustomAttributes (true);
Hashtable t = new Hashtable ();
- foreach (Attribute at in ats)
- t [at.TypeId] = at;
-
- if (comp != null comp.Site != null)
+
+ // Filter the custom attributes, so that only the top
+ // level of the same type are left.
+ //
+ for (int i = ats.Length -1; i 0; i--) {
+ t [((Attribute) ats[i]).TypeId] = ats[i];
+ }
+
+ if (comp != null comp.Site != null)
{
ITypeDescriptorFilterService filter =
(ITypeDescriptorFilterService) comp.Site.GetService
(typeof(ITypeDescriptorFilterService));
cache = filter.FilterAttributes (comp, t);
}
=== END ===
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
GPG Key: http://files.i-nZ.net/i-nZ.asc
It's all some kind of whacked out conspiracy.
Index: class/System/System.ComponentModel/TypeDescriptor.cs
===
--- class/System/System.ComponentModel/TypeDescriptor.cs (revision 64506)
+++ class/System/System.ComponentModel/TypeDescriptor.cs (working copy)
@@ -17,10 +17,10 @@
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
-//
+//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
-//
+//
// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
@@ -61,14 +61,14 @@
{
string tn = designerBaseType.AssemblyQualifiedName;
AttributeCollection col = GetAttributes (component);
-
+
foreach (Attribute at in col) {
DesignerAttribute dat = at as DesignerAttribute;
if (dat != null tn == dat.DesignerBaseTypeName) {
return (IDesigner) Activator.CreateInstance (GetTypeFromName (component, dat.DesignerTypeName));
}
}
-
+
return null;
}
@@ -193,7 +193,7 @@
if (noCustomTypeDesc == false component is ICustomTypeDescriptor) {
return ((ICustomTypeDescriptor) component).GetConverter ();
- }
+ }
else {
Type t = null;
AttributeCollection atts = GetAttributes (component, false);
@@ -201,7 +201,7 @@
if (tca != null tca.ConverterTypeName.Length 0) {
t = GetTypeFromName (component as IComponent, tca.ConverterTypeName);
}
-
+
if (t != null) {
ConstructorInfo ci = t.GetConstructor (new Type[] { typeof(Type) });
if (ci != null)
@@ -220,7 +220,7 @@
lock (creatingDefaultConverters) {
if (defaultConverters != null)
return defaultConverters;
-
+
defaultConverters = new Hashtable ();
defaultConverters.Add (typeof (bool), typeof (BooleanConverter));
defaultConverters.Add (typeof (byte), typeof (ByteConverter));
@@ -248,20 +248,20 @@
return defaultConverters;
}
}
-
+
public static TypeConverter GetConverter (Type type)
{
TypeConverterAttribute tca = null;
Type t = null;
object [] atts = type.GetCustomAttributes (typeof(TypeConverterAttribute), true);
-
+
if (atts.Length 0)
tca = (TypeConverterAttribute)atts[0];
-
+
if (tca != null) {
t = GetTypeFromName (null, tca.ConverterTypeName);
}
-
+
if (t == null) {
if (type.IsEnum) {
// EnumConverter needs to know the enum type
@@ -270,7 +270,7 @@
return new ArrayConverter ();
}
}
-
+
if (t == null)
t = FindConverterType (type);
@@ -295,19 +295,19 @@
private static Type FindConverterType (Type type)
{
Type t = null;
-
+
// Is there a default converter
t = (Type) DefaultConverters [type];
if (t != null)
return t;
-
+
// Find default converter with a type this type is assignable to
foreach (Type defType in DefaultConverters.Keys) {
if (defType.IsInterface defType.IsAssignableFrom (type)) {
Re: [Mono-dev] [PATCH] BUG in TypeDescriptor.GetAttributes : Ignores overriden attributes
Excuse me, made a typo in the previous patch. Please review this one
(basically changed i 0 to i = 0)
Cheers,
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
GPG Key: http://files.i-nZ.net/i-nZ.asc
It's all some kind of whacked out conspiracy.
Index: class/System/System.ComponentModel/TypeDescriptor.cs
===
--- class/System/System.ComponentModel/TypeDescriptor.cs (revision 64506)
+++ class/System/System.ComponentModel/TypeDescriptor.cs (working copy)
@@ -17,10 +17,10 @@
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
-//
+//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
-//
+//
// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
@@ -61,14 +61,14 @@
{
string tn = designerBaseType.AssemblyQualifiedName;
AttributeCollection col = GetAttributes (component);
-
+
foreach (Attribute at in col) {
DesignerAttribute dat = at as DesignerAttribute;
- if (dat != null tn == dat.DesignerBaseTypeName) {
+ if (dat != null tn == dat.DesignerBaseTypeName) {
return (IDesigner) Activator.CreateInstance (GetTypeFromName (component, dat.DesignerTypeName));
}
}
-
+
return null;
}
@@ -193,7 +193,7 @@
if (noCustomTypeDesc == false component is ICustomTypeDescriptor) {
return ((ICustomTypeDescriptor) component).GetConverter ();
- }
+ }
else {
Type t = null;
AttributeCollection atts = GetAttributes (component, false);
@@ -201,7 +201,7 @@
if (tca != null tca.ConverterTypeName.Length 0) {
t = GetTypeFromName (component as IComponent, tca.ConverterTypeName);
}
-
+
if (t != null) {
ConstructorInfo ci = t.GetConstructor (new Type[] { typeof(Type) });
if (ci != null)
@@ -220,7 +220,7 @@
lock (creatingDefaultConverters) {
if (defaultConverters != null)
return defaultConverters;
-
+
defaultConverters = new Hashtable ();
defaultConverters.Add (typeof (bool), typeof (BooleanConverter));
defaultConverters.Add (typeof (byte), typeof (ByteConverter));
@@ -248,20 +248,20 @@
return defaultConverters;
}
}
-
+
public static TypeConverter GetConverter (Type type)
{
TypeConverterAttribute tca = null;
Type t = null;
object [] atts = type.GetCustomAttributes (typeof(TypeConverterAttribute), true);
-
+
if (atts.Length 0)
tca = (TypeConverterAttribute)atts[0];
-
+
if (tca != null) {
t = GetTypeFromName (null, tca.ConverterTypeName);
}
-
+
if (t == null) {
if (type.IsEnum) {
// EnumConverter needs to know the enum type
@@ -270,7 +270,7 @@
return new ArrayConverter ();
}
}
-
+
if (t == null)
t = FindConverterType (type);
@@ -295,19 +295,19 @@
private static Type FindConverterType (Type type)
{
Type t = null;
-
+
// Is there a default converter
t = (Type) DefaultConverters [type];
if (t != null)
return t;
-
+
// Find default converter with a type this type is assignable to
foreach (Type defType in DefaultConverters.Keys) {
if (defType.IsInterface defType.IsAssignableFrom (type)) {
return (Type) DefaultConverters [defType];
}
}
-
+
// Nothing found, try the same with our base type
if (type.BaseType != null)
return FindConverterType (type.BaseType);
@@ -367,8 +367,8 @@
object [] atts = componentType.GetCustomAttributes (typeof(EditorAttribute), true);
if (atts == null || atts.Length == 0)
return null;
-
-
+
+
foreach (EditorAttribute ea in atts)
{
t = GetTypeFromName (null, ea.EditorTypeName);
@@ -566,7 +566,7 @@
}
public static event RefreshEventHandler Refreshed;
-
+
internal static ComponentInfo GetComponentInfo (IComponent com)
{
lock (componentTable)
@@ -583,7 +583,7 @@
return ci;
}
}
-
+
internal static TypeInfo GetTypeInfo (Type type)
{
lock (typeTable)
@@ -596,7 +596,7 @@
return ci;
}
}
-
+
static Type GetTypeFromName (IComponent component, string typeName)
{
if (component != null component.Site != null) {
@@ -604,7 +604,7 @@
if (resver != null)
return resver.GetType (typeName, true, false);
}
-
+
Type t = Type.GetType (typeName);
if (t == null) throw new ArgumentException (Type ' + typeName + ' not found);
return t;
@@ -619,21 +619,21 @@
PropertyDescriptor _defaultProperty;
bool _gotDefaultProperty;
AttributeCollection _attributes;
-
+
public Info (Type infoType)
{
_infoType = infoType;
}
-
+
public abstract AttributeCollection GetAttributes ();
public abstract EventDescriptorCollection GetEvents ();
public abstract
[Mono-dev] [Patch] 2 Bugs in ReflectorPropertyDescriptor: ignores Design-Time properties
This patch fixed the following 2 bugs. Please review and commit
1) The ReflectionPropretyDescriptor must be able to operate with non
public properties.
2) The current implementation ignores the fact that the component can
be in design mode. In design mode some of the properties (the
design-time ones) are supposed to be redirected to the designer. The
component which should be used to access the property is retrieved by
using MemberDescriptor.GetInvokee (implemented in the patch). Updated
the ReflectorPropertyDescriptor to use GetInvokee to decide which
component should it use.
P.S: Whitespace cleanup in the patch too.
Cheers,
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
GPG Key: http://files.i-nZ.net/i-nZ.asc
It's all some kind of whacked out conspiracy.
Index: class/System/System.ComponentModel/MemberDescriptor.cs
===
--- class/System/System.ComponentModel/MemberDescriptor.cs (revision 64506)
+++ class/System/System.ComponentModel/MemberDescriptor.cs (working copy)
@@ -4,6 +4,7 @@
// Author:
// Miguel de Icaza ([EMAIL PROTECTED])
// Andreas Nahr ([EMAIL PROTECTED])
+// Ivan N. Zlatev (contact i-nZ.net)
//
// (C) Ximian, Inc. http://www.ximian.com
// (C) 2003 Andreas Nahr
@@ -17,10 +18,10 @@
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
-//
+//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
-//
+//
// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
@@ -34,18 +35,19 @@
using System.Collections;
using System.Reflection;
using System.Runtime.InteropServices;
+using System.ComponentModel.Design;
namespace System.ComponentModel
{
[ComVisible (true)]
-public abstract class MemberDescriptor
+public abstract class MemberDescriptor
{
private string name;
private Attribute [] attrs;
private AttributeCollection attrCollection;
-
+
protected MemberDescriptor (string name, Attribute [] attrs)
{
this.name = name;
@@ -69,15 +71,15 @@
attrs = reference.AttributeArray;
}
-protected virtual Attribute [] AttributeArray
+protected virtual Attribute [] AttributeArray
{
-get
+get
{
-if (attrs == null)
+if (attrs == null)
{
ArrayList list = new ArrayList ();
FillAttributes (list);
-
+
ArrayList filtered = new ArrayList ();
foreach (Attribute at in list) {
bool found = false;
@@ -88,11 +90,11 @@
}
attrs = (Attribute[]) filtered.ToArray (typeof(Attribute));
}
-
+
return attrs;
}
-set
+set
{
attrs = value;
}
@@ -105,7 +107,7 @@
public virtual AttributeCollection Attributes
{
-get
+get
{
if (attrCollection == null)
attrCollection = CreateAttributeCollection ();
@@ -117,18 +119,18 @@
{
return new AttributeCollection (AttributeArray);
}
-
-public virtual string Category
+
+public virtual string Category
{
-get
+get
{
return ((CategoryAttribute) Attributes [typeof (CategoryAttribute)]).Category;
}
}
-public virtual string Description
+public virtual string Description
{
-get
+get
{
foreach (Attribute attr in AttributeArray)
{
@@ -139,9 +141,9 @@
}
}
-public virtual bool DesignTimeOnly
+public virtual bool DesignTimeOnly
{
-get
+get
{
foreach (Attribute attr in AttributeArray)
{
@@ -153,25 +155,25 @@
}
}
-public virtual string DisplayName
+public virtual string DisplayName
{
-get
+get
{
return name;
}
}
-public virtual string Name
+public virtual string Name
{
-get
+get
{
return name;
}
}
-public virtual bool IsBrowsable
+public virtual bool IsBrowsable
{
-get
+get
{
foreach (Attribute attr in AttributeArray)
{
@@ -183,15 +185,15 @@
}
}
-protected virtual
Re: [Mono-list] [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-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [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-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Application installation on Windows
Am 01.09.2006 um 03:04 schrieb Jonathan Pryor: On Thu, 2006-08-31 at 16:31 +0200, Andreas Färber wrote: P.S. Talking of Mono on Windows, does anyone have an update of Mono on Win9x/ME? That's another unanswered question of mine... (and if working again would lead to a non-official installation!) There is no supported Mono for Win9x/ME, as Mono currently relies on may Win32 APIs added to Win2k. I know, which is why I asked it in the context of non-official, hardly detectable Mono installations. If it were supported by the official Mono installer it would not matter to that aspect. :-) It might be possible to port Mono to Win9x/ME (especially with the help of MSLU), but you're probably on your own for such a port. Serge posted a wrapper library some time ago on the list (it's also mentioned in the official FAQ) to compile Mono on Cygwin with MSLU - but I was unable to compile Mono 1.1.15 with it: http://lists.ximian.com/pipermail/mono-list/2006-April/031317.html Not getting any answer from the list I had also written to Serge personally but didn't get a reply either. So that was a dead end for me. The reason I tried is that there is a legacy DOS application running on a Windows 95 system that I would like to replace with a more modern .NET based app, and I need a way of migrating it while still running. My idea was to run a Mono based server app on the Win95 machine interop'ing with the legacy app as a three-tier solution... The only alternative I've come up with was exposing the legacy data files as a Windows share and reading them from remote; I'm still figuring out the file format from a local copy so haven't tested that yet - would I get change notifications from such a remote SMB share with FileSystemWatcher? Andreas ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Announce: Mono.Fuse 0.2.0 (+ Required mcs mono patches)
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. It has since been replaced
by fusewrapper, http://arg0.net/darcs/fusewrapper.
Mono.Fuse has no relation to SULF or fusewrapper, 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.)
SULF is an inode-based API, while Mono.Fuse is a path-based
API. I think paths are easier to deal with, and Valient Gough
believes inodes are.
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, and mono-tools modules,
changes which need to be proposed and discussed.
mcs:
---
There are two major changes:
* The addition of several new methods public to
Mono.Unix.Native.NativeConvert:
class Mono.Unix.Native.NativeConvert {
public static bool TryCopy (ref Flock source, IntPtr destination);
public static void Copy (ref Flock source, IntPtr destination);
public static bool TryCopy (IntPtr source, out Flock destination);
public static void Copy (IntPtr source, out Flock source);
/* repeat for most other structure types, e.g. Stat, Statvfs,
Pollfd, Timeval, Timezone, Utimbuf... */
}
* class/Mono.Posix/Mono.Unix.Native/make-map.cs has been moved to
mono-tools/create-native-map/src/create-native-map.cs.
Those are the public changes. Internally, MapAttribute has been
revamped considerably, as has create-native-map.exe, but MapAttribute
remains an internal attribute and is not part of the public API.
The new methods on NativeConvert are required to permit extending the
current Mono.Posix infrastructure, so that Mono.Fuse can make use of
Mono.Posix's Stat Statvfs structure copying support (among other
types).
Statvfs is particularly nice, as mono/support/sys-statvfs.c is a
#ifdef-infested scourge, largely by trying to support Linux (statvfs)
and OS X/*BSD (statfs) and make them look identical to managed code.
mono:
create-native-map.exe now has support to generate structure
declarations, to better ensure that managed native structures are
identical (as opposed to doing this by hand).
map-icalls.h has been removed, its contents inserted into map.h.
map.c and map.h have additional methods for copying structures between
managed native representations, e.g. Mono_Posix_ToStat
(native-managed) and Mono_Posix_FromStat (managed-native).
Many of the .c files have been changed to update their prototypes to
match the current create-native-map-generated declarations in map.h,
and to remove the hand-created structure definitions (as
create-native-map.exe generates these now).
A cached version of create-native-map.exe is now kept as
mono/support/create-native-map.exe, so that mono-tools isn't required
to run `make refresh'. The `update-cnm' target updates the cached
program.
Otherwise, no public API changes or additions (since MonoPosixHelper
is considered to be an internal API, any changes aren't public).
mono-tools:
--
Adds create-native-map.exe, and adds a create-native-map.pc file so
that pkg-config can be used to update a cached copy of
create-native-map.exe MapAttribute.cs.
HOWTO:
=
Go to http://www.jprl.com/mono-fuse for the patches and source download.
Apply ``mcs.patch'' to a ``mcs'' checkout, rebuild, and install.
Apply ``mono.patch'' to a ``mono'' checkout, rebuild, and install.
Build ``mono-fuse-0.2.0.tar.gz'' in the standard manner.
Optionally, apply ``mono-tools.patch'' to a ``mono-tools'' checkout,
rebuild, and install.
Questions:
=
- How should we cope with unstable APIs which make use of native
code? The Application Deployment Guidelines [1] don't address
this issue.
For example, the Guidelines stat that
Re: [Mono-list] Application installation on Windows
On Fri, 2006-09-01 at 12:13 +0200, Andreas Färber wrote: The reason I tried is that there is a legacy DOS application running on a Windows 95 system that I would like to replace with a more modern .NET based app, and I need a way of migrating it while still running. Is Windows 2000 or Windows XP unable to run the DOS app? Usually they're able to run DOS apps (except maybe for games which need every bit of memory that DOS provided...). The only alternative I've come up with was exposing the legacy data files as a Windows share and reading them from remote; I'm still figuring out the file format from a local copy so haven't tested that yet - would I get change notifications from such a remote SMB share with FileSystemWatcher? I don't believe FileSystemWatcher will give timely notifications on an SMB share. It would fall back to a polling approach, so you would get change notifications, just not as they happen (and not terribly efficiently either). - Jon ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Garbage-collecting a remoting singleton object in a service?
I am interested in implementing a service (windows service in windows, and using mono-service on linux, I suppose) that hosts a singleton remoting object. As I have read on some docs, no leasing management is needed if no SAO/CAO hosting method is used (returning null in InitializeLifeTimeService method, as I will use a Singleton instance) but, how can I garbage-collect manually this server object on the OnStop() method of the service (so as to create a new instance again on the OnStart method)? I have seen that the ILease.CurrentState property is read-only so I cannot manually set the Lease as Expired from an external (but not remote) object, am I right? Thanks in advance, Andrés [ knocte ] P.S.: Is anyone in the list using the GenuineChannels library in Mono? Does it work? Is there any other stable alternatives? I think I read a message from Rafael Teixera where I understood he was using a similar solution but had scalability problems...? BTW, will Indigo support this kind of channels? Will it be implemented in Mono? -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Garbage-collecting a remoting singleton object in aservice?
Just a query... Why do you need to use a singleton object? We've always used SingleCall objects, and these die after each call. I take it you're talking about a SAO, as the term singleton is usually used to refer to an SAO. We've never found a justification for using a singleton object. Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrés G. Aragoneses [ knocte ] Sent: 01 September 2006 14:36 To: Mono-list@lists.ximian.com Subject: [Mono-list] Garbage-collecting a remoting singleton object in aservice? I am interested in implementing a service (windows service in windows, and using mono-service on linux, I suppose) that hosts a singleton remoting object. As I have read on some docs, no leasing management is needed if no SAO/CAO hosting method is used (returning null in InitializeLifeTimeService method, as I will use a Singleton instance) but, how can I garbage-collect manually this server object on the OnStop() method of the service (so as to create a new instance again on the OnStart method)? I have seen that the ILease.CurrentState property is read-only so I cannot manually set the Lease as Expired from an external (but not remote) object, am I right? Thanks in advance, Andrés [ knocte ] P.S.: Is anyone in the list using the GenuineChannels library in Mono? Does it work? Is there any other stable alternatives? I think I read a message from Rafael Teixera where I understood he was using a similar solution but had scalability problems...? BTW, will Indigo support this kind of channels? Will it be implemented in Mono? -- ___ 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] Garbage-collecting a remoting singleton object in a service?
You can use RemotingServices.Disconnect (obj) for this. Lluis. El dv 01 de 09 del 2006 a les 15:35 +0200, en/na Andrés G. Aragoneses [ knocte ] va escriure: I am interested in implementing a service (windows service in windows, and using mono-service on linux, I suppose) that hosts a singleton remoting object. As I have read on some docs, no leasing management is needed if no SAO/CAO hosting method is used (returning null in InitializeLifeTimeService method, as I will use a Singleton instance) but, how can I garbage-collect manually this server object on the OnStop() method of the service (so as to create a new instance again on the OnStart method)? I have seen that the ILease.CurrentState property is read-only so I cannot manually set the Lease as Expired from an external (but not remote) object, am I right? Thanks in advance, Andrés [ knocte ] P.S.: Is anyone in the list using the GenuineChannels library in Mono? Does it work? Is there any other stable alternatives? I think I read a message from Rafael Teixera where I understood he was using a similar solution but had scalability problems...? BTW, will Indigo support this kind of channels? Will it be implemented in Mono? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Garbage-collecting a remoting singleton object in a service?
Andrés G. Aragoneses [ knocte ] wrote:
I am interested in implementing a service (windows service in windows,
and using mono-service on linux, I suppose) that hosts a singleton
remoting object. As I have read on some docs, no leasing management is
needed if no SAO/CAO hosting method is used (returning null in
InitializeLifeTimeService method, as I will use a Singleton instance)
but, how can I garbage-collect manually this server object on the
OnStop() method of the service (so as to create a new instance again on
the OnStart method)?
To achieve this, you have to register the singleton object manually.
Throw away the service entry from you server's remoting config
and use this code instead (in server's code, of course):
YourServerClass singleton;
OnStart ()
{
singleton = new YourServerClass ();
RemotingServices.Marshal (singleton, objectUri);
}
OnStop ()
{
RemotingServices.Disconnect (singleton);
// do what you called garbage-collect manually.
}
where objectUri is the objectUri-attribute you previously
used in server's remoting config.
Robert
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Garbage-collecting a remoting singleton object in aservice?
Hi, El vie, 01-09-2006 a las 14:53 +0100, Bradley, Peter escribió: Just a query... Why do you need to use a singleton object? We've always used SingleCall objects, and these die after each call. I take it you're talking about a SAO, as the term singleton is usually used to refer to an SAO. We've never found a justification for using a singleton object. And what happend when you want to have (in server side) a shared struct or shared hash hosted in memory for all calls?. For example to keep an array of client sessions at the server. Do you prefer a SingleCall object with static variables instead of singleton object? Thanks -- Carlos Ble Shidix Technologies www.shidix.com/carlosble ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] apache terminating mod_mono?
A little background: I run mod-mono-server with its own init script. I run apache with the MonoRunXSP False flag This allows me to start and stop apache and mod-mono-server independently of each other. I.E. when I take down mod-mono-server apache displays a custom error page informing the user that we are working on the site instead of a message from the browser that no such server exists. On the flip side I can make a change to the apache config and reload with out going through the restart time or session loss on the running mod-mono-server. I recently updated to mono, xsp and mod_mono to 1.1.17 from 1.1.13 and now when I stop apache it kills mod-mono-server. I've tested and the same thing occurs using both unix and tcp sockets. Can anyone advise me on this? Thanks for your time. Mike Glenn ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] apache terminating mod_mono?
OK some digging and debugging turned up this:
If no apache MonoUnixSocket flag is defined in the config then the server tries
to load:
[Fri Sep 01 13:44:54 2006] [warn] Socket file name /tmp/mod_mono_server_global
Where as the man page for mod-mono-server says:
--filename file (mod-mono-server only)
The unix socket file name to listen on. Default value:
/tmp/mod_mono_server
and mod_mono.c has:
MAKE_CMD12 (MonoUnixSocket, filename,
Named pipe file name. Mutually exclusive with MonoListenPort.
Default: /tmp/mod_mono_server
)
I had added this line to the apache config because I was apache/mod_mono were
not communicating with mod-mono-server:
MonoUnixSocket default /tmp/mod_mono_server
this seems to have caused mod_mono.so to think there where two instances of
mod-mono-server/xsp running.
One that was set to MonoRunXSP False and one that was true. I added some
debugging lines to mod_mono.c and heres what I got in the terminate loop:
static apr_status_t
terminate_xsp2 (void *data, char *alias)
{
/* alias may be NULL to terminate all XSPs */
server_rec *server;
module_cfg *config;
apr_socket_t *sock;
apr_status_t rv;
char *termstr = ;
xsp_data *xsp;
int i;
DEBUG_PRINT (0, Terminate XSP);
server = (server_rec *) data;
config = ap_get_module_config (server-module_config, mono_module);
for (i = 0; i config-nservers; i++) {
xsp = config-servers [i];
DEBUG_PRINT (0, XSP Setting: %s, xsp-run_xsp);
if (xsp-run_xsp !strcasecmp (xsp-run_xsp, false))
continue;
...snip...
[Fri Sep 01 13:40:28 2006] [notice] caught SIGTERM, shutting down
[Fri Sep 01 13:40:28 2006] [warn] Terminate XSP
[Fri Sep 01 13:40:28 2006] [warn] XSP Setting: False
[Fri Sep 01 13:40:28 2006] [warn] XSP Setting: True
[Fri Sep 01 13:40:28 2006] [warn] Socket file name /tmp/mod_mono_server
[Fri Sep 01 13:40:28 2006] [warn] try_connect: 0
So in the end I changed mod-mono-server --filename /tmp/mod_mono_server_global
and now things are working again as expected. But it seems that the defaults are
not what the use to be or that the docs need updated.
Mike Glenn
-Original Message-
From: Mike Glenn [mailto:[EMAIL PROTECTED]
Sent: Friday, September 01, 2006 12:00 PM
To: 'Gonzalo Paniagua Javier'; mono-list@lists.ximian.com
Subject: [Mono-list] apache terminating mod_mono?
A little background:
I run mod-mono-server with its own init script.
I run apache with the MonoRunXSP False flag
This allows me to start and stop apache and mod-mono-server
independently of
each other.
I.E. when I take down mod-mono-server apache displays a
custom error page
informing the user that we are working on the site instead of
a message from the
browser that no such server exists. On the flip side I can
make a change to the
apache config and reload with out going through the restart
time or session loss
on the running mod-mono-server.
I recently updated to mono, xsp and mod_mono to 1.1.17 from
1.1.13 and now when
I stop apache it kills mod-mono-server. I've tested and the
same thing occurs
using both unix and tcp sockets.
Can anyone advise me on this?
Thanks for your time.
Mike Glenn
___
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
