Re: [Mono-dev] Non-TCP/IP socket access
-Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Andy Hume Sent: 27 July 2011 22:47 To: 'Robert Jordan'; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Non-TCP/IP socket access -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Robert Jordan Sent: 25 July 2011 15:27 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Non-TCP/IP socket access On 25.07.2011 15:24, Andy Hume wrote: Currently other socket types are blocked. This occurs [...] They are really blocked on purpose, but this is not set in stone. You could, for example, provide patches that, for unknown (but not limited to) AFs, simply assume that the specified sockaddr is of the generic type struct sockaddr_storage (see RFC 2553). All Unixes (including OSX) and even Windows support this type. What we'd need is a platform dependent SocketAddress to sockaddr_storage mapping in the runtime. OK. Please find a patch attached. :-) Works well for me. I think it's as you foresaw; use of sockaddr_storage and all... So what's the best way to progress this? :-) Is there something I can do? CC the people who've worked on sockets perhaps? Andy ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Non-TCP/IP socket access
Hi Andy, On 04.08.2011 12:58, Andy Hume wrote: -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Andy Hume Sent: 27 July 2011 22:47 To: 'Robert Jordan'; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Non-TCP/IP socket access -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Robert Jordan Sent: 25 July 2011 15:27 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Non-TCP/IP socket access On 25.07.2011 15:24, Andy Hume wrote: Currently other socket types are blocked. This occurs [...] They are really blocked on purpose, but this is not set in stone. You could, for example, provide patches that, for unknown (but not limited to) AFs, simply assume that the specified sockaddr is of the generic type struct sockaddr_storage (see RFC 2553). All Unixes (including OSX) and even Windows support this type. What we'd need is a platform dependent SocketAddress to sockaddr_storage mapping in the runtime. OK. Please find a patch attached. :-) Works well for me. I think it's as you foresaw; use of sockaddr_storage and all... So what's the best way to progress this? :-) Is there something I can do? CC the people who've worked on sockets perhaps? Please file a bug at http://bugzilla.xamarin.com/ and attach the patch or a github pull request. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Oracle's ODP.NET database provider on Mono
Sorry for the cross-posting, but I sent this email to the wrong list. monodevelop-list and mono-devel-list have similar names. - Forwarded Message - From: Daniel Morgan monodanm...@yahoo.com To: monodevelop-l...@lists.ximian.com monodevelop-l...@lists.ximian.com Sent: Wednesday, August 3, 2011 10:53 AM Subject: [MonoDevelop] Oracle's ODP.NET database provider on Mono Oracle has a web page where people can submit feature requests or vote on requests others have created. The feature requests are Oracle products using .net framework to connect to Oracle databases, such as, ODP.NET which is Oracle's ADO.NET provider to Oracle databases. Title: Support ODP.NET on Mono https://apex.oracle.com/pls/apex/f?p=18357:39:2374078370406663::NO::P39_ID:26141 Title: Thin ODP.NET Driver Description: Like Oracle has a Thin driver for Oracle databases for JDBC, how about creating a Thin driver for Oracle databases for ADO.NET too? https://apex.oracle.com/pls/apex/f?p=18357:39:2374078370406663::NO::P39_ID:26121 The links require you to log in to Oracle Technology Network. If you do not have an Oracle account, it is free to create one. The feature request for Thin ODP.NET Driver says it is Planned for 2011. Please vote for the above feature requests.___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Brian D Low is out of the office.
I will be out of the office starting 08/04/2011 and will not return until 08/10/2011. I will be out of the office fromThursday, August 4th. I will return on the 10th at 7:45am. If this is important please call Kristian or Paul at 808-587-1437, or Robert Aquino at 808-587-1780. Thanks, Brian I will respond to your message when I return. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] `System.Threading.ThreadPool' does not contain a definition for `UnsafeQueueUserWorkItem'
$ ./configure --prefix=/usr/local/src/mono-2.10.3 --with-sgen=yes --with-xen-opt=no --with-ikvm-native=no --with-moonlight=yes --with-moon-gc=sgen $ make ... System.Threading/Timer.cs(341,68): error CS0117: `System.Threading.ThreadPool' does not contain a definition for `UnsafeQueueUserWorkItem' System.Threading/ThreadPool.cs(41,29): (Location of the symbol related to previous error) Compilation failed: 1 error(s), 3 warnings ... -- View this message in context: http://mono.1490590.n4.nabble.com/System-Threading-ThreadPool-does-not-contain-a-definition-for-UnsafeQueueUserWorkItem-tp3719899p3719899.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] `System.Threading.ThreadPool' does not contain a definition for `UnsafeQueueUserWorkItem'
Moonlight development was made on 'master', not 'mono-2-10' so it looks like something was half-backported. It also means that there's no point in building with --with-moonlight=yes using 'mono-2-10' branch (--with-moon-gc too). Sebastien Le 2011-08-04 à 17:22, igouy igo...@yahoo.com a écrit : $ ./configure --prefix=/usr/local/src/mono-2.10.3 --with-sgen=yes --with-xen-opt=no --with-ikvm-native=no --with-moonlight=yes --with-moon-gc=sgen $ make ... System.Threading/Timer.cs(341,68): error CS0117: `System.Threading.ThreadPool' does not contain a definition for `UnsafeQueueUserWorkItem' System.Threading/ThreadPool.cs(41,29): (Location of the symbol related to previous error) Compilation failed: 1 error(s), 3 warnings ... -- View this message in context: http://mono.1490590.n4.nabble.com/System-Threading-ThreadPool-does-not-contain-a-definition-for-UnsafeQueueUserWorkItem-tp3719899p3719899.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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-list] Scope of MainWindow methods Stetic created widgets
Hello, So, MainWindow has an instance of an RTDFile object and you want it to be able to set properties on the MainWindow? I would either pass the RTDFile object your MainWindow class or supply it with a callback ( a delegate such as Action ) that it can call when it needs How's that sound? Ian On 3 Aug 2011, at 23:11, jimevt jae...@gmail.com wrote: My first post! I'm new to C#, mono, gtk#, etc. I'm pulling out my hair on this one, and I can't afford it! I've used the Stetic designer to make a MainWindow that includes a status bar. I also created a public method named SetStatus() to update the status bar ( get context id, pop, then push a new status ). I can call this from within the MainWindow class itself with no problems. I also have another file with a custom class (RTDFile.cs ) that processes files. The MainWindow class has an instance of the RTDFile class. I want the code within the RTDFile class to be able to update the status bar as it works its way through a file, and I can't figure out how to do it! The RTDFile class doesn't know about SetStatus(). My research leads me to believe that I can declare methods as static to make them accessible from other classes, and this appears to work for other methods. However, If I try to declare SetStatus() as static then the SetStatus() method no longer has access to the StatusBar object - I get the error message: An object reference is required for the non-static field, method, or property 'MainWindow.StatusBar' Is there a way to grant the RTDFile class access to the SetStatus() method? Or, if I make SetStaus() static, how to I get an object reference to an existing MainWindow object? Thanks for your help! JimE. -- View this message in context: http://mono.1490590.n4.nabble.com/Scope-of-MainWindow-methods-Stetic-created-widgets-tp3717101p3717101.html Sent from the Mono - General mailing list archive at Nabble.com. ___ 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] Scope of MainWindow methods Stetic created widgets
You could even pass RTDFile the StatusBar object so not to tie it to your MainWindow On 4 Aug 2011, at 07:24, Ian Norton ian.norton-bad...@thales-esecurity.com wrote: Hello, So, MainWindow has an instance of an RTDFile object and you want it to be able to set properties on the MainWindow? I would either pass the RTDFile object your MainWindow class or supply it with a callback ( a delegate such as Action ) that it can call when it needs How's that sound? Ian On 3 Aug 2011, at 23:11, jimevt jae...@gmail.com wrote: My first post! I'm new to C#, mono, gtk#, etc. I'm pulling out my hair on this one, and I can't afford it! I've used the Stetic designer to make a MainWindow that includes a status bar. I also created a public method named SetStatus() to update the status bar ( get context id, pop, then push a new status ). I can call this from within the MainWindow class itself with no problems. I also have another file with a custom class (RTDFile.cs ) that processes files. The MainWindow class has an instance of the RTDFile class. I want the code within the RTDFile class to be able to update the status bar as it works its way through a file, and I can't figure out how to do it! The RTDFile class doesn't know about SetStatus(). My research leads me to believe that I can declare methods as static to make them accessible from other classes, and this appears to work for other methods. However, If I try to declare SetStatus() as static then the SetStatus() method no longer has access to the StatusBar object - I get the error message: An object reference is required for the non-static field, method, or property 'MainWindow.StatusBar' Is there a way to grant the RTDFile class access to the SetStatus() method? Or, if I make SetStaus() static, how to I get an object reference to an existing MainWindow object? Thanks for your help! JimE. -- View this message in context: http://mono.1490590.n4.nabble.com/Scope-of-MainWindow-methods-Stetic-created-widgets-tp3717101p3717101.html Sent from the Mono - General mailing list archive at Nabble.com. ___ 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] Porting MSBuild script to XBuild with ItemGroup
Hi 2011/8/4 Mike Christensen m...@kitchenpc.com: What's the best way to port this code over: Target Name=Build [...] ItemGroup [...] : error : Error initializing task ItemGroup: Not registered task ItemGroup. This is a known bug. See https://bugzilla.novell.com/show_bug.cgi?id=565847 xBuild does currently not support ItemGroups inside Targets. Nils ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Porting MSBuild script to XBuild with ItemGroup
This won't work because I include items that are not yet created until after the target runs.. In other words, if I say: Project ItemGroup Include=Foo*.* / ... Then this ItemGroup gets populated before the Target runs. If Target then goes and creates Foo1.txt and Foo2.txt, those items won't get included in the ItemGroup since they didn't exist when it was evaluated. That's why I need to have this ItemGroup within the Target. When will this bug be fixed? It seems hugely important to support this. Mike On Wed, Aug 3, 2011 at 7:54 PM, Jonathan Pobst mon...@jpobst.com wrote: You need to use the old way of doing thing, the CreateItem task. http://msdn.microsoft.com/en-us/library/s2y3e43x.aspx Jonathan On 8/3/2011 8:29 PM, Mike Christensen wrote: What's the best way to port this code over: Target Name=Build ** Bunch of stuff here ** !-- Crunch Files -- ItemGroup ToCrunch Include=$(BuildDir)/WWW/Scripts/kpc*.js;$(BuildDir)/WWW/Styles/*.css / /ItemGroup Message Importance=High Text=Crunching Script Files... / Exec WorkingDirectory=Crunch Command=java -jar yuicompressor-2.4.2.jar %(ToCrunch.Fullpath) -o %(ToCrunch.Fullpath) --charset utf-8 / /Target If I run this, I get the error: : error : Error initializing task ItemGroup: Not registered task ItemGroup. Which I believe is a known limitation in XBuild. However, if I move the ItemGroup outside the project, the set of files is empty because those files have not been build yet. Thanks! Mike ___ 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] Porting MSBuild script to XBuild with ItemGroup
Oh I think I misread your email.. Looks like the CreateItem task can actually add things to an existing ItemGroup within a Target? If that's the case, that'll probably fix my issue.. Can we bump the priority up on this bug though? It looks pretty old.. I'm still trying to get a Mono enlistment setup, but maybe I can help out when I'm running. xbuild seems like a great project to contribute to. Mike On Thu, Aug 4, 2011 at 12:51 AM, Mike Christensen m...@kitchenpc.com wrote: This won't work because I include items that are not yet created until after the target runs.. In other words, if I say: Project ItemGroup Include=Foo*.* / ... Then this ItemGroup gets populated before the Target runs. If Target then goes and creates Foo1.txt and Foo2.txt, those items won't get included in the ItemGroup since they didn't exist when it was evaluated. That's why I need to have this ItemGroup within the Target. When will this bug be fixed? It seems hugely important to support this. Mike On Wed, Aug 3, 2011 at 7:54 PM, Jonathan Pobst mon...@jpobst.com wrote: You need to use the old way of doing thing, the CreateItem task. http://msdn.microsoft.com/en-us/library/s2y3e43x.aspx Jonathan On 8/3/2011 8:29 PM, Mike Christensen wrote: What's the best way to port this code over: Target Name=Build ** Bunch of stuff here ** !-- Crunch Files -- ItemGroup ToCrunch Include=$(BuildDir)/WWW/Scripts/kpc*.js;$(BuildDir)/WWW/Styles/*.css / /ItemGroup Message Importance=High Text=Crunching Script Files... / Exec WorkingDirectory=Crunch Command=java -jar yuicompressor-2.4.2.jar %(ToCrunch.Fullpath) -o %(ToCrunch.Fullpath) --charset utf-8 / /Target If I run this, I get the error: : error : Error initializing task ItemGroup: Not registered task ItemGroup. Which I believe is a known limitation in XBuild. However, if I move the ItemGroup outside the project, the set of files is empty because those files have not been build yet. Thanks! Mike ___ 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] RemoveDir - XBuild vs MSBuild
https://bugzilla.novell.com/show_bug.cgi?id=710234
https://bugzilla.novell.com/show_bug.cgi?id=710238
These bugs will still get a home with Novell no longer in the picture, correct?
Mike
On Wed, Aug 3, 2011 at 7:09 PM, Mike Christensen m...@kitchenpc.com wrote:
I'll get this filed right away, thanks!
I found another bug which I'll also log:
This works on MSBuild:
RemoveDir Directories=$(BuildDir) Condition= Exists( $(BuildDir) ) /
But causes a parsing error on xbuild. It works if you put in the
value rather than the property.
Thanks!
Mike
On Wed, Aug 3, 2011 at 7:01 PM, Jonathan Chambers jonc...@gmail.com wrote:
Mike,
This seems to be a bug. Please file this, and as a workaround try adding a
Condition attribute with an Exists check:
http://msdn.microsoft.com/en-us/library/7szfhaft.aspx
Something like:
RemoveDir Condition=Exists('Imp/bin') Directories=Imp/bin /
Thanks,
Jonathan
On Wed, Aug 3, 2011 at 9:13 PM, Mike Christensen m...@kitchenpc.com wrote:
I'm trying to port an MSBuild script to XBuild and running into the
following issue:
RemoveDir Directories=Imp/bin /
This crashes and stops building if Imp/bin does not exist. On
MSBuild, it will just do nothing and ignore the command.
Is this a bug? Is there any way I can say delete the directory if it
exists?
Thanks!
Mike
___
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] Porting MSBuild script to XBuild with ItemGroup
(For thread archive purposes since I hate finding a thread on Google with my exact same problem and no one ever bothered to post the solution) Here's the XBuild compatible way of doing what I had below: CreateItem Include=$(BuildDir)/WWW/Scripts/kpc*.js;$(BuildDir)/WWW/Styles/*.css Output TaskParameter=Include ItemName=ToCrunch / /CreateItem Mike On Wed, Aug 3, 2011 at 7:54 PM, Jonathan Pobst mon...@jpobst.com wrote: You need to use the old way of doing thing, the CreateItem task. http://msdn.microsoft.com/en-us/library/s2y3e43x.aspx Jonathan On 8/3/2011 8:29 PM, Mike Christensen wrote: What's the best way to port this code over: Target Name=Build ** Bunch of stuff here ** !-- Crunch Files -- ItemGroup ToCrunch Include=$(BuildDir)/WWW/Scripts/kpc*.js;$(BuildDir)/WWW/Styles/*.css / /ItemGroup Message Importance=High Text=Crunching Script Files... / Exec WorkingDirectory=Crunch Command=java -jar yuicompressor-2.4.2.jar %(ToCrunch.Fullpath) -o %(ToCrunch.Fullpath) --charset utf-8 / /Target If I run this, I get the error: : error : Error initializing task ItemGroup: Not registered task ItemGroup. Which I believe is a known limitation in XBuild. However, if I move the ItemGroup outside the project, the set of files is empty because those files have not been build yet. Thanks! Mike ___ 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
[Mono-list] Dictionary key'ed by Decimal works differently between Mono and .NET
I'm trying to get my unit tests to pass so I can try out my code on Mono, however I ran into some different behavior using the Dictionary class. I've written a stand-alone test case to illustrate the problem. http://pastie.org/2318806 The code will print out True on .NET and False on Mono. I believe this is because I add the key as 0.5m to the dictionary, but I try to look it up with 0.500m. .NET will see these values as equal, Mono will not. Technically the numbers are equal, though they have different levels of precision. However, I'm of the opinion that Mono should emulate .NET where-ever possible. Mike ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Dictionary key'ed by Decimal works differently between Mono and .NET
On 04.08.2011 11:09, Mike Christensen wrote:
I'm trying to get my unit tests to pass so I can try out my code on
Mono, however I ran into some different behavior using the
Dictionary class. I've written a stand-alone test case to
illustrate the problem.
http://pastie.org/2318806
The code will print out True on .NET and False on Mono. I believe
this is because I add the key as 0.5m to the dictionary, but I try to
look it up with 0.500m. .NET will see these values as equal, Mono
will not.
Technically the numbers are equal, though they have different levels
of precision. However, I'm of the opinion that Mono should emulate
.NET where-ever possible.
Well, MS.NET is inconsistent. It returns false in all cases
below, which means that it performs some insane magic inside
Dictionary, something that cannot be reproduced even using
its own comparer.
If you want this fixed, then you should provide some sort
of evidence (a document/blog/etc. that describes MS.NET's
behavior).
using System;
using System.Collections.Generic;
class Test
{
static void Main ()
{
decimal a = 10.5m;
decimal b = Math.Round (10.5m - 10, 3);
Console.WriteLine (a == b);
var map = new Dictionarydecimal, string();
var c = map.Comparer;
Console.WriteLine (c.Equals (a, b));
Console.WriteLine (c.GetHashCode (a) == c.GetHashCode (b));
}
}
Robert
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Dictionary key'ed by Decimal works differently between Mono and .NET
On 4/08/2011 8:04 PM, Robert Jordan wrote:
On 04.08.2011 11:09, Mike Christensen wrote:
I'm trying to get my unit tests to pass so I can try out my code on
Mono, however I ran into some different behavior using the
Dictionary class. I've written a stand-alone test case to
illustrate the problem.
http://pastie.org/2318806
The code will print out True on .NET and False on Mono. I believe
this is because I add the key as 0.5m to the dictionary, but I try to
look it up with 0.500m. .NET will see these values as equal, Mono
will not.
Technically the numbers are equal, though they have different levels
of precision. However, I'm of the opinion that Mono should emulate
.NET where-ever possible.
Well, MS.NET is inconsistent. It returns false in all cases
below, which means that it performs some insane magic inside
Dictionary, something that cannot be reproduced even using
its own comparer.
If you want this fixed, then you should provide some sort
of evidence (a document/blog/etc. that describes MS.NET's
behavior).
using System;
using System.Collections.Generic;
class Test
{
static void Main ()
{
decimal a = 10.5m;
decimal b = Math.Round (10.5m - 10, 3);
Console.WriteLine (a == b);
var map = new Dictionarydecimal, string();
var c = map.Comparer;
Console.WriteLine (c.Equals (a, b));
Console.WriteLine (c.GetHashCode (a) == c.GetHashCode (b));
}
}
Robert
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Looks like you have a typo - that should be 0.5m assigned to a?
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Dictionary key'ed by Decimal works differently between Mono and .NET
On 04.08.2011 12:14, Gareth Pearce wrote:
Looks like you have a typo - that should be 0.5m assigned to a?
Yes, thanks :) It turns out that Mono's Decimal.GetHashCode
is buggy:
using System;
class Test
{
static void Main ()
{
decimal a = 0.5m;
decimal b = Math.Round(10.5m - 10, 3);
Console.WriteLine (a == b);
Console.WriteLine (a.GetHashCode() == b.GetHashCode());
}
}
The output should be true, true, but it's true, false.
Robert
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Application not respecting MONO_EVENTLOG_TYPE environment variable?
Hi, I have a web service running that likes to event log every once in a while (it was originally written to run under IIS). I have experimented with various ways of setting the MONO_EVENTLOG_TYPE environment variable to no avail. I am running mod_mono on Apache 2.2.3 (Red Hat) on RHEL 5.4 with Mono 2.10.2 installed. First of all, the default directory /var/lib/mono/eventlog does not exist in my system. Creating it did not help. Neither did it help so point it at a file in /tmp. I have my web application configured through a .conf file in /etc/httpd/conf.d, which calls MonoSetEnv to define MONO_STRICT_MS_COMPLIANT and MONO_IOMAP (which seem to work). Is there anything obvious that I have overlooked? Best regards, Emil. -- View this message in context: http://mono.1490590.n4.nabble.com/Application-not-respecting-MONO-EVENTLOG-TYPE-environment-variable-tp3718532p3718532.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Scope of MainWindow methods Stetic created widgets
Hello Ian! Thanks for your replies! I tried creating a delegate for the SetStatus() method of the MainWindow, but I couldn't get it to work. If I remember correctly, it was requiring that the SetStatus() method be static which is a problem. I can see where passing the MainWindow ( this ) into the constructor for the RTDFile object should work; the object would then just keep that reference and use it. In the spirit of encapsulation, I like the idea of a callback. First I'll try one for the StatusBar itself. Failing that, I'll try one for the MainWindow. Thanks Again! JimE. -- View this message in context: http://mono.1490590.n4.nabble.com/Scope-of-MainWindow-methods-Stetic-created-widgets-tp3717101p3718639.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Google Native Client support questions
Look here: http://lists.ximian.com/pipermail/mono-devel-list/2011-February/036980.html https://github.com/elijahtaylor/mono Yes, I also think this is cool. :) ~ Doug. On Wed, Aug 3, 2011 at 10:30 PM, Stifu st...@free.fr wrote: Hmm, the way I see it, whether Chrome gets reimplemented as a NaCl module or not doesn't change anything regarding Mono in NaCl. Or am I missing something? philippe.monteil wrote: an interesting statement about Chrome and NaCl from Linus Upson, vice president of engineering for the Chrome team Over time we want to move the entire browser in Native Client. http://news.cnet.com/8301-30685_3-20062115-264.html I still hope that the announced integration of a Mono engine in NaCl will happen as soon as Linus's prediction becomes real :-)! -- View this message in context: http://mono.1490590.n4.nabble.com/Google-Native-Client-support-questions-tp3356623p3715668.html Sent from the Mono - General mailing list archive at Nabble.com. ___ 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] Scope of MainWindow methods Stetic created widgets
Hello Again, Well, passing the MainWindow into the RTDFile constructor does work, though it doesn't seem like the correct way to do things. Callbacks - I was thinking of signal handlers, which aren't the same thing at all. Can you refer me to documentation on creating a call back? Thanks! JimE. -- View this message in context: http://mono.1490590.n4.nabble.com/Scope-of-MainWindow-methods-Stetic-created-widgets-tp3717101p3718845.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Where Did The Gtk# API Documentation Go?
On Mon, Aug 1, 2011 at 6:53 PM, Andres G. Aragoneses kno...@gmail.com wrote: The most recent contributors usually hang out in IRC (irc.gnome.org) channel #gtk#. We are lately very busy finishing up gtk# v3.0 which will have API compatibility with gtk v3.x stack. So busy that we haven't found time yet for the docs, so help is always welcome. Well, please do tell us what we can do to help put the documentation back. Someone should take 10 minutes and fix the most obvious, obnoxious kind of failure. This does not give users any kind of confidence in a project. Many people still use Gtk# 2.x, so, yes, looking forward to Gtk# 3, but please take a moment to do some maintenance. -Doug ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Many processed end with the message Terminated (Abgebrochen)
Hi, I'm running Ubuntu 10.4 Lucid which comes with Mono 2.4.4. I have now upgraded an application of mine from .NET 2.0 to .NET 4.0 and so I needed a newer Mono version. I was pointed to one here [1]. Now I have installed Mono 2.10.1. Everything went fine so far, and my .NET 2.0-based application still works, and those of the .NET 4.0 that I have tested also work correctly. But many times (I couldn't find the scheme but it is reproducible) when a process ends normally, I get the message Terminated (in German: Abgebrochen, I hope the English name is correct) in my terminal window. No more messages, just that one word. What does it mean and how can I get rid of it? It's annoying to see that in the terminal and to get cron e-mails because of it. [1] https://answers.launchpad.net/ubuntu/+source/mono/+question/166955 -- Yves Goergen LonelyPixel nospam.l...@unclassified.de Visit my web laboratory at http://beta.unclassified.de ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Many processes end with the message Aborted (Abgebrochen)
On 04.08.2011 21:52 CE(S)T, Yves Goergen wrote: But many times (I couldn't find the scheme but it is reproducible) when a process ends normally, I get the message Terminated (in German: Abgebrochen, I hope the English name is correct) in my terminal window. No more messages, just that one word. Sorry, I think the correct message is Aborted. I've run it through strace and in the very end, it prints this: (...) close(0)= 0 close(1)= 0 close(2)= 0 fstat(1, 0x7fff75a4ba00)= -1 EBADF (Bad file descriptor) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f19d9864000 write(1, * Assertion at error.c:70, condi..., 57) = -1 EBADF (Bad file descriptor) rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(18814, 18814, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT +++ Abgebrochen It closes stdout, then detects an unmet assertion that it wants to print to stdout but that fails. Then the ABRT signal is unblocked (whatever that means) and finally mono seems to abort itself. Is that normal? It only happens with some programmes and only if they do certain things. This is what an un-aborted end looks like: (...) brk(0x267e000) = 0x267e000 unlink(/dev/shm/mono.19532) = 0 exit_group(0) = ? (no close(0/1/2) here) -- Yves Goergen LonelyPixel nospam.l...@unclassified.de Visit my web laboratory at http://beta.unclassified.de ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] P/Invoke return MonoObject*
I'm currently experimenting with embedding mono into a C++ project. Most of the C++ portion of the code is in a C++ DLL, while the Application just links against this dll. I've been using P/Invoke to call stuff from the library and everything is working fine, except when I want to return a MonoObject*. When some objects are created on the C++ side, I create a mirror of it on the managed side, and keep a reference to the MonoObject on the C++ object. Now I need to define a method that returns this MonoObject as a proper managed object to the C# side. I've been able to do this fine using internal calls, but I can't seem to get it to work with P/Invoke, so the question simply is, is this possible or it just won't work and I need to stick to internal calls? Regards, Xavier ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
