Re: [Mono-dev] What is the state of the Deveel.Pim
Hi miguel,I already talked with Antonello, he told me what i wanted to know. It seems that he was out of the mailing list so i will post the revelevant parts of his mail for others that might look for the same thing in the future. Deveel.Pim is a good, fast and stable library based on a CSharpCCgrammar (look at http://sourceforge.net/projects/csharpcc orhttp://www.deveel.com/projects/csharpcc): it can even parse vCards or iCal events from strings of files in standard or Outlook form (thediffer specially on vCard format...); it also creates compliant vCardand iCal formatted text that you can manage as you like.Deveel.Pim is a small project that I wrote in two days I was bored andreleased open-source (under MIT/X11 license) for Mono for make itusable from Hula project (since they still use C bindings for managevCard and iCal data). Thank you all.Ricardo Lopes.On 24/10/06, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, I saw a project named Deveel.Pim in the svn, it looks like a parser for vCards/iCals. Can anybody tell me what is the state of this project (does it work :-) ? ), what exactly does it do ? This is a project from Antonello to handle vcards and icals.-- Ricardo Lopes ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Managed DirectX
Hi, I am one of the programmers of the Wine Direct3D implementation, and I wondered if there are any plans to implement Managed DirectX in Mono, and if it is possible to share efforts between wine and mono? I googled around a bit, but couldn't find anything substancial, except that this was discussed for a SOC project, and that you have issues accessing COM objects from mono. This is basically what the wine direct3d code looks like: We have 3 libraries for the various dx versions, ddraw.dll, d3d8.dll and d3d9.dll. Plans are going on for a d3d10.dll. Those libraries offer a binary and source compatible interface to Microsoft's Direct3D user mode interface. We do not implement the kernel-side DDI or gdientry/ddentry interface and we do not plan to do that. ddraw.dll, d3d8.dll and d3d9.dll call our shared wined3d.dll library, which offers d3d9-like COM interfaces. We are considering dropping COM from wined3d because refcounting is a huge pita especially regarding ddraw.dll. WineD3D contains a basically feature-complete Direct3D9c implementation(but still way too buggy), and a software and opengl ddraw implementation(opengl ddraw is still buggy). The interface of this libarary is not stable, and may chance from wine to wine version, although this does not happen often. If you want to use wine for managed directx you can use d3d9.dll, or wined3d directly(which will need stabilization of the interface before though). The COM interface of Direct3D(and the other dx libs) is not terribly complex, and it does not support all the things that makes COM fun. As long as you can dereference a pointer and call a function pointer you should be fine :-) Cheers, Stefan Dösinger pgp98ppTKEBRT.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FirebirdClient 2.0 and mono
Hello, Is there interest on having that sources on the mono svn ?? they work only with .net 2.0 and the equivalent mono version and there are heavy changes on namespaces and directory structure organization compared with the 1.7 sources ( that are the ones currently in mono svn ) I think there is some interest, but we need to think about how much of the code we want to keep inside Mono today. We have recently started to split things up, because having every library in the mono distribution has its share of logistic issues. Recently we moved a lot of the FX 3 stuff to a new module called Olive, and we have created our own stack of crypto stuff in a module called Crimson. I would like to have a new module for this kind of libraries, to keep the Mono core smaller. We would still ship it though. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Our tool running WinForms on Mono 1.1.18
Hello, There are still some minor issues, but I would like to really congratulate you all for the great work you are doing. Could you file bug reports for those issues? it might help if you give a copy of your tool to the Winforms team ([EMAIL PROTECTED]) We have just made an small video (flash) making a tour through some of the tool's features on Linux. 3D graphics (TaoGL) included! :-P You can have a look at our blogsite: http://codicesoftware.blogspot.com/2006/10/plastic-scm-trial-run-on-mono-1118.html Hope you like it! 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
Re: [Mono-dev] Managed DirectX
Stefan Dösinger wrote: I am one of the programmers of the Wine Direct3D implementation, and I wondered if there are any plans to implement Managed DirectX in Mono, and if it is possible to share efforts between wine and mono? Hello. I started on an open implementation of the XNA libraries. Mostly because I was cheesed at the lack of good error messages. I know that isn't Managed DirectX, but Microsoft never really seemed interested in supporting that. The good news is that they're not terribly different from each other. The only catch is that it's implemented in C++/CLI, which at present is really the best way to do it. I wouldn't attempt it in C#, unless you could figure out a better way to do all the calli instructions. I thought at one point about doing a simple wrapper around the COM implementation and doing the rest in C#, but even that's not all that great, and you still have the C++/CLI dependency. Here, I'll give you a good example: -- _device-CreateTexture( width, height, levels, (DWORD) usage, (D3DFORMAT) format, (D3DPOOL) pool, tex, NULL ) -- ...becomes: -- IL_0006: ldarg.0 IL_0007: ldfld valuetype IDirect3DDevice9* Fluggo.Graphics.Direct3D.GraphicsDevice::_device IL_000c: ldarg.1 IL_000d: ldarg.2 IL_000e: ldarg.3 IL_000f: ldarg.susage IL_0011: ldarg.sformat IL_0013: ldarg.spool IL_0015: ldloca.s tex IL_0017: ldc.i4.0 IL_0018: ldarg.0 IL_0019: ldfld valuetype IDirect3DDevice9* Fluggo.Graphics.Direct3D.GraphicsDevice::_device IL_001e: ldind.i4 IL_001f: ldc.i4.s 92 IL_0021: add IL_0022: ldind.i4 IL_0023: calli unmanaged stdcall int32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong) modopt([mscorlib]System.Runtime.CompilerServices.CallConvStdcall)(native int,uint32,uint32,uint32,uint32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong),valuetype _D3DFORMAT,valuetype _D3DPOOL,valuetype IDirect3DTexture9**,void**) -- Here, you can see C++ calculating the address of the pointer to the function, loading it, then issuing a calli. I don't know of a way to do that in C#, at least, not one that will give you any kind of good performance. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
I am working on COM Interop support in mono. Alot of functionality is currently available for calling unmanaged COM objects from managed code (Runtime Callable Wrappers) in mono. I am working on COM Callable Wrappers right now and should have something in svn in the near future. Some details may need to be worked out (for example, I am using the cdecl calling convention on Linux right now instead of stdcall to be compatible with XPCOM). There is also a bug filed on the c# compiler (the issue is actually by design) which prevents mono from building the interop assemblies. If you want to try anything out on mono, you will need to build you interop assemblies with .Net (either by hand or via tlbimp). If you need any other help let me know. Thanks,JonathanOn 10/25/06, Brian Crowell [EMAIL PROTECTED] wrote: Stefan Dösinger wrote: I am one of the programmers of the Wine Direct3D implementation, and I wondered if there are any plans to implement Managed DirectX in Mono, and if it is possible to share efforts between wine and mono? Hello.I started on an open implementation of the XNA libraries. Mostly because I was cheesed at the lack of good error messages. I know that isn't Managed DirectX, but Microsoft never really seemed interested in supporting that. The good news is that they're not terribly different from each other. The only catch is that it's implemented in C++/CLI, which at present is really the best way to do it. I wouldn't attempt it in C#, unless you could figure out a better way to do all the calli instructions. I thought at one point about doing a simple wrapper around the COM implementation and doing the rest in C#, but even that's not all that great, and you still have the C++/CLI dependency. Here, I'll give you a good example:--_device-CreateTexture( width, height, levels, (DWORD) usage, (D3DFORMAT) format, (D3DPOOL) pool, tex, NULL )--...becomes: --IL_0006:ldarg.0IL_0007:ldfldvaluetype IDirect3DDevice9* Fluggo.Graphics.Direct3D.GraphicsDevice::_deviceIL_000c:ldarg.1IL_000d:ldarg.2IL_000e:ldarg.3IL_000f: ldarg.susageIL_0011:ldarg.sformatIL_0013:ldarg.spoolIL_0015:ldloca.s texIL_0017:ldc.i4.0IL_0018:ldarg.0IL_0019:ldfldvaluetype IDirect3DDevice9* Fluggo.Graphics.Direct3D.GraphicsDevice::_device IL_001e:ldind.i4IL_001f:ldc.i4.s 92IL_0021:addIL_0022:ldind.i4IL_0023:calliunmanaged stdcall int32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong) modopt([mscorlib]System.Runtime.CompilerServices.CallConvStdcall)(native int,uint32,uint32,uint32,uint32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong),valuetype _D3DFORMAT,valuetype _D3DPOOL,valuetype IDirect3DTexture9**,void**) --Here, you can see C++ calculating the address of the pointer to the function, loading it, then issuing a calli. I don't know of a way to do that in C#, at least, not one that will give you any kind of good performance. --Brian___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] Managed DirectX
It's worth mentioning that Microsoft's Managed DirectX doesn't use COM interop. They have a library with a simpler C interface that talks to the kernel portion of DirectX that the drivers plug into and the MDX library uses that - it's almost completely seperate from the DirectX that C++ developers use. Richard ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Richard Matthias wrote: It's worth mentioning that Microsoft's Managed DirectX doesn't use COM interop. They have a library with a simpler C interface that talks to the kernel portion of DirectX that the drivers plug into and the MDX library uses that - it's almost completely seperate from the DirectX that C++ developers use. Er... no. I have Managed DirectX installed, and I can find, through ILDASM, pretty much the exact same IL sequence I posted earlier, pointer arithmetic and all. They use hand-written marshaling to the COM interfaces, not to the kernel. In fact, here's the document where they say they did it: http://members.microsoft.com/customerevidence/Common/FileOpen.aspx?FileName=12419_MicrosoftDirectX_CS.doc --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Brian Crowell wrote: Richard Matthias wrote: It's worth mentioning that Microsoft's Managed DirectX doesn't use COM interop. They have a library with a simpler C interface that talks to the kernel portion of DirectX that the drivers plug into and the MDX library uses that - it's almost completely seperate from the DirectX that C++ developers use. Er... no. I have Managed DirectX installed, and I can find, through ILDASM, pretty much the exact same IL sequence I posted earlier, pointer arithmetic and all. They use hand-written marshaling to the COM interfaces, not to the kernel. Careful what you do with ILDASM Brian, at least if you plan on contributing code to the mono project: Do not use the ildasm or equivalent tools program to disassemble proprietary code when you are planning to reimplement a class for Mono. If you have done this, we will not be able to use your code. From the bottom of: http://www.mono-project.com/Contributing -- Michael Schurter ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Michael Schurter wrote: Careful what you do with ILDASM Brian, at least if you plan on contributing code to the mono project: Yes, I know. I mostly just wanted to figure out how they made calls; everything else in my own managed implementation is written from scratch using documentation. Better yet, I throw more useful exceptions. Anyhow, does anyone know of a good way to step around the hand-coded interop problem without using Managed C++ or C++/CLI? --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Am Mittwoch 25 Oktober 2006 19:02 schrieben Sie: A practical example of building a wrapper by hand would be most helpful. Late binding is not an option, and I haven't ever found interface definition files for DirectX9. As far as I know idl files for dx9 do not exist, only the d3d9.h, d3d9types.h and d3d9caps.h(simmilar for other dx parts), but with dx10 ms started using idl files. So from the other replies it sounds like you can use wine for dx, but mono needs some preparation work first. If you need any help just contact me or the wine-devel list :-) Stefan pgpSvOORFEmkq.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed DirectX
Stefan Dösinger wrote: So from the other replies it sounds like you can use wine for dx, but mono needs some preparation work first. If you need any help just contact me or the wine-devel list :-) Well, one option is to use a library written in C++/CLI, compile it with Microsoft's C++ compiler, and then use the resulting library with Mono. That should work. There's just no equivalent all-Mono method. Tell you what. Sometime this week I'll look to release what I have done regarding XNA. It won't be exactly what you want-- in particular, my library depends on a common primitives library-- but it could be a good starting point for a Managed DirectX 9 implementation. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Hey guys,
On the 2.0 profile, Encoding uses the char*/byte* version of encoding
methods to avoid allocating memory. One code path missed this
optimization, I've attached a fix.
This code path ends up being used in Banshee quite a bit on their tree
view (basically, every time the model is queried, this method gets called
in passing String objects to char*).
A few things to think about:
- It might pay to do something on the 1.0 profile as well.
- Paolo, can you comment on how this kind of change works with the moving gc?
-bIndex: Encoding.cs
===
--- Encoding.cs (revision 66966)
+++ Encoding.cs (working copy)
@@ -211,12 +211,18 @@
// Convenience wrappers for GetByteCount.
public virtual int GetByteCount (String s)
{
- if (s != null) {
- char[] chars = s.ToCharArray ();
- return GetByteCount (chars, 0, chars.Length);
- } else {
+ if (s == null)
throw new ArgumentNullException (s);
+#if NET_2_0
+ unsafe {
+ fixed (char* cptr = s) {
+return GetByteCount (cptr, s.Length);
+ }
}
+#else
+ char[] chars = s.ToCharArray ();
+ return GetByteCount (chars, 0, chars.Length);
+#endif
}
public virtual int GetByteCount (char[] chars)
{___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Thanks Ben! --Aaron On Wed, 2006-10-25 at 16:51 -0400, Ben Maurer wrote: Hey guys, On the 2.0 profile, Encoding uses the char*/byte* version of encoding methods to avoid allocating memory. One code path missed this optimization, I've attached a fix. This code path ends up being used in Banshee quite a bit on their tree view (basically, every time the model is queried, this method gets called in passing String objects to char*). A few things to think about: - It might pay to do something on the 1.0 profile as well. - Paolo, can you comment on how this kind of change works with the moving gc? -b ___ 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] Optimize Encoding.GetByteCount
To my understanding, fixed pointers do not participate GC target. And- locally-allocated array anyways lives until its conversion finishes (and probably immediately disposed depending on the JIT optimization)- Usually this conversion do not take long timeSo I guess fixed pointer would work better than possibly being movedfrom nursery area. It's better to not allocate a new array if it can be avoided. From my own code i found that in one of my intensively used methods i allocated a 100byte array each time the method was called. By moving that variable outside the method and just reinitialising it each time i used it (with appropriate locking) memory usage reduced by a large %. Don't rely on the GC to tidy up your mess if you can avoid creating it in the first place :p ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Hi, Well, the point of the Ben's question is, compacting GC is likely to store array in nursery area (likely, since it could be regarded too big to store in nursery area), so nursery allocation and releasing might become faster than fixing string pointer which might slowdown GC. (That's why BenM asked Paolo, as only he would know the best answer ;-) Atsushi Eno Alan McGovern wrote: To my understanding, fixed pointers do not participate GC target. And - locally-allocated array anyways lives until its conversion finishes (and probably immediately disposed depending on the JIT optimization) - Usually this conversion do not take long time So I guess fixed pointer would work better than possibly being moved from nursery area. It's better to not allocate a new array if it can be avoided. From my own code i found that in one of my intensively used methods i allocated a 100byte array each time the method was called. By moving that variable outside the method and just reinitialising it each time i used it (with appropriate locking) memory usage reduced by a large %. Don't rely on the GC to tidy up your mess if you can avoid creating it in the first place :p ___ 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] OS X MACHINE_THREAD_STATE patch for newer 10.4u SDK
This patch fixes problems with building mono for i386 using the new 10.4u SDK that ships with Xcode 2.4. Current SVN builds for i386 under the new SDK, but does not run properly due to changes in MACHINE_THREAD_STATE. It looks like the breakage in source compatibility is intentional on Apple's part and future headers will be similarly broken. I will be submitting the same patch to libgc upstream. -Allan -- Allan Hsu allan at counterpop dot net 1E64 E20F 34D9 CBA7 1300 1457 AC37 CBBB 0E92 C779 Index: libgc/darwin_stop_world.c === --- libgc/darwin_stop_world.c (revision 66738) +++ libgc/darwin_stop_world.c (working copy) @@ -75,12 +75,14 @@ ptr_t lo, hi; #if defined(POWERPC) ppc_thread_state_t state; + mach_msg_type_number_t thread_state_count = PPC_THREAD_STATE_COUNT; #elif defined(I386) i386_thread_state_t state; + mach_msg_type_number_t thread_state_count = i386_THREAD_STATE_COUNT; #else # error FIXME for non-x86 || ppc architectures + mach_msg_type_number_t thread_state_count = MACHINE_THREAD_STATE_COUNT; #endif - mach_msg_type_number_t thread_state_count = MACHINE_THREAD_STATE_COUNT; me = pthread_self(); if (!GC_thr_initialized) GC_thr_init(); @@ -94,7 +96,7 @@ /* Get the thread state (registers, etc) */ r = thread_get_state( p-stop_info.mach_thread, -MACHINE_THREAD_STATE, +GC_MACH_THREAD_STATE_FLAVOR, (natural_t*)state, thread_state_count); if(r != KERN_SUCCESS) ABORT(thread_get_state failed); @@ -193,7 +195,7 @@ ppc_thread_state64_t info; # endif mach_msg_type_number_t outCount = THREAD_STATE_MAX; - r = thread_get_state(thread, MACHINE_THREAD_STATE, + r = thread_get_state(thread, GC_MACH_THREAD_STATE_FLAVOR, (natural_t *)info, outCount); if(r != KERN_SUCCESS) continue; @@ -236,7 +238,7 @@ WARN(This is completely untested and likely will not work\n, 0); i386_thread_state_t info; mach_msg_type_number_t outCount = THREAD_STATE_MAX; - r = thread_get_state(thread, MACHINE_THREAD_STATE, + r = thread_get_state(thread, GC_MACH_THREAD_STATE_FLAVOR, (natural_t *)info, outCount); if(r != KERN_SUCCESS) continue; Index: libgc/include/private/gc_priv.h === --- libgc/include/private/gc_priv.h (revision 66738) +++ libgc/include/private/gc_priv.h (working copy) @@ -366,6 +366,16 @@ # define BZERO(x,n) bzero((char *)(x),(int)(n)) # endif +#if defined(DARWIN) +# if defined(POWERPC) +# define GC_MACH_THREAD_STATE_FLAVOR PPC_THREAD_STATE +# elif defined(I386) +# define GC_MACH_THREAD_STATE_FLAVOR i386_THREAD_STATE +# else +# define GC_MACH_THREAD_STATE_FLAVOR MACHINE_THREAD_STATE +# endif +#endif + /* Delay any interrupts or signals that may abort this thread. Data */ /* structures are in a consistent state outside this pair of calls.*/ /* ANSI C allows both to be empty (though the standard isn't very */ Index: libgc/os_dep.c === --- libgc/os_dep.c (revision 66738) +++ libgc/os_dep.c (working copy) @@ -3702,7 +3702,7 @@ mask, GC_ports.exception, EXCEPTION_DEFAULT, -MACHINE_THREAD_STATE +GC_MACH_THREAD_STATE_FLAVOR ); if(r != KERN_SUCCESS) ABORT(task_set_exception_ports failed); ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XScale?, Mono-devel-list Digest, Vol 18, Issue 62
Hello all,I know mono will run on OMAPs (nokia 770), and I managed to get the same binary to run a Cirrus Logic EP9302.What is required to get mono to run on XScale. I have an application in mind that uses a PXA255, and I would love to use C#... Thanks! J.Cody -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 12:11 AM To: mono-devel-list@lists.ximian.com Subject: Mono-devel-list Digest, Vol 18, Issue 62 Send Mono-devel-list mailing list submissions to mono-devel-list@lists.ximian.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.ximian.com/mailman/listinfo/mono-devel-list or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Mono-devel-list digest..." Today's Topics: 1. Re: Managed DirectX (Brian Crowell) 2. Re: Managed DirectX (Stefan D?singer) 3. Re: Managed DirectX (Brian Crowell) 4. [PATCH] Optimize Encoding.GetByteCount (Ben Maurer) 5. Re: [PATCH] Optimize Encoding.GetByteCount (Atsushi Eno) 6. Re: [PATCH] Optimize Encoding.GetByteCount (Aaron Bockover) 7. Re: [PATCH] Optimize Encoding.GetByteCount (Alan McGovern) 8. Re: [PATCH] Optimize Encoding.GetByteCount (Atsushi Eno) 9. Re: Managed DirectX (Miguel de Icaza) 10. [PATCH] OS X MACHINE_THREAD_STATE patch for newer 10.4u SDK (Allan Hsu) -- Message: 1 Date: Wed, 25 Oct 2006 13:31:07 -0500 From: Brian Crowell [EMAIL PROTECTED] Subject: Re: [Mono-dev] Managed DirectX To: Michael Schurter [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Michael Schurter wrote: Careful what you do with ILDASM Brian, at least if you plan on contributing code to the mono project: Yes, I know. I mostly just wanted to figure out how they made calls; everything else in my own managed implementation is written from scratch using documentation. Better yet, I throw more useful exceptions. Anyhow, does anyone know of a good way to step around the hand-coded interop problem without using Managed C++ or C++/CLI? --Brian -- Message: 2 Date: Wed, 25 Oct 2006 20:49:29 +0200 From: Stefan D?singer [EMAIL PROTECTED] Subject: Re: [Mono-dev] Managed DirectX To: Brian Crowell [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset="iso-8859-1" Am Mittwoch 25 Oktober 2006 19:02 schrieben Sie: A practical example of building a wrapper by hand would be most helpful. Late binding is not an option, and I haven't ever found interface definition files for DirectX9. As far as I know idl files for dx9 do not exist, only the d3d9.h, d3d9types.h and d3d9caps.h(simmilar for other dx parts), but with dx10 ms started using idl files. So from the other replies it sounds like you can use wine for dx, but mono needs some preparation work first. If you need any help just contact me or the wine-devel list :-) Stefan -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061025/f9253082/attachment-0001.bin -- Message: 3 Date: Wed, 25 Oct 2006 14:08:14 -0500 From: Brian Crowell [EMAIL PROTECTED] Subject: Re: [Mono-dev] Managed DirectX To: Stefan D?singer [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan D?singer wrote: So from the other replies it sounds like you can use wine for dx, but mono needs some preparation work first. If you need any help just contact me or the wine-devel list :-) Well, one option is to use a library written in C++/CLI, compile it with Microsoft's C++ compiler, and then use the resulting library with Mono. That should work. There's just no equivalent all-Mono method. Tell you what. Sometime this week I'll look to release what I have done regarding XNA. It won't be exactly what you want-- in particular, my library depends on a common primitives library-- but it could be a good starting point for a Managed DirectX 9 implementation. --Brian -- Message: 4 Date: Wed, 25 Oct 2006 16:51:57 -0400 (EDT) From: "Ben Maurer" [EMAIL PROTECTED] Subject: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount To: mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset="iso-8859-1" Hey guys, On the 2.0 profile, Encoding uses the char*/byte* version of encoding methods to avoid
[Mono-list] xsp in mono 1.1.18
Hello, I'm trying xsp test web server. I've installed mono 1.1.18 and run XSP 2.0 Test Web Server When trying to access http://localhost:8088/1.1/webservice/TestService.asmx I have the following exception: System.DllNotFoundException: libc.so.6 When I'm trying to run XSP Test Web Server (without 2.0), TestService's page works, but service proxy generation doesn't work anyway with the System.InvalidOperationException. Then I decided to try the same on the linux computer. And with xsp the results were the same while with xsp2 it worked. So I have a question. Is xsp supposed to work on windows or should I leave my attempts and use linux? -- Oleg ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Determining if a name is a valid C# name
Hi, Can anyone tell me if there is a way of determining if a string is a valid C# name? e.g. valid for use as a namespace/class name/variable name. Is there a method that does this in the mcs source? Thanks Colin ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Determining if a name is a valid C# name
Here you go: http://www.jaggersoft.com/csharp_standard/9.4.2.htm Enjoy! Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin JN Breame Sent: 25 October 2006 12:15 To: mono-list@lists.ximian.com Subject: [Mono-list] Determining if a name is a valid C# name Hi, Can anyone tell me if there is a way of determining if a string is a valid C# name? e.g. valid for use as a namespace/class name/variable name. Is there a method that does this in the mcs source? Thanks Colin ___ 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] Internal server error
Ok, I've found the source of my problems. Those problems were caused by mod_mono-1.1.18. Both of my linux boxes (Slackware/Gentoo) behaved that way after this upgrade. Downgrading mod_mono to 1.1.17 helped. Now, does anyone have any idea why does mod_mono-1.1.18 break stuff here? Best regards, Jurek Bartuszek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Internal server error
possibly related - i've got an application that dynamically compiles C#. After upgrading to 1.1.18 I get some crashes when compiling - I haven't had time to investigate fully but downgrading to 1.1.17 fixes. This only seems to happen on one of my debian boxes... On Wednesday 25 October 2006 12:49, Jurek Bartuszek wrote: Ok, I've found the source of my problems. Those problems were caused by mod_mono-1.1.18. Both of my linux boxes (Slackware/Gentoo) behaved that way after this upgrade. Downgrading mod_mono to 1.1.17 helped. Now, does anyone have any idea why does mod_mono-1.1.18 break stuff here? Best regards, Jurek Bartuszek ___ 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] Determining if a name is a valid C# name
Thanks Peter - I wasn't aware of the verbatim @. On Wednesday 25 October 2006 12:26, Bradley, Peter wrote: Here you go: http://www.jaggersoft.com/csharp_standard/9.4.2.htm Enjoy! Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin JN Breame Sent: 25 October 2006 12:15 To: mono-list@lists.ximian.com Subject: [Mono-list] Determining if a name is a valid C# name Hi, Can anyone tell me if there is a way of determining if a string is a valid C# name? e.g. valid for use as a namespace/class name/variable name. Is there a method that does this in the mcs source? Thanks Colin ___ 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] Mono and MS Singularity
I'm sure you know MS Singularity (http://research.microsoft.com/os/singularity/). Singularity is something like a kernel (similar to Mach) + a virtual machine (similar to Mono/.NET VM) + a language (similar to C# but with special contract-programming and multithreading features). (Yes, it is much more than this but... ignore that, for the moment). I wonder if anybody has even thought to re-create something like Singularity starting from Mono (or GNU.NET). I mean, something like this: 1) a kernel (Linux, Mach, a managed code kernel written in C#, whatever...) 2) the Mono virtual machine (maybe with support for channels and other stuff) 3) C# or, much better, a contract-programming enabled version of C# (something like Sing#) 4) Something like a message passing system to support concurrent/distributed programming (something like the channels used by Singularity) 5) a (minimalistic) set of device driver written in C#. Do anybody thought about this possibility? From the point of view of Mono, what do you think of Singularity? -- Alessandro Bottoni ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and MS Singularity
You might find some inspiration here: http://jos.sf.net On Wednesday 25 October 2006 12:57, Alessandro Bottoni wrote: I'm sure you know MS Singularity (http://research.microsoft.com/os/singularity/). Singularity is something like a kernel (similar to Mach) + a virtual machine (similar to Mono/.NET VM) + a language (similar to C# but with special contract-programming and multithreading features). (Yes, it is much more than this but... ignore that, for the moment). I wonder if anybody has even thought to re-create something like Singularity starting from Mono (or GNU.NET). I mean, something like this: 1) a kernel (Linux, Mach, a managed code kernel written in C#, whatever...) 2) the Mono virtual machine (maybe with support for channels and other stuff) 3) C# or, much better, a contract-programming enabled version of C# (something like Sing#) 4) Something like a message passing system to support concurrent/distributed programming (something like the channels used by Singularity) 5) a (minimalistic) set of device driver written in C#. Do anybody thought about this possibility? From the point of view of Mono, what do you think of Singularity? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Internal server error
Jurek Bartuszek wrote: Ok, I've found the source of my problems. Those problems were caused by mod_mono-1.1.18. Both of my linux boxes (Slackware/Gentoo) behaved that way after this upgrade. Downgrading mod_mono to 1.1.17 helped. Now, does anyone have any idea why does mod_mono-1.1.18 break stuff here? Because it introduced a regression. Stick with mod_mono-1.1.17 until a new version is available. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Internal server error
Madars Vitolins napisał(a): The same problem for me are from version 1.1.13 on gentoo box. Nor 1.1.16, 17, 18 helps :( Are you running ASP.NET 1.1 projects or ASP.NET 2.0 I'm running mod-mono-server.exe (not 2.0) with MonoRunXSP set to True. Now I know that mod_mono 1.1.17 works good for me, but I didn't test any previous versions. However, I'm about to spend some time on 1.1.13.x as those are maintentance releases. I'll commit the changes to the portage tree as soon as my testing is over (which will probably be today or tomorrow). Best regards, Jurek Bartuszek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and MS Singularity
Alessandro Bottoni wrote: I'm sure you know MS Singularity (http://research.microsoft.com/os/singularity/). Singularity is something like a kernel (similar to Mach) + a virtual machine (similar to Mono/.NET VM) + a language (similar to C# but with special contract-programming and multithreading features). (Yes, it is much more than this but... ignore that, for the moment). I wonder if anybody has even thought to re-create something like Singularity starting from Mono (or GNU.NET). I mean, something like this: 1) a kernel (Linux, Mach, a managed code kernel written in C#, whatever...) 2) the Mono virtual machine (maybe with support for channels and other stuff) I don't know how relevant it is -- for this thread and the other about a C# operating system -- but I was playing around with writing a managed runtime last month, that is, a .NET VM written in C#. Some info here: http://razor.occams.info/blog/?p=41 And code here: http://razor.occams.info/code/repo/?action=viewurl=/mmr/ Though it can run *very* basic .NET programs, it's many man-months away from being able to run anything useful, mostly due to the need to reimplement a good chunk of the class library to fit with the VM. I think anyone interested in doing an OS or something low-level like that ought to consider the huge amount of effort that would be needed to re-create the base class library -- - Joshua Tauberer http://razor.occams.info Strike up the klezmer and start acting like a man. You're about to have a truth-mitzvah. -- The Colbert Report ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Determining if a name is a valid C# name
Invaluable for Windows paths. Saves all those pesky backslashes. :) Peter -Original Message- From: Colin JN Breame [mailto:[EMAIL PROTECTED] Sent: 25 October 2006 12:57 To: Bradley, Peter Cc: mono-list@lists.ximian.com Subject: Re: [Mono-list] Determining if a name is a valid C# name Thanks Peter - I wasn't aware of the verbatim @. On Wednesday 25 October 2006 12:26, Bradley, Peter wrote: Here you go: http://www.jaggersoft.com/csharp_standard/9.4.2.htm Enjoy! Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin JN Breame Sent: 25 October 2006 12:15 To: mono-list@lists.ximian.com Subject: [Mono-list] Determining if a name is a valid C# name Hi, Can anyone tell me if there is a way of determining if a string is a valid C# name? e.g. valid for use as a namespace/class name/variable name. Is there a method that does this in the mcs source? Thanks Colin ___ 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] running two different versions on mono on one box?
I have a need to keep one particular older version of mono on computer, because it's included in a system that I have deployed and need to support, and it not convenient to upgrade those environments at this time, but yet still update applications written against that older version of mono. But, I'd like to run the newest stable version too on my machine. Write now i do this by having a script, a pre-script/post-script that moves the mono binary, libs and /etc/mono to the version I want, runs the program, and then changes it back. There must be an easier way? to selectively run a mono app against a particular mono version, and do so with different versions on the same machine? I am thinking there is a set of environment variables? I can dig on it, but figuring someone can probably post there sol'n in 2 seconds. -tl ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] running two different versions on mono on one box?
Different versions of Mono or even multiple instances of the same version can be installed on different prefixes. The easiest thing to do is to install multiple Mono versions to different locations and execute the mono binary you want to use. It will find it's own class library and GAC. Kornél - Original Message - From: ted leslie [EMAIL PROTECTED] To: Mono-list@lists.ximian.com Sent: Wednesday, October 25, 2006 3:28 PM Subject: [Mono-list] running two different versions on mono on one box? I have a need to keep one particular older version of mono on computer, because it's included in a system that I have deployed and need to support, and it not convenient to upgrade those environments at this time, but yet still update applications written against that older version of mono. But, I'd like to run the newest stable version too on my machine. Write now i do this by having a script, a pre-script/post-script that moves the mono binary, libs and /etc/mono to the version I want, runs the program, and then changes it back. There must be an easier way? to selectively run a mono app against a particular mono version, and do so with different versions on the same machine? I am thinking there is a set of environment variables? I can dig on it, but figuring someone can probably post there sol'n in 2 seconds. -tl ___ 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] Mono and MS Singularity
Colin JN Breame ha scritto: You might find some inspiration here: http://jos.sf.net Thanks. I knew of Java OS (now considered a legacy system by Sun) but not of JOS. It looks like JOS is defunct now or, at least, the development is very, very slow (last events on the wiki date back to 2004). Looking around I found JNode: http://www.jnode.org/ . JNode seems to be alive (last version was realeased on March 2006). Thanks again. Alessandro Bottoni ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] running two different versions on mono on one box?
On 10/25/06, ted leslie [EMAIL PROTECTED] wrote: I have a need to keep one particular older version of mono on computer, because it's included in a system that I have deployed and need to support, and it not convenient to upgrade those environments at this time, but yet still update applications written against that older version of mono. But, I'd like to run the newest stable version too on my machine. Write now i do this by having a script, a pre-script/post-script that moves the mono binary, libs and /etc/mono to the version I want, runs the program, and then changes it back. There must be an easier way? to selectively run a mono app against a particular mono version, and do so with different versions on the same machine? I am thinking there is a set of environment variables? I can dig on it, but figuring someone can probably post there sol'n in 2 seconds. http://www.mono-project.com/Parallel_Mono_Environments ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] running two different versions on mono on one box?
Hello, I'd like to run the newest stable version too on my machine. Write now i do this by having a script, a pre-script/post-script that moves the mono binary, libs and /etc/mono to the version I want, runs the program, and then changes it back. You compile Mono to be installed in a particular prefix, like this: ./configure --prefix=/mono (Thats what I use), so you end up with a Mono in /usr/bin/mono and another in /mono/bin/mono. Then you run a script like this to switch from the standard system mono, to the mono installed in /mono: bash$ source setup-mono The source command there is important, then the setup-mono file looks like this: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mono/lib export C_INCLUDE_PATH=/mono/include export ACLOCAL_PATH=/mono/share/aclocal export PKG_CONFIG_PATH=/mono/lib/pkgconfig:/opt/gnome/lib/pkgconfig:/usr/local/lib/pkgconfig PATH=/mono/bin:$PATH PS1=mono$ Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] running two different versions on mono on one box?
http://www.mono-project.com/Parallel_Mono_Environments Ah, that is a much better answer ;-) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and MS Singularity
Hi Joshua, Alessandro Bottoni wrote: I'm sure you know MS Singularity (http://research.microsoft.com/os/ singularity/). Singularity is something like a kernel (similar to Mach) + a virtual machine (similar to Mono/.NET VM) + a language (similar to C# but with special contract-programming and multithreading features). (Yes, it is much more than this but... ignore that, for the moment). I wonder if anybody has even thought to re-create something like Singularity starting from Mono (or GNU.NET). I mean, something like this: 1) a kernel (Linux, Mach, a managed code kernel written in C#, whatever...) 2) the Mono virtual machine (maybe with support for channels and other stuff) [...] I was playing around with writing a managed runtime last month, that is, a .NET VM written in C#. Some info here: http://razor.occams.info/blog/?p=41 I've been looking into the idea of writing a CLI interpreter myself and I noticed that mcs and gmcs emit a Microsoft-style metadata version string in the assembly. Did you find a way for your assemblies to strictly adhere to the ECMA standard? ECMA-335 3rd and 4th edition both define Standard CLI 2005 whereas [g]mcs uses .NET's proprietary v1.1.4322 and v2.0.50727, in theory making assemblies incompatible with purely ECMA-compliant CLI implementations. Andreas (btw http://www.mono-project.com/ECMA still needs to be updated with 4th ed.!) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and MS Singularity
Hi, Am 25.10.2006 um 14:31 schrieb Joshua Tauberer: Alessandro Bottoni wrote: I'm sure you know MS Singularity (http://research.microsoft.com/os/ singularity/). Singularity is something like a kernel (similar to Mach) + a virtual machine (similar to Mono/.NET VM) + a language (similar to C# but with special contract-programming and multithreading features). (Yes, it is much more than this but... ignore that, for the moment). I wonder if anybody has even thought to re-create something like Singularity starting from Mono (or GNU.NET). I mean, something like this: 1) a kernel (Linux, Mach, a managed code kernel written in C#, whatever...) 2) the Mono virtual machine (maybe with support for channels and other stuff) I don't know how relevant it is -- for this thread and the other about a C# operating system -- but I was playing around with writing a managed runtime last month, that is, a .NET VM written in C#. Some info here: http://razor.occams.info/blog/?p=41 And code here: http://razor.occams.info/code/repo/?action=viewurl=/mmr/ Though it can run *very* basic .NET programs, it's many man-months away from being able to run anything useful, mostly due to the need to reimplement a good chunk of the class library to fit with the VM. I think anyone interested in doing an OS or something low-level like that ought to consider the huge amount of effort that would be needed to re-create the base class library Some months ago there was an admittedly short discussion on the list of Mono's future in the case of a managed Microsoft OS (see the archive) where I mentioned Singularity and pointed out the possibility to port Mono to such an OS in order to run any CLI we like - that would come close to Joshua's managed runtime project. (however I still don't believe Microsoft would put Singulary on the market as such, it's a research project) Concerning the thought of a managed OS, wouldn't that either mean you'd have to write it in assembler and thus architecture-specific or you'd need CLI-specific hardware? I thought I heard for Java there was some research to create a processor that could directly execute Java bytecode, don't have any links though. Anyway, there are a number of both experimental and commercial operating systems out there, each with their unique pros and cons - even if Novell as a widely known company said its OS would in a future version be fully managed, then that would still mean that they would have to re-invent everything from the ground up (resource management, threading etc.) just like any other OS (e.g. Linux) and even if they did and supplied drivers for virtually every device as well as a set of apps then that would still not assure a commercial success in the sense of a large user base. (think BeOS) Same argument as for Singularity. However, this is in no way intended to stop you from proving it can be done. :-) Andreas ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] TabControl
Hi guys, Sorry this question, Who can advice me a good tabcontrol, datagrid and chart assembly's for asp.net ? Sorry this offtopic question :P Jorge ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and MS Singularity
Andreas Färber wrote: Alessandro Bottoni wrote: I'm sure you know MS Singularity (http://research.microsoft.com/os/singularity/). Singularity is something like a kernel (similar to Mach) + a virtual machine (similar to Mono/.NET VM) + a language (similar to C# but with special contract-programming and multithreading features). (Yes, it is much more than this but... ignore that, for the moment). I wonder if anybody has even thought to re-create something like Singularity starting from Mono (or GNU.NET). I mean, something like this: 1) a kernel (Linux, Mach, a managed code kernel written in C#, whatever...) 2) the Mono virtual machine (maybe with support for channels and other stuff) [...] I was playing around with writing a managed runtime last month, that is, a .NET VM written in C#. Some info here: http://razor.occams.info/blog/?p=41 I've been looking into the idea of writing a CLI interpreter myself and I noticed that mcs and gmcs emit a Microsoft-style metadata version string in the assembly. Did you find a way for your assemblies to strictly adhere to the ECMA standard? Strict adherence is something well beyond what I got to the point of thinking about. I was following ECMA-335 June 2006 (to the extent I was following anything). Concerning the thought of a managed OS, wouldn't that either mean you'd have to write it in assembler and thus architecture-specific or you'd need CLI-specific hardware? It turns out (IMO) that the notion of CLI-specific hardware isn't so interesting, or practical. The part of my managed runtime that involves executing IL instructions is pretty minimal compared to the infrastructure necessary to handle the whole type system, for instance. callvirt, castclass, and newobj are all very complicated instructions -- especially compared to native instructions like add, mov, etc. In order to have CLI-specific hardware, you'd really need to have the whole Mono runtime implemented in hardware, and that seems kind of ridiculous. :) -- - Joshua Tauberer http://razor.occams.info Strike up the klezmer and start acting like a man. You're about to have a truth-mitzvah. -- The Colbert Report ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
