Hello,
> This results in a recursiong with Conversions.ToDecimal because CDec (and
> all the other CType conversions are done at runtime unless the type is known
> to the compiler as well. And anyway there is no use to do reinterpretation
> when the exact type is know. A simple unbox is enough.
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
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 o
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 Wi
On Tue, 2006-09-12 at 08:07 -0500, [EMAIL PROTECTED] wrote:
> I have 4 windows systems, one of which is the development machine.
> Each is running the same deployed exe and set of libraries. The
> problem is that two of the four machines fail with the following
> message when executing code
Hi,
I didn't have a look at the docs, but when a type has no namespace or is in
the global namespace (I don't know the which is the right term:)
Type.Namespace returns null on Mono and MS.NET as well. It's quite easy to
create a such type. An example is Consts.cs that is used in almost all clas
Hi,
Use "VB.replace.bat 2" then try to bootstrap vbnc on MS.NET.
For an example have a look at the attached vbrun.diff.
The bug I found when trying to compile vbnc was:
Case TypeCode.Decimal
Return CDec(Value)
This results in a recursiong with Conversions.ToDe
Hey!
> But it's unable to bootstrap itself on MS.NET using our VB runtime so the VB
> runtime should be fixed as well before trying to fix vbnc on Mono.
Do you have some details for me?
This is a good observation, before we launch ourselves into a quest to
fix bugs on the Mono side (although we
Hi,
>So Rolf's new VB compiler can bootstrap itself on Windows, and is
> able to build its own runtime on Windows as well (I mean, with .NET),
> but on Linux we are running into a few bugs in Mono.
But it's unable to bootstrap itself on MS.NET using our VB runtime so the VB
runtime should be
Yes, if you are running your app on Windows, then in my experience there
is no more stable version - and we've checked out *every* one. We have
an application that challenges many areas of System.Windows.Forms and it
does not work under any version of Mono since 1.1.9.2. XSP has had
problems with
Mats Nilsson wrote:
> Thats a problem for me because of the 77075 bug. Mono GC fails almost
> everytime I'm testing my application because of the suspend thread
> fault described in the above mentioned bug report. I was recommened
> to try out the 1.1.9.2 release by Bill Seddon, the author of the b
Michael Schurter wrote:
Mats Nilsson wrote:
Is there somone who could tell me what this is. I'm writing a
nhibernate application and testing it under windows with mono
1.1.9.2. The application runs with mono 1.1.16.1 or higher but I was
recommended to use the 1.1.9.2 release becaus
Mats Nilsson wrote:
> Is there somone who could tell me what this is. I'm writing a
> nhibernate application and testing it under windows with mono
> 1.1.9.2. The application runs with mono 1.1.16.1 or higher but I was
> recommended to use the 1.1.9.2 release because of it´s stability.
Thats a wei
Hi,
Is there somone who could tell me what this is.
I'm writing a nhibernate application and testing it under windows with
mono 1.1.9.2.
The application runs with mono 1.1.16.1 or higher but I was recommended
to use the
1.1.9.2 release because of it´s stability.
I haven't done any attribute pro
I have 4 windows systems, one of which is the development machine.
Each is running the same deployed exe and set of libraries. The
problem is that two of the four machines fail with the following
message when executing code in Mono.Unix.Catalog for gettext. The
worst part is that MonoPosix
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 funct
16 matches
Mail list logo
