Re: [Mono-dev] upgrading an app
Le vendredi 15 septembre 2006 14:28 -0700, Tom Bombadil a crit: Hi all... We are running into a few problems with a mod_mono/asp.net app (no dlls, nor assemblies, yet) in two different servers using the same NFS volume... If we use server A to update the files in the NFS volume, server B's app will fail. I use NFS too, in order to share .net webapps! asp.net use inotify or gamin to be aware of changes... and those methods doesn't works with NFS... The doc below says that mono picks up changes in the src automatically: http://www.mono-project.com/FAQ:_ASP.NET#My_application_fails_if_I_replace_binaries My question is: how does mono pick up changes in the src files, when we replace them? by the date in the file? by md5 checksum? Also, if we are using a DLL with mod_mono... what's the best way of reloading it: - rm + cp as shown in the URL above; or - just move the file over, and use the control panel, as shown here: http://www.mono-project.com/Mod_mono#Control_panel When i update an app... i always restart them manually! And if you dont mind my curiosity, why do we have delete the DLL? Thanks a lot ;) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Maybe a System.Data.OracleClient.dll bug
You have to have the column as NVarchar, Which is national character
set, It saves all data as unicode (utf8) instead of ASCII
On 9/17/06, David [EMAIL PROTECTED] wrote:
I use System.Data.OracleClient to connect and operate oracle database;
But I find a problem when inserting into oracle database with chinese
character;
Here is a simple exapmle:
using System;
using System.Data ;
using System.Data.OracleClient;
namespace Test{
class MainEntry{
public static void Main(string[] args){
String connString = server=video;User Id=mono;password=jcyjcy;
String insertSql = INSERT INTO test(name) values (:name);
OracleConnection conn = new OracleConnection(connString);
try{
conn.Open();
OracleCommand command = new OracleCommand();
command.Connection = conn;
command.CommandText = insertSql;
command.CommandType = CommandType.Text;
OracleParameter parm = new OracleParameter(:name,
OracleType.VarChar);
// insert a Chinese stiing into oracle database(the string's
length is 4)
parm.Value = 测试插入;
command.Parameters.Add(parm);
command.ExecuteNonQuery();
}
catch(Exception ex){
Console.WriteLine(String.Format(Error is:
{0},ex.Message));
}
finally{
conn.Close();
}
}
}
}
and the create table is :
create table test(name varchar(1000));
in sqlplus :
select * from test;
You will see the result is not we expected,not all the character insert into
the database.
Can't anybody tell me how to resolve this problem?
___
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] upgrading an app
The doc below says that mono picks up changes in the src automatically: http://www.mono-project.com/FAQ:_ASP.NET#My_application_fails_if_I_replace_binaries My question is: how does mono pick up changes in the src files, when we replace them? by the date in the file? by md5 checksum? If the timestamp changes, so its not surprising that you are having problems with NFS, the client is probably caching the time. Also, if we are using a DLL with mod_mono... what's the best way of reloading it: - rm + cp as shown in the URL above; or - just move the file over, and use the control panel, as shown here: http://www.mono-project.com/Mod_mono#Control_panel In Unix it is legal to overwrite a file that is currently open by a process, if you do not rm/cp (which guarantees that the link is broken) you will alter data behind mono's back. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] installer for amd64
I hope this is the right place for this. Sorry if it isn't... I would like just to suggest it would be great to have an installer for amd64, just like that for x86. I have tried to compile mono for ubuntu amd64 and it's really a hell. Specially, I couldn't make work monodevelop. In gentoo it was also impossible to me... I have compiled successfully quite a lot of programs in both distributions, but mondevelop is really, in my opinion, very complicated. Having to install a linux version for x86, to me is not an option... Thanks for your attention. __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Sharing build specs between MS VS .net 2005 and mono on Linux
On 9/15/06, Mads Bondo Dydensborg [EMAIL PROTECTED] wrote: fredag 15 september 2006 12:17 skrev Leszek Ciesielski: As for now, company I'm working for is using NAnt together with custom script that generates VS2005 projects from the NAnt *.build files. (Would you care to share you scripts, btw?) Unfortunately, I can not :-( ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Specifying culture, version, etc, for gmcs
Hi there I have a MSVSNET 2005 build file, which I am trying to get xbuild to build. Reference Include=DBC.Data, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL SpecificVersionFalse/SpecificVersion HintPath..\..\BIN\DBC.Data.dll/HintPath /Reference When running: $ xbuild DBC.ORM.csproj /verbosity:diag /t:Build /p:Configuration=Debug I get calls gmcs with reference specs like this: /reference:DBC.Data, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL which of course make gmcs barf: : warning CS2002: Source file `Version=1.0.0.0,' specified multiple times : warning CS2002: Source file `Culture=neutral,' specified multiple times : warning CS2002: Source file `processorArchitecture=MSIL' specified multiple times and : error CS2001: Source file `Version=1.0.0.0,' could not be found : error CS2001: Source file `Culture=neutral,' could not be found : error CS2001: Source file `processorArchitecture=M My question is this: How do I specify this to gmcs - or is it needed at all? Thanks in advance, Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch for System.Net/WebException.cs
Hello.
The following code reveils 2 problems in subj: wrong initial value for
Status, and incompatibility with .Net serialization. To check the
latter, run test on .net, rename out.xml into in.xml and run test on
mono. After applying the patch the test passes and initial value for
Status is the same.
using System;
using System.Runtime.Serialization.Formatters.Soap;
using System.Net;
using System.IO;
namespace dumb_GH20
{
class Program
{
static void Main (string[] args)
{
WebException def = new WebException ();
Console.Out.Write (def.Status);
WebException e = new WebException (message,
new Exception (inner), WebExceptionStatus.PipelineFailure,
null);
SoapFormatter f = new SoapFormatter ();
FileStream fs = new FileStream (out.xml,
FileMode.CreateNew);
f.Serialize (fs, e);
WebException e1 = (WebException) f.Deserialize
(new FileStream (in.xml, FileMode.Open));
}
}
}
Thank you.
Andrew.
WebException.patch
Description: WebException.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Maybe a System.Data.OracleClient.dll bug
在06-9-18，John Anderson [EMAIL PROTECTED] 写道： You have to have the column as NVarchar, Which is national characterset, It saves all data as unicode (utf8) instead of ASCIIYes, I've also tried nvarchar2, it also have the same problem You cat try the above my code.my oracle database is also using utf8so, I think this maybe a bug ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fwd: COM Interop Bug Fix Patch
Hi, This is ok to check in. Zoltan On 9/18/06, Jon Chambers [EMAIL PROTECTED] wrote: Attached an updated patch. These changes are committed under MIT/X11 license, as specified in the revised ChangeLog. -- Forwarded message -- From: Jon Chambers [EMAIL PROTECTED] Date: Sep 15, 2006 4:08 PM Subject: COM Interop Bug Fix Patch To: Mono Devel List mono-devel-list@lists.ximian.com Attached is a patch to fix a few issues. It fixes a case where the interface wasn't found for a given method, fixes NULL case BSTR/MonoString conversion, and uses cdecl on platforms other than windows. This is allows for interaction with MainWin built COM components on other platforms, and is the beginning of support for XPCOM. - 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
Re: [Mono-dev] upgrading an app
Ok Sounds good. I was trying to avoid restarting the app manually, to avoid the downtime, but I guess this is the safest thing to do. Thanks Hubert and Miguel for your replies! Cheers ;) Hubert FONGARNAND wrote: Le vendredi 15 septembre 2006 à 14:28 -0700, Tom Bombadil a écrit : Hi all... We are running into a few problems with a mod_mono/asp.net app (no dlls, nor assemblies, yet) in two different servers using the same NFS volume... If we use server A to update the files in the NFS volume, server B's app will fail. I use NFS too, in order to share .net webapps! asp.net use inotify or gamin to be aware of changes... and those methods doesn't works with NFS... The doc below says that mono picks up changes in the src automatically: http://www.mono-project.com/FAQ:_ASP.NET#My_application_fails_if_I_replace_binaries My question is: how does mono pick up changes in the src files, when we replace them? by the date in the file? by md5 checksum? Also, if we are using a DLL with mod_mono... what's the best way of reloading it: - rm + cp as shown in the URL above; or - just move the file over, and use the control panel, as shown here: http://www.mono-project.com/Mod_mono#Control_panel When i update an app... i always restart them manually! And if you dont mind my curiosity, why do we have delete the DLL? Thanks a lot ;) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Ce message et les �ventuels documents joints peuvent contenir des informations confidentielles. Au cas o� il ne vous serait pas destin�, nous vous remercions de bien vouloir le supprimer et en aviser imm�diatement l'exp�diteur. Toute utilisation de ce message non conforme � sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'�tant pas s�curis�es, l'int�grit� de ce message n'est pas assur�e et la soci�t� �mettrice ne peut �tre tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] upgrading an app
If the timestamp changes, so its not surprising that you are having problems with NFS, the client is probably caching the time. Another question regarding this: What's the condition that mono uses to pickup the change in the timestamp? - if timestamp changed? or - if new timestamp previous timestamp I'm asking because this last one would be bad if we are trying recover from backup for example. Thanks ;) Miguel de Icaza wrote: The doc below says that mono picks up changes in the src automatically: http://www.mono-project.com/FAQ:_ASP.NET#My_application_fails_if_I_replace_binaries My question is: how does mono pick up changes in the src files, when we replace them? by the date in the file? by md5 checksum? If the timestamp changes, so its not surprising that you are having problems with NFS, the client is probably caching the time. Also, if we are using a DLL with mod_mono... what's the best way of reloading it: - rm + cp as shown in the URL above; or - just move the file over, and use the control panel, as shown here: http://www.mono-project.com/Mod_mono#Control_panel In Unix it is legal to overwrite a file that is currently open by a process, if you do not rm/cp (which guarantees that the link is broken) you will alter data behind mono's back. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] C# to x86 assembly code?
Hi all, I want to know if there is a tool to compile a C# program into a x86 assembly code? Thanx in advance, ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# to x86 assembly code?
Hi Auge, You can currently use Mono AOT compilation (Ahead-Of-Time; mono --aot I think) in order to get a precompiled binary, It'll cause your application to run faster, between some other things. Hope this helps. Regards, 2006/9/18, Auge Mike [EMAIL PROTECTED]: Hi all, I want to know if there is a tool to compile a C# program into a x86 assembly code? Thanx in advance, ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcos - http://www.youcannoteatbits.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# to x86 assembly code?
But to complete the picture, it will still need the Mono runtime. :) On 9/18/06, Marcos Cobeña [EMAIL PROTECTED] wrote: Hi Auge, You can currently use Mono AOT compilation (Ahead-Of-Time; mono --aot I think) in order to get a precompiled binary, It'll cause your application to run faster, between some other things. Hope this helps. Regards, 2006/9/18, Auge Mike [EMAIL PROTECTED]: Hi all, I want to know if there is a tool to compile a C# program into a x86 assembly code? Thanx in advance, ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcos - http://www.youcannoteatbits.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# to x86 assembly code?
Thanks, forgot it! :-) 2006/9/18, Rafael Teixeira [EMAIL PROTECTED]: But to complete the picture, it will still need the Mono runtime. :) On 9/18/06, Marcos Cobeña [EMAIL PROTECTED] wrote: Hi Auge, You can currently use Mono AOT compilation (Ahead-Of-Time; mono --aot I think) in order to get a precompiled binary, It'll cause your application to run faster, between some other things. Hope this helps. Regards, 2006/9/18, Auge Mike [EMAIL PROTECTED]: Hi all, I want to know if there is a tool to compile a C# program into a x86 assembly code? Thanx in advance, ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcos - http://www.youcannoteatbits.org ___ 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 -- Marcos - http://www.youcannoteatbits.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# to x86 assembly code?
Hi Marcos,
Yes this can help! But what I am looking for is something like the following
code. Is there any possibility to achive that while debugging mono
application ??
Thanx in advance :)
int Add(int x, int y)
{
pushedi
0001 pushesi
0002 pushebx
0003 pushebp
0004 mov ebx,ecx
0006 mov esi,edx
0008 cmp dword ptr ds:[001AA30Ch],0
000f je 0016
0011 call769AF339
0016 xor edi,edi
0018 xor ebp,ebp
int z = x+y;
IL_: ldarg.0
IL_0001: ldarg.1
IL_0002: add
001a lea eax,[ebx+esi]
IL_0003: stloc.1
001d mov ebp,eax
return z;
IL_0004: ldloc.1
IL_0005: stloc.0
001f mov edi,ebp
}
IL_0006: ldloc.0
IL_0007: ret
0021 mov eax,edi
0023 pop ebp
0024 pop ebx
0025 pop esi
0026 pop edi
0027 ret
From: Marcos Cobeña [EMAIL PROTECTED]
To: Auge Mike [EMAIL PROTECTED]
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] C# to x86 assembly code?
Date: Mon, 18 Sep 2006 20:44:50 +0200
Hi Auge,
You can currently use Mono AOT compilation (Ahead-Of-Time; mono
--aot I think) in order to get a precompiled binary, It'll cause your
application to run faster, between some other things.
Hope this helps.
Regards,
2006/9/18, Auge Mike [EMAIL PROTECTED]:
Hi all,
I want to know if there is a tool to compile a C# program into a x86
assembly code?
Thanx in advance,
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Marcos - http://www.youcannoteatbits.org
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# to x86 assembly code?
At 08:44 PM 18/09/2006 +0200, Marcos wrote: Hi Auge, You can currently use Mono AOT compilation (Ahead-Of-Time; mono --aot I think) in order to get a precompiled binary, It'll cause your application to run faster, between some other things. More specifically, it will cause the application to start up faster. The actual run speed in practice shouldn't be noticeably different from on-the-fly JITted code. It's the same engine, after all, emitting the code. :-) In theory, when doing ahead-of-time compilation, the compiler can do more expensive optimizations and possibly produce better machine code. On the flip side, theory also says that the JIT can make certain assumptions that make the output code simpler or faster when it can see the whole picture -- the application when it is actually running. I believe inlining falls into this category, since calls into other assemblies are susceptible to the other assembly being swapped for a different version, but at runtime that problem disappears since once loaded, the assembly is guaranteed to remain the same version (and remain loaded, too). I don't know to what extent mono takes advantage of either of these points. Jonathan Gilbert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] About Sebastien blog Gendarme gains XML support, more...
At 01:32 PM 18/09/2006 -0300, Rafael Teixeira wrote:
From the high number of UseStringEmptyRule hits in the example report,
I think we can add some magic to gmcs/mcs, so that when run with
-optimize it could automatically generate:
x = String.Empty;
from any
x = ;
it finds. And after that we should compile all mono managed libs with
optimization turned on.
Just a bit of my craziness... :)
I'm a bit confused by this suggestion. My understanding is that at assembly
load time, the JIT interns all string literals that are present in the
module, canonicalizing them, and that therefore the two statements above
are 100% identical, semantically at least. For instance,
class MainClass
{
static void Main()
{
string from_literal = ;
System.Console.WriteLine(
ReferenceEquals(from_literal, string.Empty));
}
}
This sample program outputs True. This automatic interning of strings is
crucial for string 'switch' blocks to work. Also, it seems to me that 'x =
' will perform better (on the order of a couple of clock cycles) than 'x
= string.Empty', since the former is resolved to a constant assignment (a
constant value, really, propagated to the use of variable 'x') at JIT time
while the latter, barring some special-case optimization in the JIT, will
get translated to a load from a static field.
I also happen to think that 'x = ' is more readable than 'x =
string.Empty'. :-)
Do you know of a compelling reason to use 'x = string.Empty' over 'x = '?
Jonathan Gilbert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Fwd: About Sebastien blog Gendarme gains XML support, more...
Sorry forgot to cc the list.
I may have the details wrong, so anyone better informed please correct
my ramblings on why using String.Empty is more desirable over using
the literal, if needed.
:)
-- Forwarded message --
Wrom: WFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVR
Date: Sep 18, 2006 4:56 PM
Subject: Re: [Mono-dev] About Sebastien blog Gendarme gains XML
support,more...
To: Jonathan Gilbert [EMAIL PROTECTED]
inline
On 9/18/06, Jonathan Gilbert [EMAIL PROTECTED] wrote:
At 01:32 PM 18/09/2006 -0300, Rafael Teixeira wrote:
From the high number of UseStringEmptyRule hits in the example report,
I think we can add some magic to gmcs/mcs, so that when run with
-optimize it could automatically generate:
x = String.Empty;
from any
x = ;
it finds. And after that we should compile all mono managed libs with
optimization turned on.
Just a bit of my craziness... :)
I'm a bit confused by this suggestion. My understanding is that at assembly
load time, the JIT interns all string literals that are present in the
module, canonicalizing them, and that therefore the two statements above
are 100% identical, semantically at least. For instance,
class MainClass
{
static void Main()
{
string from_literal = ;
System.Console.WriteLine(
ReferenceEquals(from_literal, string.Empty));
}
}
This sample program outputs True. This automatic interning of strings is
crucial for string 'switch' blocks to work. Also, it seems to me that 'x =
' will perform better (on the order of a couple of clock cycles) than 'x
= string.Empty', since the former is resolved to a constant assignment (a
constant value, really, propagated to the use of variable 'x') at JIT time
while the latter, barring some special-case optimization in the JIT, will
get translated to a load from a static field.
AFAIK, String.Empty is interned just once, each literal has to be
interned in its turn when the method body it is contained is jitted.
Also the literal is embedded in the IL as many times as it appear
in the code, so it is costing space in the image. To top it all, the
JIT in reality knows string.Empty is constant, and generates native
code that is as fast or faster than the constant assignment (as it
doesn't have to create the in-stack reference to the interned
literal).
I also happen to think that 'x = ' is more readable than 'x =
string.Empty'. :-)
That's is why I suggested for the compiler to do the translation, so
that your source could be kept in the less optimized form. See that
Gendarme is looking at your compiled IL, not your source files, when
pointing out the optimization rule isn't being followed.
Do you know of a compelling reason to use 'x = string.Empty' over 'x = '?
Jonathan Gilbert
--
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
--
Rafael Monoman Teixeira
---
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. George Bernard Shaw
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# to x86 assembly code?
On Mon, 2006-09-18 at 14:27 -0500, Jonathan Gilbert wrote: At 08:44 PM 18/09/2006 +0200, Marcos wrote: Hi Auge, You can currently use Mono AOT compilation (Ahead-Of-Time; mono --aot I think) in order to get a precompiled binary, It'll cause your application to run faster, between some other things. More specifically, it will cause the application to start up faster. The actual run speed in practice shouldn't be noticeably different from on-the-fly JITted code. It's the same engine, after all, emitting the code. :-) More specifically, it *might* speed things up, and it might not. There was a .NET developer blog (last year?) that did some timing analysis for .NET, and found that for *cold* starts, the JIT was _faster_ than NGEN-generated code (the equivalent of `mono --aot`). Why? Because IL is smaller than x86 assembly, so less data needed to be read from disk, and the JIT was fast enough that it didn't slow things down in that case. On the flip side, for *warm* starts (i.e. the NGEN code was already in the OS disk cache), NGEN code was faster than JIT code (as the OS didn't have to hit the disk). Then there are other issues (the JIT can do direct method calls, while NGEN/AOT code needs to go through an indirection for each method invocation so that the assembly loader can fixup method addresses, just like with normal Win32 DLLs and ELF shared libraries). So the only way to know for sure which is faster is to test. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Red Carpet repository
Hi, I'm trying to use the smart package manager to install/update mono. I'm using: SuSE 10.0 x86_64 smart ver. 0.42 In the past (a few months ago) I had setup smart to use this URL: http://go-mono.com/download/mono/suse-100-x86_64 But now there is no such an URL. smart reports: http://go-mono.com/download/mono/suse-100-x86_64/packageinfo.xml.gz: Not Found The directory /download on the server is not browsable, so I can not figure it out by myself. What is the right URL for the packageinfo.xml.gz file for SuSE 10.0 x86_64? Thanks -- -- Svetoslav Milenov (Sunny) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] App_Code
hello there,I know someone asked it befere, but i still haven't found solution.How to make my asp.net 2.0 web page 'automagically' compile dll's (and see the inner Types) in the App_Code folder (as it used to be in VS.NET 2005) ? Any workarounds ?regards,Tomasz Kubacki-- avoid reality at all costs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
