[Mono-dev] Nokia 770
Hi, I'm playing with a Nokia 770. I already installed mono, but when I try to execute a CLI application I get the following: Unhandled Exception: System.IO.FileNotFoundException: mscorlib.resources . One question, looking at /var/lib/install/usr/lib/mono/1.0 I only find mscorlib.dll. Is remoting supported on Nokia 770? Shouldn't I have more dlls under this directory??? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] question on the Socket class
Hi, all!
In the C# code below I try to check during given timeout whether host is
available or not. This code is working fine under .Net with the following
output:
10035
Time: 5,040425 seconds
For the Mono 1.1.13/Debian
10035
Test Failed: 1,660835 seconds
Could somebody explain what I did wrong in my code?
Ignoring of the socket errors #10035 and #10035 is under suspicion, but I
have read in the documentation that these errors can be skipped.
using System;
using System.Net;
using System.Net.Sockets;
using System.Collections;
namespace ConsoleApplication1
{
/// summary
/// Summary description for Class1.
/// /summary
///
class Class1
{
/// summary
/// The main entry point for the application.
/// /summary
[STAThread]
static void Main(string[] args)
{
//
// TODO: Add code to start application here
//
DateTime start = DateTime.Now;
try
{//host 1.1.1.1:8080, timeout 5 seconds
CheckConnection(1.1.1.1, 8080, 5);
}
catch(Exception)
{
Console.Out.WriteLine(Time: +
DateTime.Now.Subtract(start).TotalSeconds.ToString() + seconds);
return;
}
Console.Out.WriteLine(Test failed: +
DateTime.Now.Subtract(start).TotalSeconds.ToString() + seconds);
return;
}
public static void CheckConnection(string host, int port, int
timeout)
{
Socket sock = new Socket(AddressFamily.InterNetwork,
SocketType.Stream,
ProtocolType.Tcp);
bool isConnected = false;
IPHostEntry entries = Dns.GetHostByName(host);
foreach (IPAddress ipAddr in entries.AddressList)
{
sock.Blocking = false;
try
{
sock.Connect(new IPEndPoint(ipAddr,
port));
}
catch (SocketException ex)
{
Console.Out.WriteLine(ex.ErrorCode.ToString());
// ignore errors:
// Resource temporarily unavailable.
// Operation now in progress.
if (ex.ErrorCode != 10035
ex.ErrorCode != 10036)
throw;
}
ArrayList checkWrite = new ArrayList();
checkWrite.Add(sock);
ArrayList checkError = new ArrayList();
checkError.Add(sock);
Socket.Select(null, checkWrite, checkError,
timeout * 100);
sock.Blocking = true;
sock.Close();
isConnected = checkWrite.Count 0;
if (isConnected)
break;
}
if (!isConnected)
throw new Exception();
}
}
}
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Nokia 770
Hi, Well, our app uses resources ... (a lot). Could this be the problem? - Original Message - From: Miguel de Icaza [EMAIL PROTECTED] To: pablosantosluac [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, September 04, 2006 9:08 PM Subject: Re: [Mono-dev] Nokia 770 Hello, I'm playing with a Nokia 770. I already installed mono, but when I try to execute a CLI application I get the following: Unhandled Exception: System.IO.FileNotFoundException: mscorlib.resources . Where is that coming from? We do not have an mscorlib.resources, it might indicate a bug somewhere. One question, looking at /var/lib/install/usr/lib/mono/1.0 I only find mscorlib.dll. Is remoting supported on Nokia 770? Shouldn't I have more dlls under this directory??? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.ServiceProcess API compatibility fixes
Hi, The attached patch fixes some (not all) API compatibility issue in the System.ServiceProcess assembly in preparation for my win32 implementation. Let me know if it's ok to commit. Signed-off-by: Gert Driesen [EMAIL PROTECTED] Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.ServiceProcess API compatibility fixes - try #2
guess it's no good without the patch itself, or is it ;-) - Original Message - From: Gert Driesen [EMAIL PROTECTED] To: 'mono-devel mailing list' mono-devel-list@lists.ximian.com Sent: Tuesday, September 05, 2006 12:37 PM Subject: [PATCH] System.ServiceProcess API compatibility fixes Hi, The attached patch fixes some (not all) API compatibility issue in the System.ServiceProcess assembly in preparation for my win32 implementation. Let me know if it's ok to commit. Signed-off-by: Gert Driesen [EMAIL PROTECTED] Gert serviceprocess.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.ServiceProcess API compatibility fixes - try #2
Hello Gert, I see no problems with this patch as it shouldn't affect the Linux mono-service implementation. Joerg. 2006/9/5, Gert Driesen [EMAIL PROTECTED]: guess it's no good without the patch itself, or is it ;-) - Original Message - From: Gert Driesen [EMAIL PROTECTED] To: 'mono-devel mailing list' mono-devel-list@lists.ximian.com Sent: Tuesday, September 05, 2006 12:37 PM Subject: [PATCH] System.ServiceProcess API compatibility fixes Hi, The attached patch fixes some (not all) API compatibility issue in the System.ServiceProcess assembly in preparation for my win32 implementation. Let me know if it's ok to commit. Signed-off-by: Gert Driesen [EMAIL PROTECTED] Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.ServiceProcess API compatibilityfixes - try #2
- Original Message - From: Jörg Rosenkranz [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: mono-devel mailing list mono-devel-list@lists.ximian.com Sent: Tuesday, September 05, 2006 12:51 PM Subject: Re: [Mono-dev] [PATCH] System.ServiceProcess API compatibilityfixes - try #2 Hello Gert, I see no problems with this patch as it shouldn't affect the Linux mono-service implementation. Now that you bring it up, could you explain how the mono-service implementation works. I've never looked into it. Is it a daemon ? I've been given our windows/unix interoperability for services/eventlog/registry some thought. To allow seemless cross-platform access (from Windows machine to Linux or vice versa) to these base services, we have two options: * either we implement the win32 low-level protocols for services, eventlog and registry on Linux -or- * we implement managed daemons for both Windows and Linux, and use either .NET remoting or web services to access these daemons remotely. The first option would ofcourse be better, as it would not only allow (managed) Linux applications to access these base services on a Windows machine, but it would also allow the native MS tools to access these services on a Linux system. However, I think this would be a *huge* project which cannot be realised within a reasonable timeframe. The second option would not be all that hard to implement. We already have native win32 and linux support for the registry and eventlog in place, and I should have a wrapper for the win32 service implementation ready in a few days or so (if I find enough free time). For Windows, all we'd need is to write either .NET remoting or web services wrappers around these API's. For Linux, we also need to implement a Service Control Manager ourselves (if mono-service doesn't do this already). These daemons could then be packaged as a Mono Management Pack for Windows / Linux. This would definitely give Mono more exposure in corporate environments. I'm just thinking out loud, feel free to bring my feet back on the ground. Gert 2006/9/5, Gert Driesen [EMAIL PROTECTED]: guess it's no good without the patch itself, or is it ;-) - Original Message - From: Gert Driesen [EMAIL PROTECTED] To: 'mono-devel mailing list' mono-devel-list@lists.ximian.com Sent: Tuesday, September 05, 2006 12:37 PM Subject: [PATCH] System.ServiceProcess API compatibility fixes Hi, The attached patch fixes some (not all) API compatibility issue in the System.ServiceProcess assembly in preparation for my win32 implementation. Let me know if it's ok to commit. Signed-off-by: Gert Driesen [EMAIL PROTECTED] Gert ___ 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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.ServiceProcess API compatibilityfixes - try #2
Gert Driesen wrote: * we implement managed daemons for both Windows and Linux, and use either .NET remoting or web services to access these daemons remotely. I already wrote a native (unmanaged) Win32 service wrapper which embeds Mono's runtime and provides the same functionality like MS.NET. I could donate it. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.ServiceProcess API compatibilityfixes - try #2
2006/9/5, Gert Driesen [EMAIL PROTECTED]: Now that you bring it up, could you explain how the mono-service implementation works. I've never looked into it. Is it a daemon ? First it was a C daemon embedding Mono. For easier implementation it was converted to a C# EXE which is run in the background by the mono-service starter script. A service on Windows has a somewhat strange behaviour which I had to mimic on Linux. The service's Main entry point has to run the static ServiceBase.Run method which does all the service handling. This method returns after the last service of this EXE is stopped in the Service Control Manager. To get control from ServiceBase back to mono-service there is an internal callback function named RunService inside of ServiceBase. Mono-service loads the service assembly, registers the callback using Reflection and runs the assembly's entry point. Inside the callback function it does all the Start, Stop, etc. handling. Mono-service is controlled by signals (SIGUSR1, SIGUSR2 and SIGTERM) from the outside. I don't know how to implement this handling on Windows because I haven't done much low level service programming yet. Maybe it's easier to fork the execution in ServiceBase.Run based on the operating system than to implement an equivalent infrastructure on both sides? Joerg. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Error on 'make install' in latest SVN revision
Michael Hutchinson wrote: On 9/3/06, Alejandro Serrano [EMAIL PROTECTED] wrote: MONO_PATH=../../class/lib/net_1_1_bootstrap:$MONO_PATH /home/serras/mono-svn/mono/runtime/mono-wrapper ../../class/lib/net_1_1_bootstrap/gacutil.exe /i ../../class/lib/net_2_0/System.dll /f /root /usr/lib /package 2.0 Failure adding assembly to the cache: The file specified is not a valid assembly. make[7]: *** [install-local] Error 1 I don't know where could this error come from, because there's no error in make. I get this too. It's caused by a runtime change in SVN revision 64801 which has made gactool.exe unable to install 2.0 assemblies. This change should probably be reverted until someone integrates a 2.0 gacutil.exe into the build system. Probably old news, but it works for me in r64927. -- 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] C# source files in mcs tree are now UTF-8
Hi, I commited the patch that converted all C# source files in mcs tree to UTF-8 (without byte order mark). All C# source files are now compiled using UTF-8 by default. Please use UTF-8 in source files because the compiler will decode the files using UTF-8. (Note that this does not affect your own source files, only applies to the mcs tree.) Please don't use UTF-8 byte order marks because that may cause the BOM being left in the middle of the source file by text editors not dealing with the BOM. If you experience problems or bugs because of this patch please correct the caracters in the appropriate source file to use proper UTF-8 characters rather than reverting the entire patch. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Nokia 770
pablosantosluac wrote: Unhandled Exception: System.IO.FileNotFoundException: mscorlib.resources . What is the full stack trace? Check to see whether your code triggers the loading of these resources. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-winforms-list] Extended error reporting for libgdiplus/System.Drawing
Hello Jonathan,
On Mon, 2006-09-04 at 17:57 -0500, Jonathan Gilbert wrote:
Ever since I started working on libgdiplus and the related System.Drawing
bits, I've always been somewhat unimpressed by the error reporting
capabilities of GDI+.
True, still very similar to most of the Win32 API ;-)
I didn't think it would be too hard to make them a
lot better, even without breaking cross-platform compatibility, but I
didn't have the free time to sit down and work it out until now.
My proposal is two added functions to libgdiplus, along with a new GpStatus
value.
GpStatus.ExtendedError (100): Indicates that the last error which
occurred has an extended description accessible through
GdipGetErrorEx ().
GpStatus GdipSetErrorEx (GpStatus status, char *description): Places
the specified status code description into TLS slots allocated
for the purpose and returns GpStatus.ExtendedError. In the event
that TLS slots could not be allocated (a non-fatal error during
GdipStartup ()), GdipSetErrorEx actually simply returns its first
argument, and the feature is transparently disabled.
int GdipGetErrorEx (GpStatus *status, char *description): Copies the
last error set with GdipSetErrorEx into the parameters. Either
parameter can be NULL. If description is not NULL, then it is
assumed to be large enough to store the string. The caller
determines this size by first calling the function with a NULL
pointer for description; the return value is the necessary number
of bytes (including null-terminator) for the buffer.
This extended error status code (GpStatus.ExtendedError) is then detected
in the System.Drawing side. Of course, we would break compatibility if we
added an entry for it to the managed enumeration, but it's easy enough to
test for by casting the Status result to an int. If the GDIPlus.CheckStatus
function finds this extended error status value, then it uses the
GdipGetErrorEx function to get the actual error details. When
System.Drawing is running against Microsoft's GDIPLUS.DLL, it will never
get this value (or so we can reasonably assume) and thus it won't ever try
to call GdipGetErrorEx (which won't be exported by GDIPLUS.DLL, of course).
I have attached a pair of patches which implement this functionality,
paving the way for the translation of error return codes in libgdiplus to
have more meaningful descriptions.
extendederrorreporting.libgdiplus.diff: Apply in /source/trunk/libgdiplus
extendederrorreporting.System.Drawing.diff: Apply in
/source/trunk/mcs/class/System.Drawing
Thoughts?
I don't see why this wouldn't work.
Comments?
Yes.
On a general note, I don't like making big changes this late in the 1.2
beta cycle. No the patch itself isn't big, however it won't be useful
until other large changes are made.
On a technical level:
* this introduce user-visible strings inside libgdiplus - something we
do not have right now. While translation hasn't been a big issue yet (in
Mono source code) it will become one (sooner than later) and should be
addressed as a day-1 issue (i.e. before the patch gets approved).
* while error reporting is weak I can't recall many times where an error
needed a more a detailed explanation. So I'm unsure how much we really
gain (on the Linux side). Evidently this doesn't affect (nor help) the
Windows side (Mono or MS runtime) where most of the System.Drawing
development currently occurs.
If nobody thinks this is a bad idea (and some people
think it is a good idea), I can commit it.
My feeling is that it's not a bad idea *but* this should wait after Mono
1.2 release because it won't help immediately, other things needs to be
addressed and (finally) if we should add this it would be nice to do it
with some refactoring of the current source code.
However it's worth a longer discussion, along with other current issues
in libgdiplus. Are you coming, by any chance, to the Mono Summit ?
Thanks,
Jonathan Gilbert
-
I have included the patches inline in the e-mail as well as attaching them
in gzipped form, because my e-mail client
isn't smart enough to properly encode text attachments with LF-only line
endings. Enjoy.
=== extendederrorreporting.libgdiplus.diff ===
Index: general.c
===
--- general.c (revision 64773)
+++ general.c (working copy)
@@ -52,12 +52,21 @@
extern void cairo_test_xlib_disable_render();
+static pthread_key_t last_error_status_tls_key,
last_error_description_tls_key;
+static BOOL use_extended_error_reporting = TRUE;
+
GpStatus
GdiplusStartup(unsigned long *token, const struct startupInput *input,
struct startupOutput *output)
{
/* don't initialize multiple time, e.g. for each appdomain */
if (!startup) {
startup = TRUE;
+
+ /* Ensure TLS storage for error information. */
+
[Mono-dev] Is there a tool (command line) to read assembly's version number?
the question is in the title... thanks -- Hubert FONGARNAND [EMAIL PROTECTED] Fiducial ___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] Is there a tool (command line) to read assembly's version number?
You could use:monodis --assembly MyAssembly.dll/JacobOn 9/5/06, Hubert FONGARNAND [EMAIL PROTECTED] wrote: the question is in the title... thanks -- Hubert FONGARNAND [EMAIL PROTECTED] Fiducial ___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 listMono-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] Nokia 770
Hello, Well, our app uses resources ... (a lot). Could this be the problem? The best way of tracking this down is writing the smallest possible program that exhibits this behavior. - Original Message - From: Miguel de Icaza [EMAIL PROTECTED] To: pablosantosluac [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, September 04, 2006 9:08 PM Subject: Re: [Mono-dev] Nokia 770 Hello, I'm playing with a Nokia 770. I already installed mono, but when I try to execute a CLI application I get the following: Unhandled Exception: System.IO.FileNotFoundException: mscorlib.resources . Where is that coming from? We do not have an mscorlib.resources, it might indicate a bug somewhere. One question, looking at /var/lib/install/usr/lib/mono/1.0 I only find mscorlib.dll. Is remoting supported on Nokia 770? Shouldn't I have more dlls under this directory??? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Miguel de Icaza [EMAIL PROTECTED] -- Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Nokia 770
Hi Pablo,Are you using Nokia OS 2005 or 2006?Can you provide a simple test program?Everaldo. pablosantosluac wrote:Unhandled Exception: System.IO.FileNotFoundException: mscorlib.resources. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Environment.ProcessorCount
Hi, This looks ok, but I'm not sure all of our platforms define _SC_NPROCESSORS_CONF. Zoltan On 9/5/06, Jon Chambers [EMAIL PROTECTED] wrote: Here is a patch (from a coworker) for Environment.ProcessorCount. Please review. Thanks, Jonathan ___ 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] TestConfiguration.cs is not a common file (2)
Hi, TestConfiguration.cs is currently in mcs/build/common but is only used by Npgsql_test and it's functionality is specific to Npgsql as well. There is no use to have this file in mcs/build/common. I posted this patch to the list two weeks ago but I received no comments. If there will be no objections I'll commit this patch. Kornél TestConfiguration.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono on Linux/Alpha
Hello Zoltan, Well, kind of good news for mono on Linux/Alpha. With small hack to mcs source code I was able to build mcs compiler by modified mcs from sources on Linux/Alpha. :) Still need to understand why it fails at first place. 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] [PATCH] Generate Consts.vb from Consts.cs (3)
Hi, Microsoft.VisualBasic and vbnc are written in VB. Consts.cs contains contants that are usable in these assemblies as well so it is preferable to have a Consts.vb as well. I created cs2vb.pl that is intended to generate Consts.vb from Consts.cs so that only Consts.cs.in has to be maintained by hand. Please review and approve the patch. Kornél Consts.vb.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
