Re: [Mono-dev] [Mono-list] Announce: Mono.Fuse 0.2.0 (+ Required mcs & mono patches)
Can you elaborate on the tests you've used? On Tue, 2006-09-12 at 00:08 -0700, Valient Gough wrote: > There is a program "fsx-linux" which you might find useful. I've > found bugs in FUSE itself with this program in the past while trying > to debug my own filesystems. I managed to find this; it fails nearly instantly with RedirectFS-FH.exe when run as "fsx-linux mount-point/filename": [EMAIL PROTECTED]:RedirectFS$ ./redirectfs-fh t ~/tmp > f.txt & [EMAIL PROTECTED]:RedirectFS$ ./fsx-linux t/fsx2 truncating to largest ever: 0x13e76 domapwrite: mmap: No such device LOG DUMP (4 total operations): 1(1 mod 256): TRUNCATE UP from 0x0 to 0x13e76 2(2 mod 256): WRITE 0x17098 thru 0x26857(0xf7c0 bytes) HOLE 3(3 mod 256): READ 0xc73e thru 0x1b801 (0xf0c4 bytes) 4(4 mod 256): MAPWRITE 0x32e00 thru 0x331fc (0x3fd bytes) Correct content saved for comparison (maybe hexdump "t/fsx2" vs "t/fsx2.fsxgood") However, "fsx2" and "fsx2.fsxgood" differ only in the last 0x1fd bytes, and this appears to be because it never writes those bytes to t/fsx2, but only to t/fsx2.fsxgood. Note that t/fsx2 never writes at 0x331fd, while t/fsx2.fsxgood *does*: OnOpenHandle (/fsx2, 9)=9 ... OnWriteHandle (/fsx2, 9, 858, 26000)=858 OnReadHandle (/fsx2, 9, b000, c000)=b000 OnReadHandle (/fsx2, 9, 1000, 17000)=1000 OnTruncateFile (/fsx2, 9, 331fd)=0 vs. OnOpenHandle (/fsx2.fsxgood, 10)=10 ... OnWriteHandle (/fsx2.fsxgood, 10, 1000, 0)=1000 ... OnWriteHandle (/fsx2.fsxgood, 10, 1fd, 33000)=1fd Plus, given the output of fsx-linux, the difference appears to be due to mmap (or lack thereof). If I run `fsx-linux -W t/fsx2` (to disable mmap writing), things seem to run nicely: [EMAIL PROTECTED]:RedirectFS$ ./a.out -W t/fsx2 mapped writes DISABLED truncating to largest ever: 0x32740 truncating to largest ever: 0x39212 truncating to largest ever: 0x3bae9 ... Is there a known issue with FUSE, fsx-linux & mmap testing, or am I wrong about this? Do you have any other fsx-linux tests to suggest? > Did you try rsync and Evolution? They really do create lots of > rename-while-open events that are useful for testing assumptions > related to the primary key (path in your case). I did rsync earlier today. Found a bug in OnReadDirectory() (it would skip files on large directories), but rsync currently works. The OnReadDirectory fix is in GIT. rsyncing to and from RedirectFS-FH.exe-hosted mount point work as expected. I haven't tried Evolution yet. Do you have any other easily runnable tests? Or is hand-crafting test cases and throwing programs at a filesystem the only way to go? Thanks, - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] IRIX port
Hello, > anybody working on an Irix port? I've been trying to compile for awhile > now but, I think I've answered my own question of how long it would take > to get going. Tooo long! An expert on both Mono and the target platform can usually do this port in one or two months. Becoming an expert on either might add another month or two. We do not have plans at this time to support IRIX. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] Announce: Mono.Fuse 0.3.0
On 9/13/06, Rolf Bjarne Kvinge <[EMAIL PROTECTED]> wrote: > As far as I can see you can download it (for free) here: > http://www.microsoft.com/whdc/devtools/ddk/default.mspx > > > So if you (a) have money, and (b) have lots of time to learn the > > intricacies of Win32 device driver development, you're more than welcome > > to attempt a port. :-) > You'll still need the time though :-) Although the DDK is free, AFAIK kernel-mode drivers need to be signed officially on Vista x64 ( and presumably every future MS OS). This most likely costs lots of money. This is quite unfortunate, as the only reason for this restriction is to protect the HDCP/DRM. I think the best bet is to make FUSE so useful and popular that MS 'innovate' something equivalent ;-) -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] Announce: Mono.Fuse 0.3.0
Hi, > The problem is that FUSE is a kernal module + library pair. To do the > same on Windows, you'd need a Windows kernel driver, and you'd need the > Windows kernel driver interface to support the FUSE operations. > > This means you'd have to have the Windows DDK, which IIRC costs money > (as opposed to the Win32 SDK, which is typically free). As far as I can see you can download it (for free) here: http://www.microsoft.com/whdc/devtools/ddk/default.mspx > So if you (a) have money, and (b) have lots of time to learn the > intricacies of Win32 device driver development, you're more than welcome > to attempt a port. :-) You'll still need the time though :-) Rolf -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/445 - Release Date: 11/09/2006 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] IRIX port
anybody working on an Irix port? I've been trying to compile for awhile now but, I think I've answered my own question of how long it would take to get going. Tooo long! Mathew ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announce: Mono.Fuse 0.3.0
On Tue, 2006-09-12 at 21:31 +0200, pablosantosluac wrote: > Hey, next step could be having the same on Windows? Do you imagine it? File > system kernel modules written in C# You're more than welcome to try. :-) The problem is that FUSE is a kernal module + library pair. To do the same on Windows, you'd need a Windows kernel driver, and you'd need the Windows kernel driver interface to support the FUSE operations. This means you'd have to have the Windows DDK, which IIRC costs money (as opposed to the Win32 SDK, which is typically free). So if you (a) have money, and (b) have lots of time to learn the intricacies of Win32 device driver development, you're more than welcome to attempt a port. :-) - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announce: Mono.Fuse 0.3.0
Hey, next step could be having the same on Windows? Do you imagine it? File
system kernel modules written in C#
ok, let's stop dreaming... :-P
- Original Message -
From: "Jonathan Pryor" <[EMAIL PROTECTED]>
To: "Mono List" ; "mono-devel-list"
<[EMAIL PROTECTED]>
Sent: Monday, September 11, 2006 12:04 PM
Subject: [Mono-dev] Announce: Mono.Fuse 0.3.0
> Mono.Fuse is a C# binding for the FUSE library.
>
> This release features a near complete change in the public FileSystem
> API; a complete API change list is available at:
>
> http://www.jprl.com/Blog/archive/development/mono/2006/Sep-11.html
>
> Hopefully this will be the last major API change, though I would
> appreciate any and all feedback on the current API.
>
> The most "interesting" change is for OnReadDirectory(). It was
> previously:
>
> protected virtual Errno
> OnReadDirectory(string path, out string[] paths,
> OpenedFileInfo info);
>
> It is now:
>
> protected virtual Errno
> OnReadDirectory(string path, OpenedPathInfo info,
> out IEnumerable paths);
>
> That is, `out string[]' is now `out IEnumerable'. This
> allows for two things:
>
> 1. A performance boost: an array containing the names of all file
> system entries in `path' doesn't need to be created all at once. For
> large directories (hundreds-thousands of files), this can really slow
> things down. The IEnumerable interface allows file system entries to be
> retrieved piecemeal.
>
> 2. C# iterators can be used to implement directory reading. From
> HelloFS.cs:
>
> private IEnumerable GetEntries ()
> {
> yield return ".";
> yield return "..";
> yield return "hello";
> yield return "data";
> if (have_data_im)
> yield return "data.im";
> }
>
> protected override Errno OnReadDirectory (string path,
> OpenedPathInfo info,
>out IEnumerable paths)
> {
> paths = GetEntries ();
> return 0;
> }
>
> I think (2) is particularly cool.
>
>
> Design Questions:
>
> OnReadDirectory() uses FileSystemEntry, which is:
>
> class FileSystemEntry
> public string Path {get;}
> public Stat Stat;
> public FileSystemEntry (string path);
> public static implicit operator FileSystemEntry (string);
> }
>
> This has a public field Stat, which is against normal design guidelines.
> This was done because Stat is a 96-byte structure, so these shouldn't be
> created on the stack that often, and a read/write Property would require
> much more stack use. Is this reasonable?
>
> The Stat field is optional. It is only used Stat.st_ino is non-zero (as
> FUSE 2.5.3 currently only reads the st_ino & st_mode fields, though I
> imagine this could be extended in the future). Is this reasonable? Or
> should an alternative mechanism be used to determine when the Stat
> instance should be used?
>
> Is it a good idea to have the implicit conversion from string to
> FileSystemEntry?
>
>
> Download:
>
> Mono.Fuse 0.3.0 is available for download at:
>
> http://www.jprl.com/Projects/mono-fuse/mono-fuse-0.3.0.tar.gz
>
> Thanks,
> - Jon
>
>
> ___
> 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] Mono on Pocket PC
Running WinCE or Linux? And for which CPU? Pocket PCs vary greatly in the chosen CPU, and although Mono currently has a ARM port (running on Linux), many Pocket PCs use completely unsupported CPUs. And many recent Pocket PCs (and Smartphones) come with WinCE.NET, that sport a diet .NET, what some people really do is to adapt and compile selected Mono Class Libraries (like System.Xml) for running in the PPCs, if they have enough memory... :) On 9/11/06, Carlos J. Muentes <[EMAIL PROTECTED]> wrote: > Are there any plans to port mono to the Pocket PC? I haven't been able > to find anything on this. > > ___ > 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] bug in xsd.exe
El mar, 12-09-2006 a las 05:38 -0700, L.G. Meredith escribió: > Lluis, > > Thanks for the response. The schema validates against the W3C schema > schema using Oxygen. i haven't had the chance, yet to validate it > using any other validation tool. Does xsd.exe on mono not support all > valid schema? It does not. Not everything that can be defined using XML schema can be defined using classes and attributes. > What are the limitations? I don't have a list of limitations. Notice that the limitations are not in the XSD tool, but in the set of attributes defined in System.Xml.Serialization. Those attributes allow you to specify how class members have to be serialized. They perform the class to schema mapping. But they are not expressive enough to support all possible schema constructs. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] bug in xsd.exe
El dom, 10-09-2006 a las 20:43 -0700, Lucius Meredith escribió: > All, > > The attached valid schema causes xsd.exe to fail with the following > stack trace. i'm working to minimize the example, but any help would > be greatly appreciated. The NUllReferenceException error is a bug in mono that has been fixed. However, you'll get another exception because this schema contains some definitions which are not supported by XSD. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Use recursive AscW in VB runtime (2)
Kornél, I have tested and I agree with your patch. Sorry for the extra iteration. Please commit, Rafael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael Mizrahi Sent: Tuesday, September 12, 2006 12:38 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] Use recursive AscW in VB runtime (2) Kornél, I don't understand your patch, you are calling AscW within AscW function. Isn't it will generate a StackOverflow exception ? Public Function AscW(ByVal c As Char) As Integer -Return Convert.ToInt32(c) +' Compiled as if it were "Return CInt(c)" when /novbruntimeref is used +Return AscW(c) End Function Rafael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kornél Pál Sent: Tuesday, September 12, 2006 12:17 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] [PATCH] Use recursive AscW in VB runtime (2) Hi, /novbruntimeref treats AscW specially as it is compiled as if it were CInt (no AscW method is called). Now vbnc has support for this as well and a dedicated test case ensures this behavior. Please review and approve the patch. Kornél ___ 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] Use recursive AscW in VB runtime (2)
Kornél, I don't understand your patch, you are calling AscW within AscW function. Isn't it will generate a StackOverflow exception ? Public Function AscW(ByVal c As Char) As Integer -Return Convert.ToInt32(c) +' Compiled as if it were "Return CInt(c)" when /novbruntimeref is used +Return AscW(c) End Function Rafael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kornél Pál Sent: Tuesday, September 12, 2006 12:17 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] [PATCH] Use recursive AscW in VB runtime (2) Hi, /novbruntimeref treats AscW specially as it is compiled as if it were CInt (no AscW method is called). Now vbnc has support for this as well and a dedicated test case ensures this behavior. Please review and approve the patch. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Use recursive AscW in VB runtime (2)
Hi, /novbruntimeref treats AscW specially as it is compiled as if it were CInt (no AscW method is called). Now vbnc has support for this as well and a dedicated test case ensures this behavior. Please review and approve the patch. Kornél vbruntime_AscW.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono on Linux/Alpha
Hello Zoltan,
Here is another set of patches for mono on Linux/Alpha.
What is changed:
- Reworked passing of arguments on stack - now it is more close to ABI
(and same as gcc) and safe from stack allocation leaks
- New argument passing schema would allow to start pass valuetypes in
registers (as native methods expect)
- Fixed start_handler/endfinally/endfilter - not to modify stack pointer
- Added implemetation of lconv_to_i/u4
- Some opcode implemetation and fixes
- Fixed strtod for Alpha
- Added native opcodes patch missed from previous patchset
With all of that I was able to build mcs compiler and using it build all
assembles in mcs directory. :)
So, now it could be considered that the mono is supported on Linux/Alpha
as betta version. :)
Number of failed tests in mono/tests down to 7. Most of the pinvokes
with complex parameters, vararg and one thread tests.
Regards,
--
Sergey Tikhonov
Solvo Ltd.
Saint-Petersburg, Russia
[EMAIL PROTECTED]
Index: mono/mono/mini/exceptions-alpha.c
===
--- mono/mono/mini/exceptions-alpha.c (revision 65271)
+++ mono/mono/mini/exceptions-alpha.c (working copy)
@@ -310,6 +310,7 @@
/* Exception is in a0 already */
alpha_mov1(code, alpha_ra, alpha_a1); // Return address
alpha_mov1(code, alpha_sp, alpha_a2); // Stack pointer
+
if (rethrow)
alpha_lda(code, alpha_a3, alpha_zero, 1);
else
@@ -746,6 +747,7 @@
{
static guint8 *start;
static int inited = 0;
+ unsigned int *code;
if (inited)
return start;
@@ -754,6 +756,10 @@
//get_throw_exception_generic (start, SZ_THROW, TRUE, FALSE);
inited = 1;
+ code = (unsigned int *)start;
+
+ alpha_call_pal(code, 0x80);
+
return start;
}
/*= End of Function */
@@ -912,9 +918,12 @@
/* Some how we should find size of frame. One way:
read 3rd instruction (alpha_lda(alpha_sp, alpha_sp, -stack_size ))
and extract "stack_size" from there
+ read 4th and 5th insts to get offsets to saved RA & FP
*/
unsigned int *code = (unsigned int *)ji->code_start;
short stack_size = -((short)(code[2] & 0x));
+ short ra_off = code[3] & 0x;
+ short fp_off = code[4] & 0x;
/* Restore stack - value of FP reg + stack_size */
new_ctx->uc_mcontext.sc_regs[alpha_sp] =
@@ -923,11 +932,11 @@
/* we substract 1, so that the IP points into the call instruction */
/* restore PC - @FP + 0 */
new_ctx->uc_mcontext.sc_pc =
- *((guint64 *)ctx->uc_mcontext.sc_regs[alpha_r15]);
+ *((guint64 *)(ctx->uc_mcontext.sc_regs[alpha_r15] + ra_off));
/* Restore FP reg - @FP + 8 */
new_ctx->uc_mcontext.sc_regs[alpha_r15] =
- *((guint64 *)(ctx->uc_mcontext.sc_regs[alpha_r15] + 8));
+ *((guint64 *)(ctx->uc_mcontext.sc_regs[alpha_r15] + fp_off));
/* Restore GP - read two insts that restore GP from sc_pc and */
/* do the same. Use sc_pc as RA */
@@ -945,7 +954,10 @@
}
}
+#if 0
/* Pop arguments off the stack */
+ // No poping args off stack on Alpha
+ // We use fixed place
{
MonoJitArgumentInfo *arg_info =
g_newa (MonoJitArgumentInfo,
@@ -957,7 +969,7 @@
arg_info);
new_ctx->uc_mcontext.sc_regs[alpha_sp] += stack_to_pop;
}
-
+#endif
return ji;
}
else if (*lmf)
Index: mono/mono/mini/cpu-alpha.md
===
--- mono/mono/mini/cpu-alpha.md (revision 65271)
+++ mono/mono/mini/cpu-alpha.md (working copy)
@@ -57,7 +57,7 @@
arg:
arglist:
break: len:4
-jmp: len:4
+jmp: len:48
br: len:4
beq: len:4
bge: len:4
@@ -99,8 +99,8 @@
shr.un: dest:i src1:i src2:s len:8
neg: dest:i src1:i len:4
not: dest:i src1:i len:4
-conv.i1: dest:i src1:i len:4
-conv.i2: dest:i src1:i len:4
+conv.i1: dest:i src1:i len:12
+conv.i2: dest:i src1:i len:12
conv.i4: dest:i src1:i len:4
conv.i8: dest:i src1:i len:4
conv.r4: dest:f src1:i len:20
@@ -126,7 +126,7 @@
cgt.un: dest:c len:8
clt: dest:c len:8
clt.un: dest:c len:8
-localloc: dest:i src1:i len:84
+localloc: dest:i src1:i len:20
compare: src1:i src2:i len:4
lcompare: src1:i src2:i len:4
icompare: src1:i src2:i len:4
@@ -304,7 +304,7 @@
call_handler: len:4
start_handler: len:96
endfinally: len:96
-op_endfilter: len:96
+op_endfilter: src1:i len:96
aot_const: dest:i len:10
# x86_test_null: src1:i len:5
# x86_compare_membase_reg: src1:b src2:i len:9
Index: mono/mono/mini/tramp-alpha.c
===
--- mono/mono/mini/tramp-alpha.c(revision 65271)
+++ mono/mono/mini/tramp-alpha.c(working copy)
@@ -625,3 +625,25 @@
g_assert_not_reached ();
}
+/*
+ * This method is onl
Re: [Mono-dev] [Mono-list] Announce: Mono.Fuse 0.2.0 (+ Required mcs & mono patches)
On 9/11/06, Jonathan Pryor <[EMAIL PROTECTED]> wrote: > On Sun, 2006-09-10 at 21:07 -0700, Valient Gough wrote: > I think this is why they changed `struct fuse_operations' to deprecate > the getdir() method and replaced it with a readdir() method which > provides a `struct stat' to the filler function pointer. This change > requires FUSE 2.3, and setting the FUSE_USE_VERSION macro in order to > use it. I see that neither Sulf nor fusewrapper set this macro. The getdir() / readdir() changes don't affect my wrappers - those are for the path based API. > >From what I can gather from email archives, they added the readdir() > replacement precisely because of apps like Mutt, so that the filesystem > programs could provide an inode for stability tracking purposes. Yes, but this is only vaguely related. You might have noticed that I reported that problem, and I think even provided some of the changes to help with this case. One of the tricks Mutt does is create hard links and then check that the inode numbers were identical as a race-condition check. That solves one particular problem with Mutt running under a virtual FS. That's the interesting thing with running random programs under a filesystem - you find out that behavior which programs expect isn't necessarily guaranteed by the filesystem documentation. > The current Mono.Fuse.FileSystem.OnReadDirectory() method now allows > providing this `struct stat' information, so hopefully things should > work sanely (though I have yet to actually test it, and coming up with > an a good test case which exercises reading, writing, and renaming > concurrently is difficult). There is a program "fsx-linux" which you might find useful. I've found bugs in FUSE itself with this program in the past while trying to debug my own filesystems. > Also, a file can't be deleted while it's still open if the *Handle > methods use file descriptors, as even after OnRemoveFile() is called the > file handle would still be valid, and won't be invalided until > OnReleaseHandle() is called. The same should be true for directories, > if a directory handle is used (again, see > example/RedirectFS/RedirectFS-FH.cs). I wrote a fair amount of the rename and delete handling code in libfuse, which has been there since version 1.9, so I feel confident in describing how it works. You're right that a file handle will still be valid, but the path name will have changed. The NFS trick is used for the path-based API (unnecessary with the inode api) - a delete is turned into a synchronized rename with the final delete postponed until files are closed. Did you try rsync and Evolution? They really do create lots of rename-while-open events that are useful for testing assumptions related to the primary key (path in your case). Now consider edge cases related to this NFS trick. Consider that you have an open file and the file is removed. Now the directory is supposed to be empty (although because of the NFS trick it isn't) and the directory is removed. Does it succeed, or does it fail, and does it match what a program might expect from a 'normal' filesystem? No point arguing about what we expect to happen - rsync can cause such a condition, or it could be constructed by hand, so it is easy to test. Sounds like minor issues, and they are mostly. Only a few programs will probably be affected, and most of them in a way that doesn't cause an serious problem (meaning data loss). If the broken programs are used by few people, it may takes years to hear about it. But if it causes Evolution to corrupt its db files, the feedback may not be so friendly. regards, Valient PS. You know about the language wrapper FUSE wiki page? (http://fuse.sourceforge.net/wiki/index.php/LanguageBindings). Might want to list your wrapper so that people outside mono-devel can find it. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Microsoft.VisualBasic compiled into java
FYI, Microsoft.VisualBasic 1.1 at 'mono-basic\vbruntime' now runs on Java. I have added VB.J2EE.build.bat which compiles VB 1.1 (using the define TARGET_JVM) and then, converts it into jar, using Mainsoft Grasshopper. Next steps regard Java: * Port and Run Microsoft.VisualBasic test suites on java using Grasshopper. * Do the same for Microsoft.VisualBasic 2.0 Enjoy and deploy, Rafael Mainsoft ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
