[Mono-list] Problems with System.Data.OracleClient
Hello, please could you tell me how System.Data.OracleClient works on Linux Here my environment : OS : SuSE 9.0 with Mono 1.04 and Oracle Client 9.2.0.1 For testing I used the testprogram down on /www.go-mono.com/oracle.html with modification for connecting my oracle database Compilation was succesfull When I run -mono test.exe- I' ve got this message Unhandled Exception: System.DllNotFoundException: oci in 0x00053 (wrapper managed-to-native) OciNativeCalls:OCIEnvCreate (intptr,System.Data.OracleClient.Oci.OciEnvironmentMode,intptr,intptr,i ntptr,intptr,int,intptr) in 0x00020 System.Data.OracleClient.Oci.OciCalls:OCIEnvCreate (intptr,System.Data.OracleClient.Oci.OciEnvironmentMode,intptr,intptr,i ntptr,intptr,int,intptr) in 0x0005d System.Data.OracleClient.Oci.OciEnvironmentHandle:.ctor (System.Data.OracleClient.Oci.OciEnvironmentMode) in 0x0003c System.Data.OracleClient.Oci.OciGlue:CreateConnection (System.Data.OracleClient.OracleConnectionInfo) in 0x0002b System.Data.OracleClient.OracleConnection:Open () in 0x0004f (wrapper remoting-invoke-with-check) System.Data.OracleClient.OracleConnection:Open () in 0x0006a Test:Main (string[]) Then I tried it with OS : SuSE 9.1 with Mono 1.04 and Oracle Client from Version 10g ... same problems will appear :-( what's wrong ? ... does a file like oci.dll on linux exist ? please help me best regards Mike __ This communication contains information which may be confidential. It is for the exclusive use of the intended recipient. If you are not the intended recipient, please note that any distribution, copying or use of this communication or the information in it is prohibited. If you have received this communication in error, please notify us by email or by telephone on +49-5362-9374-0 and then delete the email and any copies of it. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Time problems on Mono
Yes, you can submit a test case that shows we're slow,
so we can check and fix it.
I made some speed tests too and found mono to be slower.
If you have some sample programs that run faster on mono I would be interested.
My test was simple:
// project created on 8/16/2004 at 4:00 PM
using System;
class MainClass
{
public static void Main(string[] args)
{
double sum=0;
for ( int m=0;m9;m++){
for ( int n=0; n=(1000* 1000 * 1000) ;n+=1 )
{
sum *= 1.0;
}
}
}
}
The results was
Under .net 6 secs. Under mono 9 secs, adding --optimize=all did not make a big
difference.
The same program in c++ compiled by g++ -O3 is also about 6 secs.
But the most peculiar thing is that sometimes when compiled by mcs it takes
mono above 2 minutes to finish, I have not found the differencing factor yet.
--
Med venlig hilsen
Martin Hansen
Software Specialist
Center for Software Innovation
Stenager 2
DK-6400 Sønderborg
Tlf: +45 7347 7017
Fax: +45 7347 7001
Email: [EMAIL PROTECTED]
Web: www.cfsi.dk
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problems with System.Data.OracleClient
Oetjen, Michael wrote:
Hello,
please could you tell me how System.Data.OracleClient works on Linux
Here my environment :
OS : SuSE 9.0 with Mono 1.04 and Oracle Client 9.2.0.1
For testing I used the testprogram down on /www.go-mono.com/oracle.html
with modification for connecting my oracle database
Compilation was succesfull
When I run -mono test.exe- I' ve got this message
Unhandled Exception: System.DllNotFoundException: oci
in 0x00053 (wrapper managed-to-native) OciNativeCalls:OCIEnvCreate
(intptr,System.Data.OracleClient.Oci.OciEnvironmentMode,intptr,intptr,i
ntptr,intptr,int,intptr)
in 0x00020 System.Data.OracleClient.Oci.OciCalls:OCIEnvCreate
(intptr,System.Data.OracleClient.Oci.OciEnvironmentMode,intptr,intptr,i
ntptr,intptr,int,intptr)
in 0x0005d System.Data.OracleClient.Oci.OciEnvironmentHandle:.ctor
(System.Data.OracleClient.Oci.OciEnvironmentMode)
in 0x0003c System.Data.OracleClient.Oci.OciGlue:CreateConnection
(System.Data.OracleClient.OracleConnectionInfo)
in 0x0002b System.Data.OracleClient.OracleConnection:Open ()
in 0x0004f (wrapper remoting-invoke-with-check)
System.Data.OracleClient.OracleConnection:Open ()
in 0x0006a Test:Main (string[])
Then I tried it with
OS : SuSE 9.1 with Mono 1.04 and Oracle Client from Version 10g
... same problems will appear :-(
what's wrong ? ... does a file like oci.dll on linux exist ?
please help me
best regards
Mike
Hi,
problem is your program cannot find oracle libraries, so you need to
set up ORACLE environment to run your program correctly.
Example:
export ORACLE_BASE=/opt/oracle
export ORACLE_HOME=$ORACLE_BASE/product/9.2.0.1.0
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_OWNER=oracle
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/opt/oracle/product/9.2.0.1.0/lib
export
CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib:$ORACLE_HOME/network/jlib
Lojza
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] IDE tools for mono on linux
Monodevelop (http://www.monodevelop.com/) is what you need, a port of #Develop to use gtk# basically. Erik On Dec 5, 2004, at 1:17 PM, Amish Munshi wrote: Greetings, Will sharpdevelop run on linux, without modifications? Can I use the existing installed sharpdevelop on windows and execute mono /windows/C/Program\ Files/Sharpdevelop/bin/Sharpdevelop.exe and expect it to work any time soon? I installed from the svn today, but unfortunately it doesnt work as of now. Will we have a tool like VS.NET (Just drag and drop the tools to create web/windows pages). Amish. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Problems with System.Data.OracleClient
Hello Michael, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oetjen, Michael When I run -mono test.exe- I' ve got this message Unhandled Exception: System.DllNotFoundException: oci in 0x00053 (wrapper managed-to-native) OciNativeCalls:OCIEnvCreate ... what's wrong ? ... does a file like oci.dll on linux exist ? oci.dll is mapped to libclntsh.so under Linux (see $MONO_PATH/etc/mono/config). This lib has to be in the path. Joerg. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
--- Colin JN Breame [EMAIL PROTECTED] wrote: Kelly Leahy wrote: (very silly thought indeed for mainstream langauges like C# and VB.NET) we should not expect such support to be useful in real-world applications. Not sure which real-world you are referring to...:) Some languages are more suited to particular tasks than others, with specialised syntax that makes life easy. e.g. I personally wouldn't use C for a task where Perl is more suited. I agree completely. One must use the best tool for the job. I'm referring the the world in which we are trying to match as closely as possible the functionality of a system over which we have no control (MS .NET C# and VB.Net compilers). In this case, it doesn't really make sense to discuss adding features to our compilers that are not going to appear in the MS compilers. If our true goal is to support cross-platform development, then IMHO the only features we should have in our compiler that are not in MS's compiler should be those features that allow access to platform specific items - not new language features that have nothing to do with platform whatsoever. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
--- Colin JN Breame [EMAIL PROTECTED] wrote: Michal Moskal wrote: snip Not that I'm an expert, but the 'common' parts would probably be something like: - a shared symbol table - shared intermediate representation (does mcs or the vb compiler use an intermediate representation? how about ironpython and nemerle?) - shared error reporting mechnism snip All sounds very good to me. Again, however, my question has to be this: Are we trying to build a better compiler system for .NET compatible languages than the one MS has, or are we trying to build a cross-platform compiler that has similar (hopefully the same) features as the MS compilers? I assert the latter. If we want to build a compiler that has all kinds of neat features that the MS compiler doesn't have, that's fine, but I think it should be separate from mcs proper, as mcs proper should act like the MS compiler insofar as that is possible. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
Jonathan, Actually this is part of the proposed spec (partial classes). As I see it from the latest information on MSDN. (http://msdn.microsoft.com/vcsharp/team/language/default.aspx) They have a PDF file with some of the proposed information (http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/Standard.pdf) I don't know if there is a newer release of this document, but it seems that "partial" isplaned to be part of the spec. Yes I believe that you are correct that the compiler needs to support it (a compile time issue not a runtime issue) but they are still separate code files that you compile into one. The multi-assembly namespace is available now though. XAML is just the class definitions laid out in XML. The XAML is compiled either with VB.NET or C# then the two class files are "merged" to form the executable (if my understandingis still correct from the demos). In Longhorn you should also be able to run a XAML file directly (I believe this was demoed as well) which is then compiled and ran like a normal application. But again, the particular language needs to be specified. :-) Don't you love it when these discussions go so far away from the original questions... On a MONO board at that... Anyway, I am still learning and have not been to all of the conferences and training courses yet, but I try to keep up with what I can. Mostly I believe that the above is correct. If not, forgive the ignorance... Like I said I am still learning... Richard Norman Web/Application Developer http://www.jazzynupe.net/blog/ *** Message: 8Date: Thu, 09 Dec 2004 22:43:24 -0500To: [EMAIL PROTECTED] From: "Jonathan Gilbert" [EMAIL PROTECTED]Subject: RE: [Mono-list] Mixing languages within At 04:58 PM 09/12/2004 -0800, Richard Norman wrote: [snip] In .NET 2.0 there is the notion of "partial" classes where for exampleXAML files describe one part of the class and say a VB file describesanother. But again the languages they are compiled with must be the same(Example:http://www.devx.com/dotnet/Article/22603/1954?pf=truehttp://www.devx.com/dotnet/Article/22603/1954?pf=true ) I'm not certain, but I believe this is more of a compiler hack thananything supported innately by .NET. The compiler has to see all theseparate source code files before it can produce the class in IL, and theXAML is translated to C# before the real compilation starts. Jonathan Gilbert
[Mono-list] Re: Eclipse plugins in C# ?
Ecmel Ercan wrote: On Tue, 07 Dec 2004 09:51:35 -0300, Alejandro Mery wrote: i guess he was talking about a syntax highlighting and building-macros to do c#/mono on eclipse, not to run eclipse over mono. No, i know ikvm and also the improve plug-in. I just wanted to know if it is technically feasible to write plug-ins in managed code using C# on a gcj-compiled (native) or java based eclipse. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list I am still wishing someone would write a very cool fairly complete C# mode for eclipse ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
This might give you some ideas: http://logix.livelogix.com/index.html It's python based so, theoretically it could also run on top of IronPython on top of mono. Rodrigo ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] 1.0.5 Yum Repository for FC2
I am having the same problem. Unresolvable chain of dependencies: mono-core 1.0.5-1.novell.8.3 requires mono mono-core-1.0.5-1.novell.8.3 requires mono-complete-devel 1.0.5-1.novell.8.3 Please modify your package selections and try again. Thanks, Weston Sébastien Robitaille wrote: Hi, FYI, my rpm database was corrupted. rpm --rebuilddb corrected the problem. But now, I have another one: # yum install mono-complete Resolving dependencies ..conflict between mono-core and mono Any idea ? Thanks Sébas -Original Message- From: Sébastien Robitaille Sent: Thursday, December 09, 2004 2:15 PM To: Duncan Mak Cc: Mono-List Subject: RE: [Mono-list] 1.0.5 Yum Repository for FC2 Duncan, the header.info file is now accessible, but now I have a Segmentation fault when running yum. Do you have an idea how to solve this ? Thanks Sébas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Duncan Mak Sent: Thursday, December 09, 2004 1:15 PM To: Sébastien Robitaille Cc: Mono-List Subject: Re: [Mono-list] 1.0.5 Yum Repository for FC2 On Thu, 2004-12-09 at 13:05 -0500, Sébastien Robitaille wrote: Hi, I tried to install mono-1.0.5 with Yum on FC2 and I got this error message: Please try again. I just did something, maybe that fixed it. -- Duncan Mak [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mod_mono make error
I just grabbed the latest version of mod_mono from the downloads section, when I run make after running : ./configure --prefix=/usr/local/apache --with-apxs=/usr/local/apache --with-apr-config=/usr/local/apache I get: --- Configuration summary for mod_mono * Installation prefix = /usr/local/apache * Apache version = 1.3 * Apache modules directory = * apxs = /usr/local/apache * mono prefix = /usr * Default MonoApplicationsConfigDir = /mod-mono-applications --- When I run make: The following is as far as it makes it. [EMAIL PROTECTED] mod_mono-1.0.5]# make Making all in src make[1]: Entering directory `/home/voseman/mono/mod_mono-1.0.5/src' if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -I -DAPACHE13 -DEAPI -Wall -DDFLT_MONO_CONFIG_DIR=\"/mod-mono-applicati ons\" -g -O2 -I -DAPACHE13 -DEAPI -MT mod_mono_la-mod_mono.lo -MD -MP -MF ".de ps/mod_mono_la-mod_mono.Tpo" -c -o mod_mono_la-mod_mono.lo `test -f 'mod_mono.c' || echo './'`mod_mono.c; \ then mv -f ".deps/mod_mono_la-mod_mono.Tpo" ".deps/mod_mono_la-mod_mono.Plo"; el se rm -f ".deps/mod_mono_la-mod_mono.Tpo"; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -I -DAPACHE13 -DEAPI -Wall -DDF LT_MONO_CONFIG_DIR=\"/mod-mono-applications\" -g -O2 -I -DAPACHE13 -DEAPI -MT mo d_mono_la-mod_mono.lo -MD -MP -MF .deps/mod_mono_la-mod_mono.Tpo -c mod_mono.c -fPIC -DPIC -o .libs/mod_mono_la-mod_mono.o mod_mono.c:378: conflicting types for `apr_sockaddr_info_get' /usr/local/include/apr_network_io.h:394: previous declaration of `apr_sockaddr_i nfo_get' mod_mono.c: In function `apr_sockaddr_info_get': mod_mono.c:400: structure has no member named `addrlen' mod_mono.c:401: structure has no member named `addr' mod_mono.c:402: structure has no member named `addr' mod_mono.c:403: structure has no member named `addr' mod_mono.c: At top level: mod_mono.c:413: warning: static declaration for `apr_socket_connect' follows non -static mod_mono.c: In function `apr_socket_connect': mod_mono.c:417: structure has no member named `addr' mod_mono.c:417: structure has no member named `addrlen' mod_mono.c: At top level: mod_mono.c:425: warning: static declaration for `apr_socket_send' follows non-st atic mod_mono.c: In function `apr_socket_send': mod_mono.c:431: dereferencing pointer to incomplete type mod_mono.c: At top level: mod_mono.c:441: warning: static declaration for `apr_socket_recv' follows non-st atic mod_mono.c:459: conflicting types for `apr_wait_for_io_or_timeout' /usr/local/include/apr_support.h:42: previous declaration of `apr_wait_for_io_or _timeout' mod_mono.c: In function `apr_wait_for_io_or_timeout': mod_mono.c:467: dereferencing pointer to incomplete type mod_mono.c:468: dereferencing pointer to incomplete type mod_mono.c: At top level: mod_mono.c:493: conflicting types for `apr_sleep' /usr/local/include/apr_time.h:190: previous declaration of `apr_sleep' mod_mono.c: In function `setup_socket': mod_mono.c:796: dereferencing pointer to incomplete type mod_mono.c:796: warning: implicit declaration of function `ap_psocket' mod_mono.c:797: dereferencing pointer to incomplete type mod_mono.c:798: dereferencing pointer to incomplete type /usr/include/stdlib.h: At top level: mod_mono.c:459: warning: `apr_wait_for_io_or_timeout' defined but not used make[1]: *** [mod_mono_la-mod_mono.lo] Error 1 make[1]: Leaving directory `/home/voseman/mono/mod_mono-1.0.5/src' make: *** [all-recursive] Error 1 Any ideas? Kindest Regards, Shawn Vose
RE: [Mono-list] Mixing languages within
At 09:58 AM 10/12/2004 -0800, Richard Norman wrote: Jonathan, Actually this is part of the proposed spec (partial classes). As I see it from the latest information on MSDN. (http://msdn.microsoft.com/vcsharp/team/language/default.aspx>http://msdn.microsoft.com/vcsharp/team/language/default.aspx) They have a PDF file with some of the proposed information (http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/Standard.pdf>http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/Standard.pdf) I don't know if there is a newer release of this document, but it seems that partial is planed to be part of the spec. Yes, of course, part of the *language* specification. That does not necessarily mean, though, that its implementation is based on a corresponding *framework* feature. To be honest, I haven't done the research, but it seems likely to me that .NET itself does not allow just part of a class to be present in a .netmodule. I could be wrong here, but on that assumption, I meant that the compiler would have to see all parts of the class in a single invocation. If I am right, then for a class split across file1.cs and file2.cs, csc /target:module file1.cs and csc /target:module file2.cs individually would fail, but csc /target:module file1.cs file2.cs would succeed. If am wrong, then .NET itself allows a class's definition to spread across multiple .netmodules. I don't have .NET 2.0, so I can't check :-) And when you refer to XAML being compiled with VB.NET or C#, you must see that this is the same concept as ASP.NET: the XAML file is translated to the actual framework language first, and then the resulting .vb or .cs file is passed to the VB.NET or C# compiler. Jonathan Gilbert ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Bugs in the 1.0.5 and 1.1.3 release RPM
Hello all, From bugs #70416 [1] and #70445 [2], major bugs in the release RPM packages were found that might prevent proper installation. I have local fixes for them already, but I won't be able to roll out new packages until the weekend. Sorry for the inconvenience, [1] http://bugzilla.ximian.com/show_bug.cgi?id=70445 [2] http://bugzilla.ximian.com/show_bug.cgi?id=70416 -- Duncan Mak [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono as an enterprise middleware?
Hi, In our company I'm looking for an alternative for our middleware software (i.e., Progress Webpeed/Appserver). I have been following the Mono project for a while and found it as a very interesting platform. What I would like to know is that if anyone is already using Mono as an enterprise middleware? Have you had any major issues while using Mono in your company/with your customers? What about advantages? What about Mono's ADO.NET support w.r.t. enterprise-wide employment? Is ADO.NET support mature enough in reality (please see the Technical FAQ, question 96)? Thanks, Hermanni Hyytiälä Software Architect Starnet Systems Oy ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
On Thu, 9 Dec 2004 15:38:14 -0800 (PST), Kelly Leahy [EMAIL PROTECTED] wrote: That being said, the question was about mixing code in a single source file. I don't think this should be or would ever be possible. It is easy to mix source languages in one file -- you just need to write a simple preprocessor, that separates the content to files. This has been done with various literate programming systems. Then, if all the compilers involved support IL output, then it is easy to merge -- even if they cannot produce .netmodule, you can ildasm dlls produced, cat them together and ilasm. The problem is cross references -- that is if part in language A needs part in language B and vice versa. Then the compilers need to agree much more -- upon some internal APIs, which seems quite difficult in general. However there is also a possibility to generate language A from specialized languages B and C (that is C# from the string processing languages), and then just run the output through the A compiler. If B and C do not need much information about parts written in A, then it is quite easy -- most of the semantic checks are done by the A compiler. The drawbacks are the need for separate program, but also, which is more important, misleading error messages from the A compiler, for errors in B or C parts. Yet another possibility is to host the B and C compilers inside the A compiler -- they would use A internal representations, produce proper error messages and so on. The hard part is the embedding -- you need to know a lot about the compiler you're going to use. In most cases you'll also need the sources for it. advHowever there are some compilers, like the Nemerle compiler, that support easy embedding of such stuff within separate plugins. I refer you to http://nemerle.org/macrouse.html#embedded-languages for some more info./adv :-) -- : Michal Moskal ::: http://nemerle.org/~malekith/ :: GCS !tv h e+++ b++ : ::: Logic is a nice contrast to the Real World. :: UL$ C++ E--- a? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
The problem is cross references -- that is if part in language A needs part in language B and vice versa. Then the compilers need to agree much more -- upon some internal APIs, which seems quite difficult in general. I understand that in general, it would certainly be possible to build a set of compilers that are aware of each other to the extent that they support nested code. However, this was the problem I was most concerned with when discussing such a design, and again - I don't believe this should or ever could be done with the .NET platform and C#, without a huge effort by MS to make such a thing possible, or a very non-standard implementation of the compilers. In any case, even if we could build such a thing, why would we? Unless MS is going to do the same, or we have plans to eclipse MS in the .NET compiler business (very silly thought indeed for mainstream langauges like C# and VB.NET) we should not expect such support to be useful in real-world applications. After all, at the end of the day, our goal is to build a platform that allows for cross-platform compatibility with MS's .NET implementation, right? Perhaps this means they have features we don't (Win-specific features that cannot be implemented on other platforms) and perhaps this means we have features they don't, but I don't think we should make the source files incompatible. Here, I think features == run-time library stuff, not features == language functionality. If we start going a completely different direction with the language altogether, we suddenly become as obscure as MS would probably like to think we are. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Michal Moskal wrote: The problem is cross references -- that is if part in language A needs part in language B and vice versa. Then the compilers need to agree much more -- upon some internal APIs, which seems quite difficult in general. Not that I'm an expert, but the 'common' parts would probably be something like: - a shared symbol table - shared intermediate representation (does mcs or the vb compiler use an intermediate representation? how about ironpython and nemerle?) - shared error reporting mechnism That way, whenever the language is changed during compilation, the symbol table can be passed on, modified if needed and then returned to the 'compiler host'. The 'compiler host' could then hold all the common bits with the knowledge of how to invoke the 'secondary' compilers when the language is switched, and how to conglomerate each compilers output (IL). Perhaps I should smoke less crack... ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Kelly Leahy wrote: (very silly thought indeed for mainstream langauges like C# and VB.NET) we should not expect such support to be useful in real-world applications. Not sure which real-world you are referring to...:) Some languages are more suited to particular tasks than others, with specialised syntax that makes life easy. e.g. I personally wouldn't use C for a task where Perl is more suited. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Jonathan Gilbert wrote: Not exactly right. You're leaving out an intermediate step: an individual source code file can be compiled to a .netmodule, and .netmodules compiled with different languages can be mixed within a single assembly. Does this mean that a partial class (or part of a class) can be compiled to a .netmodule? or do .netmodules have to contain a complete class? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: Time problems on Mono
Martin Hansen wrote:
Yes, you can submit a test case that shows we're slow,
so we can check and fix it.
I made some speed tests too and found mono to be slower.
If you have some sample programs that run faster on mono I would be interested.
My test was simple:
// project created on 8/16/2004 at 4:00 PM
using System;
class MainClass
{
public static void Main(string[] args)
{
double sum=0;
for ( int m=0;m9;m++){
for ( int n=0; n=(1000* 1000 * 1000) ;n+=1 )
{
sum *= 1.0;
}
}
}
}
The results was
Under .net 6 secs. Under mono 9 secs, adding --optimize=all did not make a big
difference.
The same program in c++ compiled by g++ -O3 is also about 6 secs.
But the most peculiar thing is that sometimes when compiled by mcs it takes
mono above 2 minutes to finish, I have not found the differencing factor yet.
Not meaning to flame but isn't that test a bit of a no brainer for
performance issues, I mean its simply an aggressive loop that will take
any langugage / platform a while to work through
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: Calling back from unmanaged code to managed code.
Paolo Molaro wrote: On 11/29/04 Francis Brosnan Blázquez wrote: I'm trying to make the c# binding for some set of libraries which, in sort, makes petitions to a remote server without blocking the caller. In this context, the caller must suply a handler to manage the server response. Later, when server response arrives, these libraries initiate a thread and execute on it the Caller's handler. The binding works fine until unmanaged code invoke the caller's handler inside the newly thread create. I've made a litle test to show more presiselly what I'm trying to do. The follwing file is the unmanaged pice of code that has two ways to notify the caller throught its handler: 1) by creating a new thread, 2) by using the actual caller's thread. [...] When I execute this test I get the following: $ ./Callback.exe Test init.. Recieved call on unmanaged side.. Calling back to managed side.. Recieved callback on managed side Values: 2 and some text Calling back finished.. Recieved call on unmanaged side.. Calling back to managed side.. ** ERROR **: file mini.c: line 6558 (mono_get_lmf_addr): should not be reached We could easily remove this assert and instead add the code to setup the thread to execute managed code. This won't solve the whole issue, though: the GC needs to know about the thread and its stack limits or it won't work correctly. There is also the issue of deciding which application domain should be set for the new thread. We should probably add a call to a function that does all this setup to the wrapper methods used to go from unmanaged to managed code. lupus If i am reading this correctly, is the lack of support for unmanaged code in mono a case of three incomplete features namely: 1) Lack of Code access security stuff 2) Bits of monos internal setup 3) GC pinning and stack issues If so is it that difficult to add this feature to mono (say once the work on code security is finished) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] 1.1.3 and gmcs
James Fitzsimons wrote: Hi all, Hi James. Do I need to do anything special to enable gmcs in 1.1.3? I tried to clean up my system before installing 1.1.3 and I notice the the $PREFIX/lib/mono/2.0 directory is no longer created and I didn't seem to get a gmcs script installed in the bin directory either? Yeap. ./autogen.sh or ./configure.sh --with-preview=yes. This will create the 2.0 assemblies as well as gmcs support. I hope it helps. -- Regards, Francisco Figueiredo Jr. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] 1.0.5 Yum Repository for FC2
Hi, FYI, my rpm database was corrupted. rpm --rebuilddb corrected the problem. But now, I have another one: # yum install mono-complete Resolving dependencies ..conflict between mono-core and mono Any idea ? Thanks Sébas -Original Message- From: Sébastien Robitaille Sent: Thursday, December 09, 2004 2:15 PM To: Duncan Mak Cc: Mono-List Subject: RE: [Mono-list] 1.0.5 Yum Repository for FC2 Duncan, the header.info file is now accessible, but now I have a Segmentation fault when running yum. Do you have an idea how to solve this ? Thanks Sébas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Duncan Mak Sent: Thursday, December 09, 2004 1:15 PM To: Sébastien Robitaille Cc: Mono-List Subject: Re: [Mono-list] 1.0.5 Yum Repository for FC2 On Thu, 2004-12-09 at 13:05 -0500, Sébastien Robitaille wrote: Hi, I tried to install mono-1.0.5 with Yum on FC2 and I got this error message: Please try again. I just did something, maybe that fixed it. -- Duncan Mak [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] XSD Tool and code generators
Hello: There are any sample on how to write a code generator that could be used with the xsd.exe tool ?? -- Best regards Carlos Guzmán Álvarez Vigo-Spain In the end there can be only one (Highlander) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Hello,
I don't know what the .Net standard would have to say about this
I would like to mix C# and (say) Hypothetical String Processing Language
(HSPL) and (say) Hypothetical Data Processing Language (HDPL) within the
same source code file. e.g.
class mixed {
string normal_c_sharp_method() {
string ret = null;
region is HSPL
some HSPL...modifying ret
/region is HSPL
region is HDPL
some HDPL...modifying ret
/region is HDPL
return ret
}
}
Is this a crazy idea?
This can be either very simple or very hard depending on the level of
integration that you want to achieve.
On the simple end of the spectrum you might have a pre-processor that
handles the regions of HSPL and produces a new C# file that is later
compiled by the C# compiler.
On the other end of the spectrum, you might actually want to consider
extending the Mono C# compiler and instead of doing a simplistic
macro-processing job, you could probably provide integration between the
two worlds.
Miguel.
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
