[Mono-dev] new version of ADO.NET provider for MaxDB is released

[Dmitry Key]

Hi All

The ADO.NET provider for MaxDB version 0.8 is released (see 
http://www.sf.net/projects/maxdbprovider). Some bugs are fixed in the 
Interop module (thanks to Kornél Pál for the help) so provider looks less or 
more workable for mono-1.0 profile.


Also I have one question to ADO.NET/Mono team. I would like to get more 
feedbacks from MaxDB users. Is it possible to add link to the MaxDB Provider 
project on Mono/Data Access web page?


_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Application deployment questions

[Lucifer]

Hi Robert,

Thank you very much!
Your information is really useful for me.

I have not mentioned that I develop Mono application in Win32 platform, and
I strive to make my application cross-platform targeted.

In Win32 port, I might construct the application directory structure as
following:
AppFolder/
AppFolder/MyApp.exe
AppFolder/DependentDLLs
AppFolder/MyDLLs
As for Linux and Mac ports, I thought I have to switch to different
directory structure though I don't know how. I have very limited experience
in Linux/Unix development.

Originally I use Mono-1.1.13, and now I switch to use Mono-1.1.16. I tried
to use mkbundle.exe but exceptions throw.

Sources: 1 Auto-dependencies: False
   embedding: D:\test\x.exe
Compiling:
as -o temp.o temp.s
Unhandled Exception: System.ComponentModel.Win32Exception: Cannot find the
specified file
  at System.Diagnostics.Process.Start_shell
(System.Diagnostics.ProcessStartInfo startInfo, System.Diagnostics.Process
process) [0x0]
  at System.Diagnostics.Process.Start_common
(System.Diagnostics.ProcessStartInfo startInfo, System.Diagnostics.Process
process) [0x0]
  at System.Diagnostics.Process.Start (System.Diagnostics.ProcessStartInfo
startInfo) [0x0]
  at System.Diagnostics.Process.Start (System.String fileName, System.String
arguments) [0x0]
  at MakeBundle.Execute (System.String cmdLine) [0x0]
  at MakeBundle.GenerateBundles (System.Collections.ArrayList files)
[0x0]
  at MakeBundle.Main (System.String[] args) [0x0]
(skip)

Do you have any ideas about this?

One restriction on me is that I can't afford to pack all binaries in /bin
with my application because the overall package size must be limited. I'd
only utilize a small portion of Mono binaries so that I hope I could pack up
the only DLLs required with my application.

I've wrote a simple program and managed to run on a WindowsXP PC which has
no Mono/.NET installed.
The DLLs required are as following: iconv.dll, intl.dll, libglib-2.0-0.dll,
libgmodule-2.0-0.dll, libgthread-2.0-0.dll, mono-1.dll, and mono.exe.
Would the DLLs required in Linux and MacOSX be different than in Win32?


Regards,
Lucifer

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Build system support for SWF apps

[Miguel de Icaza]

Hello,

> Apparently Mono's build system does not yet support building Winform apps.
> 
> If you include executable.make, then -target:exe will automatically be
> passed to mcs (even if you explicitly set -target:winexe in
> LOCAL_MCS_FLAGS).
> 
> As a result, the mcs-built SWP app will run with a DOS-box on MS.NET.
> 
> Is there any workaround for this ?

I still think that your event viewer should go into a different module
(winforms-tools)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Build system support for SWF apps

[Kornél Pál]

Modify build to use -target:winexe.

For example adding a WINEXE (or something like that) variable that will be 
recognized by executable.make would be a good solution.

Kornél

- Original Message - 
From: "Gert Driesen" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, August 24, 2006 9:34 PM
Subject: [Mono-dev] Build system support for SWF apps


> Hi,
>
> Apparently Mono's build system does not yet support building Winform apps.
>
> If you include executable.make, then -target:exe will automatically be
> passed to mcs (even if you explicitly set -target:winexe in
> LOCAL_MCS_FLAGS).
>
> As a result, the mcs-built SWP app will run with a DOS-box on MS.NET.
>
> Is there any workaround for this ?
>
> Gert
>
> ___
> 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] Build system support for SWF apps

[Gert Driesen]

Hi,

Apparently Mono's build system does not yet support building Winform apps.

If you include executable.make, then -target:exe will automatically be
passed to mcs (even if you explicitly set -target:winexe in
LOCAL_MCS_FLAGS).

As a result, the mcs-built SWP app will run with a DOS-box on MS.NET.

Is there any workaround for this ?

Gert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] DataSet : Trouble with Relation and ForeignKey ...

[xiii29]

Hi !

Ok one for me !!! I misunderstood the exception message. It seems that 
we can't add a Constraint if there an equivalent Relation ...

MS.Net does the same ... so it's ok : one for me !

Sorry for the disturb ...


Konstantin Triger a écrit :
> Hi,
>
> Does it work on ms .net?
> Can you drop a test case reproducing the problem?
>
> Regards,
> Konstantin Triger
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of xiii29
> Sent: Wednesday, August 23, 2006 11:55 PM
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] DataSet : Trouble with Relation and ForeignKey ...
>
> Hi,
>
> My applications uses a DataSet with DataRelations to store information.
> After created a relation, I also create a ForeignKey between the same 
> two columns.
>
> With the 1.1.13.4 version of mono : no trouble everything is working.
>
> With the 1.1.16.1 version of mono : I get this messages :
> /Unhandled Exception: System.Data.DataException: Constraint matches 
> contraint named '' already in collection/
>
> I think I'm doing something twice by creating a DataRelation and a 
> Constraint, so which one include the other one ?
>
> Thanks for answer !
>
>
>
>
>
>
>
>
> ___
> 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-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Cecil bug report and a question

[Jb Evain]

Hi Bjarke,

Bjarke Hammersholt Roune wrote:
> I have taken a look at 0.4.3, and you are correct that it can read and 
> then write the bug-triggering assembly that I attached to my previous 
> bug report without problems. The issue has not been entirely fixed, 
> however. I have attached an assembly that makes Cecil output an invalid 
> assembly. This is using Cecil 0.4.3 - I have not checked the version of 
> Cecil in SVN. Specifically MS peverify gives the following complaint 
> when I run it on the output:
> 
> [IL]: Error: [E:\net\o.exe : Bug::Main][offset 0x0007] Handler 
> starts in the middle of an instruction.
> 
> As far as I can tell the problem is rather the handler end than the 
> start, but maybe I am wrong (I can't inspect it manually as ildasm does 
> not display what the actual ranges are, probably because in this case 
> the handler is invalid).
> 
> I believe I have tracked the problem down to the following method in 
> CodeWriter.cs:
> 
> int GetLength (Instruction start, Instruction end, Instruction last)
> {
> return (end == null ? last.Offset + last.OpCode.Size : end.Offset) - 
> start.Offset;
> }
> 
> As far as I have been able to figure out, OpCode.Size is only the size 
> of the opcode itself - it does not include any parameters that follow 
> the opcode. Thus the ending offset is miscalculated in case the last 
> instruction in the method has any parameters, and that instruction is 
> also the last instruction in an exception handler.

Hmm, interesting, I'll have a look at that soon. Thanks for the test case!

> The thing is, I am not sure how ranges are handled in Cecil. I think it 
> works like this: all ranges of instructions are represented as half open 
> intervals [start, end), where start and end are pointers to actual 
> Instructions. start and end can be null if they are past the last 
> instruction. Is this correct?

Yes it is. But we expect that only the end could be pointing after the 
last instruction. If start is null then we have a real problem.

>> Cecil does not preserve the .rsrc (aka Win32 resources) section or the 
>> PE file for the moment. So it saves some place.
>>
> What are the consequences of this other than smaller assemblies?

We can not add stuff like Win32 icons, or any kind of Win32 resources to 
the assembly. Kornél already wrote some stuff to handle that in mcs and 
ilasm, thought I'm not sure I want to include his code which very 
complete, but also kind of large.

Jb
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Cecil bug report and a question

[Bjarke Hammersholt Roune]

Hi,

Jb Evain skrev:

Hi,

Bjarke Hammersholt Roune wrote:
I have found the following bug in Cecil. Here is how to trigger it: Make 
an assembly with a method where the last instruction in that method is 
also the last instruction in a handler block. Use Cecil to load the 
assembly and then save it. This will result in a NullReferenceException 
being thrown from Mono.Cecil.Cil.CodeWriter.IsRangeFat. I have attached 
an example assembly that contains such a method.


This seems to be already fixed. Please use the very fresh 0.4.3 release 
or even better, an always up to date SVN checkout.


Thank you for the prompt and informative reply! I thought I was using 
the newest version, but I did not think to check if a new version had 
been released. Sorry about that.


I have taken a look at 0.4.3, and you are correct that it can read and 
then write the bug-triggering assembly that I attached to my previous 
bug report without problems. The issue has not been entirely fixed, 
however. I have attached an assembly that makes Cecil output an invalid 
assembly. This is using Cecil 0.4.3 - I have not checked the version of 
Cecil in SVN. Specifically MS peverify gives the following complaint 
when I run it on the output:


[IL]: Error: [E:\net\o.exe : Bug::Main][offset 0x0007] Handler 
starts in the middle of an instruction.


As far as I can tell the problem is rather the handler end than the 
start, but maybe I am wrong (I can't inspect it manually as ildasm does 
not display what the actual ranges are, probably because in this case 
the handler is invalid).


I believe I have tracked the problem down to the following method in 
CodeWriter.cs:


int GetLength (Instruction start, Instruction end, Instruction last)
{
	return (end == null ? last.Offset + last.OpCode.Size : end.Offset) - 
start.Offset;

}

As far as I have been able to figure out, OpCode.Size is only the size 
of the opcode itself - it does not include any parameters that follow 
the opcode. Thus the ending offset is miscalculated in case the last 
instruction in the method has any parameters, and that instruction is 
also the last instruction in an exception handler.


Adding a dummy return instruction at the end of the instruction stream 
also works as a temporary work around for this bug, as return 
instructions do not take parameters.


It would probably be a good idea to document how ranges are represented 
in Cecil in the FAQ, as there are several reasonable ways it could work, 
 and it is not possible to tell from the Cecil interface which one it is.


Good idea! Feel tree to add another entry to 
http://www.mono-project.com/Cecil:FAQ


The thing is, I am not sure how ranges are handled in Cecil. I think it 
works like this: all ranges of instructions are represented as half open 
intervals [start, end), where start and end are pointers to actual 
Instructions. start and end can be null if they are past the last 
instruction. Is this correct?


I also have a question: I have an example of an assembly output by the 
MS C# compiler that shrinks from 3.072 bytes to 2.048 bytes simply by 
loading and then saving it using Cecil. How does that happen?


Cecil does not preserve the .rsrc (aka Win32 resources) section or the 
PE file for the moment. So it saves some place.



What are the consequences of this other than smaller assemblies?

Regards
Bjarke Roune


bug2
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] [PATCH] Generate Consts.vb from Consts.cs (new patch)

[Carlos Alberto Cortez]

> I might be wrong but I am wondering if it is consistent to use Perl for 
> this kind of things, inside the mono project. It would be more logical 
> to use Mono itself, and then not having another external dependency 
> (Mono depending on Perl??), right?

Just for the record: we already have perl scripts in the build system,
as well in gtk-sharp, for example.

Carlos.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new patch)

[Ympostor]

Kornél Pál wrote:
> I attached a cs2vb.cs that is functionally equivalent to cs2vb.pl. (I 
> created this just for fun to show how much easier it is in Perl.:)

I keep preferring C# :D


> I anybody has ideas how to compile a C# program before compiling 
> anything else help is welcome otherwise I think the previously attached 
> cs2vb.pl is the best solution.

Hey, if the conversion tool is made with C#, you need to compile the 
runtime first but, when is this tool needed? I suppose it is only for 
the VB part. Why not compiling all the C# stuff, compile this tool, and 
then all the VB part?

Regards

-- 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] NullReferenceException thrown inside catch

[Robert Jordan]

Robert Jordan wrote:
> Robert Jordan wrote:
>> Hi,
>>
>> Janne Rantala wrote:
>>> I found out that when NullReferenceException is thrown inside catch
>>> clause in embedded environment, Mono crashes. Normally when method is
>>> invoked with mono_runtime_invoke, exceptions are stored in MonoObject
>>> but somehow this does not happen in this case.
>>> This happened when I tried to print out message from InnerException
>>> which didn't exist.
>>>
>>> Here is the code, without that Console.WriteLine it works ok
>>> (exception is stored in MonoObject).
>>
>> Here is another simple sample:
>>
>> public void CrashMe ()
>> {
>>  null.Equals (null);
>> }
>>
>>
>> It seems that a "true" SIGSEGV (generated by native JIT code)
>> cannot be caught by mono_runtime_invoke ().
>>
>> Please file a bug, if no one objects (it could be by design).
> 
> Oh, it's a Windows problem. I cannot reproduce it under Linux.


The Windows port seems to use SEH. Maybe a SEH handler
could be able to catch the exception:

#include 

MonoException *ex;

__try {
mono_runtime_invoke ( ..., &ex);
}
__except (EXCEPTION_EXECUTE_HANDLER) {

/* simulate a NRE */
ex = mono_get_exception_null_reference ();
}

if (ex != NULL) {
handle the exception
}

The code is for VC++ in C mode (not C++).

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] NullReferenceException thrown inside catch

[Robert Jordan]

Robert Jordan wrote:
> Hi,
> 
> Janne Rantala wrote:
>> I found out that when NullReferenceException is thrown inside catch
>> clause in embedded environment, Mono crashes. Normally when method is
>> invoked with mono_runtime_invoke, exceptions are stored in MonoObject
>> but somehow this does not happen in this case.
>> This happened when I tried to print out message from InnerException
>> which didn't exist.
>>
>> Here is the code, without that Console.WriteLine it works ok
>> (exception is stored in MonoObject).
> 
> 
> Here is another simple sample:
> 
> public void CrashMe ()
> {
>   null.Equals (null);
> }
> 
> 
> It seems that a "true" SIGSEGV (generated by native JIT code)
> cannot be caught by mono_runtime_invoke ().
> 
> Please file a bug, if no one objects (it could be by design).

Oh, it's a Windows problem. I cannot reproduce it under Linux.

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] NullReferenceException thrown inside catch

[Robert Jordan]

Hi,

Janne Rantala wrote:
> I found out that when NullReferenceException is thrown inside catch
> clause in embedded environment, Mono crashes. Normally when method is
> invoked with mono_runtime_invoke, exceptions are stored in MonoObject
> but somehow this does not happen in this case.
> This happened when I tried to print out message from InnerException
> which didn't exist.
> 
> Here is the code, without that Console.WriteLine it works ok
> (exception is stored in MonoObject).


Here is another simple sample:

public void CrashMe ()
{
null.Equals (null);
}


It seems that a "true" SIGSEGV (generated by native JIT code)
cannot be caught by mono_runtime_invoke ().

Please file a bug, if no one objects (it could be by design).

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] build on win failed on ./monoburg ./sample.brg > sample.c

[Atsushi Eno]

Hi,

Probably downgrading libtool to 1.5.20 would solve the problem.

Atsushi Eno

Sebastien Pouliot wrote:
> Hello Timo,
> 
> On Tue, 2006-08-22 at 15:05 +0200, Timo Rainio wrote:
>> hi all,
>> building mono on windows when in /trunk/mono/mono/monoburg the
>> following command:
>>
>> ./monoburg ./sample.brg > sample.c
>>
>> produces me an empty sample.c (zero byte) and the following compile
>> fails. This happens with current source code release 1.1.16.1 as well
>> as current svn-checkout.
>>
>> thanks for any hints
> 
> When did you install/update cygwin ?
> 
> I installed it (well re^12-installed it) yesterday and got the same
> problem.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new patch)

[Kornél Pál]

Hi,

I attached a cs2vb.cs that is functionally equivalent to cs2vb.pl. (I 
created this just for fun to show how much easier it is in Perl.:)


I anybody has ideas how to compile a C# program before compiling anything 
else help is welcome otherwise I think the previously attached cs2vb.pl is 
the best solution.



But perhaps tomorrow you need constans and X; and in one month you see
that you need Y too, and then Z... And you could have finished it
earlier reusing code..? :)


Consts.cs is for constants. If we need code it probably will be (and should 
be) put to separate code files. Converting code from one language to another 
as the part of the build process is a bad idea anyway. Even if you convert 
it programatically you have to look at the result that everyting is fine. So 
if we need the same code both in C# and VB there should be two source files 
in SVN.


Consts.cs is a special case because it only contains constants. It's more 
like a configuration file than a code file.


Kornél

- Original Message - 
From: "Ympostor" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, August 24, 2006 1:45 PM
Subject: Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new 
patch)



Kornél Pál escribió:

This conversion is restricted to constants. And it should be simple rather
than a complex language converter.


But perhaps tomorrow you need constans and X; and in one month you see
that you need Y too, and then Z... And you could have finished it
earlier reusing code..? :)



BTW who do you mean on the SD guys?


Sorry for not clarifying, SD: SharpDevelop.

Regards.

--

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list 

//
// cs2vb.cs
//
// Author:
//   Kornél Pál 
//
// Copyright (C) 2006 Kornél Pál
//

//
// Permission is hereby granted, free of charge, to any person obtaining
// a copy of this software and associated documentation files (the
// "Software"), to deal in the Software without restriction, including
// without limitation the rights to use, copy, modify, merge, publish,
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
//

// This converter is suitable only for Consts.cs.

// There will be no hidden bugs because unsupported constructs are not
// converted that will cause compilation errors in Visual Basic compiler.

using System;
using System.Globalization;
using System.IO;
using System.Text.RegularExpressions;

internal class cs2vb
{
private static string line;
private static Match match;

private static string GetSubstring (int index)
{
return GetSubstring (match, index);
}

private static string GetSubstring (Match match, int index)
{
return match.Groups [index].Value;
}

private static bool IsMatch (string pattern)
{
return IsMatch (line, pattern);
}

private static bool IsMatch (string input, string pattern)
{
match = Regex.Match (input, pattern, 
RegexOptions.CultureInvariant);
return match.Success;
}

private static bool Replace (string pattern, string replacement)
{
return Replace (ref line, pattern, replacement);
}

private static bool Replace (string pattern, MatchEvaluator evaluator)
{
return Replace (ref line, pattern, evaluator);
}

private static bool Replace (ref string input, string pattern, string 
replacement)
{
if (!IsMatch (input, pattern))
return false;

input = Regex.Replace (input, pattern, replacement, 
RegexOptions.CultureInvariant);
return true;
}

private static bool Replace (ref string input, string pattern, 
MatchEvaluator evaluator)
{
if (!IsMatch (input, pattern))
return false;

input = Regex.Replace (input, pattern, evaluator, 
RegexOptions.CultureInvariant);
return true;
}

private static string HexEvaluator (Match ma

[Mono-dev] NullReferenceException thrown inside catch

[Janne Rantala]

Hi,

I found out that when NullReferenceException is thrown inside catch
clause in embedded environment, Mono crashes. Normally when method is
invoked with mono_runtime_invoke, exceptions are stored in MonoObject
but somehow this does not happen in this case.
This happened when I tried to print out message from InnerException
which didn't exist.

Here is the code, without that Console.WriteLine it works ok
(exception is stored in MonoObject).

namespace ExceptionTest
{
class Program
{
public static void Main()
{
try
{
throw new Exception("Test");
}
catch (Exception e)
{
Console.WriteLine(e.InnerException.Message);
throw new Exception("Testi2");
}
}
public Program()
{

}
}
}

Same program ran from the command line gives

"Unhandled Exception: System.NullReferenceException: Object reference not set to
an instance of an object"

Cheers,
Janne
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] build on win failed on ./monoburg ./sample.brg > sample.c

[Sebastien Pouliot]

Hello Timo,

On Tue, 2006-08-22 at 15:05 +0200, Timo Rainio wrote:
> hi all,
> building mono on windows when in /trunk/mono/mono/monoburg the
> following command:
> 
> ./monoburg ./sample.brg > sample.c
> 
> produces me an empty sample.c (zero byte) and the following compile
> fails. This happens with current source code release 1.1.16.1 as well
> as current svn-checkout.
> 
> thanks for any hints

When did you install/update cygwin ?

I installed it (well re^12-installed it) yesterday and got the same
problem.
-- 
Sebastien Pouliot  <[EMAIL PROTECTED]>
Blog: http://pages.infinit.net/ctech/

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new patch)

[Ympostor]

Kornél Pál escribió:
> This conversion is restricted to constants. And it should be simple rather 
> than a complex language converter.

But perhaps tomorrow you need constans and X; and in one month you see 
that you need Y too, and then Z... And you could have finished it 
earlier reusing code..? :)


> BTW who do you mean on the SD guys?

Sorry for not clarifying, SD: SharpDevelop.

Regards.

-- 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new patch)

[Kornél Pál]

This conversion is restricted to constants. And it should be simple rather 
than a complex language converter.

BTW who do you mean on the SD guys?

Kornél

- Original Message - 
From: "Ympostor" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, August 24, 2006 12:24 PM
Subject: Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new 
patch)


Kornél Pál escribió:
> I think we already have perl dependency. I decided to use perl because 
> this
> conversion is done solely using regular expressions and perl is good at 
> it.
> On the other hand things in the common directory are built before any
> bootstrap compilation is done it may be better not to rely on mcs in this
> directory.
>
> Anyway if others prefer to have a cs2vb.cs instead I'll port it to C#
> because it's really small work.

Thanks for both answers Kornel and Robert.

BTW, there is already some implementation of language conversion
utilities, which could be reused here AFAIK, from the SD guys. But I
don't know if the use of mono-lite implies any restriction on the code
used that could not be fulfilled the mentioned utilities...

Regards.

-- 

___
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] Generate Consts.vb from Consts.cs (new patch)

[Ympostor]

Kornél Pál escribió:
> I think we already have perl dependency. I decided to use perl because this 
> conversion is done solely using regular expressions and perl is good at it. 
> On the other hand things in the common directory are built before any 
> bootstrap compilation is done it may be better not to rely on mcs in this 
> directory.
> 
> Anyway if others prefer to have a cs2vb.cs instead I'll port it to C# 
> because it's really small work.

Thanks for both answers Kornel and Robert.

BTW, there is already some implementation of language conversion 
utilities, which could be reused here AFAIK, from the SD guys. But I 
don't know if the use of mono-lite implies any restriction on the code 
used that could not be fulfilled the mentioned utilities...

Regards.

-- 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new patch)

[Robert Jordan]

Ympostor wrote:
> Kornél Pál wrote:
>> I've done some more work on cs2vb.pl; now I consider it being complete.
> 
> I might be wrong but I am wondering if it is consistent to use Perl for 
> this kind of things, inside the mono project. It would be more logical 
> to use Mono itself, and then not having another external dependency 
> (Mono depending on Perl??), right?

I'm pretty sure Kornél won't disagree if you'd rewrite
this in C#. And don't forget to take care about the
bootstrapping using mono-lite, because at this stage
the class libs don't exist ;-)

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new patch)

[Kornél Pál]

Hi,

I think we already have perl dependency. I decided to use perl because this 
conversion is done solely using regular expressions and perl is good at it. 
On the other hand things in the common directory are built before any 
bootstrap compilation is done it may be better not to rely on mcs in this 
directory.

Anyway if others prefer to have a cs2vb.cs instead I'll port it to C# 
because it's really small work.

Kornél

- Original Message - 
From: "Ympostor" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, August 24, 2006 11:41 AM
Subject: Re: [Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new 
patch)


Kornél Pál wrote:
> I've done some more work on cs2vb.pl; now I consider it being complete.

I might be wrong but I am wondering if it is consistent to use Perl for
this kind of things, inside the mono project. It would be more logical
to use Mono itself, and then not having another external dependency
(Mono depending on Perl??), right?

Regards.

-- 

___
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] Generate Consts.vb from Consts.cs (new patch)

[Ympostor]

Kornél Pál wrote:
> I've done some more work on cs2vb.pl; now I consider it being complete.

I might be wrong but I am wondering if it is consistent to use Perl for 
this kind of things, inside the mono project. It would be more logical 
to use Mono itself, and then not having another external dependency 
(Mono depending on Perl??), right?

Regards.

-- 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Generate Consts.vb from Consts.cs (new patch)

[Kornél Pál]

Hi,

I've done some more work on cs2vb.pl; now I consider it being complete.

Kornél

- Original Message - 
From: "Kornél Pál" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, August 23, 2006 8:17 PM
Subject: [PATCH] Generate Consts.vb from Consts.cs



Hi,

Microsoft.VisualBasic and vbnc are written in VB. Consts.cs contains
contants that are usable in these assemblies as well so it is preferable 
to

have a Consts.vb as well.

I created cs2vb.pl that is intended to generate Consts.vb from Consts.cs 
so

that only Consts.cs.in has to be maintained by hand.

Please review and approve the patch.

Kornél



Consts.vb.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] Application deployment questions

[Robert Jordan]

Lucifer wrote:
> Hi everyone,
> 
> I have read this article though sill not quite understand how to do it.
> http://www.mono-project.com/Guidelines:Application_Deployment
> 
> The normal way to run an application compiled with Mono would be to invoke
> it through the Mono runtime, like this: mono myprogram.exe
> However, I have to deploy my application to end users that are not supposed
> to have Mono runtime/libs installed.
> 
> What's the best practice for deployment?
> 
> I'm planning on packing my application EXE with required DLLs such as
> intl.dll, libglib-2.0-0.dll, mono-1.dll, etc., and the mono.exe.
> Is it a feasible way to do?

All *.dlls from Mono's bin folder are needed, unless you
can prove that your app doesn't touch one of them.

You should build the following hierarchy:

yourapp\
yourapp\bin\yourapp.exe
yourapp\bin\mono.exe
yourapp\bin\*.dll
yourapp\etc\mono\  copied from $monoprefix\etc\mono
yourapp\lib\mono\  copied from $monoprefix\lib\mono


> Would it be a better way if I embed Mono runtime(mono.exe) in my
> application?

Not w/out duplicating mkbundle's work.

> http://www.mono-project.com/Embedding_Mono
> In addition, I checked out mkbundle.exe to realize that it is for Linux only
> that is unable to use it for Win32 or MacOSX.

Mkbundle as of Mono 1.1.14 works in Windows.

Under MacOS just some settings are missing. Use the following
shell script:

---cut-here---
#!/bin/bash

PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Libraries/pkgconfig
DYLD_LIBRARY_PATH=/Library/Frameworks/Mono.framework/Libraries

export PKG_CONFIG_PATH DYLD_LIBRARY_PATH

mkbundle $*
---cut-here---


> Second question:
> While Mono.exe startup, it would search '\mono\2.0\' path for 'mscorlib.dll'
> even if I write code such as: mono_set_dirs("", "") to change its search
> path.
> I tried to place 'mscorlib.dll' in the same directory with my application
> EXE but it's not worked and the assembly can't be found.
> How could I do it right?

With mono_set_dirs("", "") you'd need the following directory
structure:

yourapp.exe
mono\

The contents of "mono" must be built by copying (recursive) the
contents of the following folders:

$monoprefix\etc\mono\*
$monoprefix\lib\mono\*

It would be much saner from maintainer's point of view
to build this hierarchy:

yourapp.exe
etc\mono   <- copied from  $monoprefix\etc\mono
lib\mono   <- copied from  $monoprefix\lib\mono

and call mono_set_dirs("lib", "etc");

You should make "lib" and "etc" absolute.

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Application deployment questions

[Lucifer]

Hi everyone,

I have read this article though sill not quite understand how to do it.
http://www.mono-project.com/Guidelines:Application_Deployment

The normal way to run an application compiled with Mono would be to invoke
it through the Mono runtime, like this: mono myprogram.exe
However, I have to deploy my application to end users that are not supposed
to have Mono runtime/libs installed.

What's the best practice for deployment?

I'm planning on packing my application EXE with required DLLs such as
intl.dll, libglib-2.0-0.dll, mono-1.dll, etc., and the mono.exe.
Is it a feasible way to do?
Would it be a better way if I embed Mono runtime(mono.exe) in my
application?
http://www.mono-project.com/Embedding_Mono
In addition, I checked out mkbundle.exe to realize that it is for Linux only
that is unable to use it for Win32 or MacOSX.

Second question:
While Mono.exe startup, it would search '\mono\2.0\' path for 'mscorlib.dll'
even if I write code such as: mono_set_dirs("", "") to change its search
path.
I tried to place 'mscorlib.dll' in the same directory with my application
EXE but it's not worked and the assembly can't be found.
How could I do it right?


Any comments/suggestions would be much appreciated. Thanks in advanced.

Regards.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] DataSet : Trouble with Relation and ForeignKey ...

[Konstantin Triger]

Hi,

Does it work on ms .net?
Can you drop a test case reproducing the problem?

Regards,
Konstantin Triger

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of xiii29
Sent: Wednesday, August 23, 2006 11:55 PM
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] DataSet : Trouble with Relation and ForeignKey ...

Hi,

My applications uses a DataSet with DataRelations to store information.
After created a relation, I also create a ForeignKey between the same 
two columns.

With the 1.1.13.4 version of mono : no trouble everything is working.

With the 1.1.16.1 version of mono : I get this messages :
/Unhandled Exception: System.Data.DataException: Constraint matches 
contraint named '' already in collection/

I think I'm doing something twice by creating a DataRelation and a 
Constraint, so which one include the other one ?

Thanks for answer !








___
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 for UnixClient

[Lukas Lipka]

Hi,

attached is the patch for the UnixClient docs.

Cheers,
Lukas

On Ut, 2006-08-22 at 10:52 -0400, Miguel de Icaza wrote:
> Hello,
> 
> > attached is a patch to make UnixClient more TcpClient like on 2.0.
> > Mainly needed to make the Client property public.
> 
> This looks good, but please provide also a patch for the documentation
> in monodoc/class that would reflect these changes.
> 
> You can use `monodocer' to update the particular docs.
Index: class/Mono.Posix/en/Mono.Unix/UnixClient.xml
===
--- class/Mono.Posix/en/Mono.Unix/UnixClient.xml	(revision 64196)
+++ class/Mono.Posix/en/Mono.Unix/UnixClient.xml	(working copy)
@@ -146,8 +146,20 @@
 To be added.
   
 
+
+  
+  Property
+  
+System.Int32
+  
+  
+To be added.
+To be added.
+To be added.
+  
+
 
-  
+  
   Property
   
 System.Net.Sockets.Socket
@@ -158,6 +170,18 @@
 To be added.
   
 
+
+  
+  Property
+  
+System.Boolean
+  
+  
+To be added.
+To be added.
+To be added.
+  
+
 
   
   Property
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] build on win failed on ./monoburg ./sample.brg > sample.c

[Timo Rainio]

hi all,
building mono on windows when in /trunk/mono/mono/monoburg the following 
command:

./monoburg ./sample.brg > sample.c

produces me an empty sample.c (zero byte) and the following compile fails. This 
happens with current source code release 1.1.16.1 as well as current 
svn-checkout.

thanks for any hints
-timo77
-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Patch to avoid some race conditions on the mono runtime

[briaeros007]

Hello,
In my work, i have to use mono with a specific thread library. Mono
with the use of this library show some race conditions that i've tried
to fixed.
In the patch we can see three modifications of the file mini.c.
The first two are modifications which avoid to put two times the same
fonction in a table.
The last modification (which corresponds to the two last modifications
on the patch) was done since we have plenty of bugs which aren't
reproductibles, but all theses bugs have this fonction as a common
point. In this way we have just extend the critical section. this
modifications permits to run our tests program without any scratch.

yours sincerely

Ps: the version of mono i used is the 1.1.16.1

---
Subete ga wakatta toki…watashi ga anta wo korosu.
diff -abur mono-1.1.16.1/mono/mini/mini.c mono-1.1.16.1.1/mono/mini/mini.c
--- mono-1.1.16.1/mono/mini/mini.c	2006-07-05 23:55:50.0 +0200
+++ mono-1.1.16.1.1/mono/mini/mini.c	2006-08-04 09:22:11.418560308 +0200
@@ -2848,12 +2848,15 @@
 
 	info = mono_find_jit_icall_by_name (icall_name);
 	if (info == NULL) {
+	  mono_jit_lock ();
+	  info = mono_find_jit_icall_by_name (icall_name);
+	  if (info == NULL) {
 		esig = mono_get_array_new_va_signature (rank);
 		name = g_strdup (icall_name);
 		info = mono_register_jit_icall (mono_array_new_va, name, esig, FALSE);
 
-		mono_jit_lock ();
 		g_hash_table_insert (jit_icall_name_hash, name, name);
+	  }
 		mono_jit_unlock ();
 	}
 
@@ -3052,13 +3055,18 @@
 
 	info = mono_find_jit_icall_by_name (icall_name);
 	if (info == NULL) {
+	  mono_jit_lock();
+	  info = mono_find_jit_icall_by_name (icall_name);
+	  if(info==NULL){
 		esig = mono_get_element_address_signature (rank);
 		name = g_strdup (icall_name);
 		info = mono_register_jit_icall (ves_array_element_address, name, esig, FALSE);
 
-		mono_jit_lock ();
+		/*mono_jit_lock ();*/
 		g_hash_table_insert (jit_icall_name_hash, name, name);
-		mono_jit_unlock ();
+		/*mono_jit_unlock ();*/
+	  }
+	  mono_jit_unlock();
 	}
 
 	temp = mono_emit_native_call (cfg, bblock, mono_icall_get_wrapper (info), info->sig, sp, ip, FALSE, FALSE);
@@ -10284,7 +10292,6 @@
 		}
 	}
 
-	mono_domain_unlock (target_domain);
 	p = mono_create_ftnptr (target_domain, mono_jit_compile_method_inner (method, target_domain, opt));
 
 	if (callinfo) {
@@ -10296,7 +10303,7 @@
 		}
 		mono_jit_unlock ();
 	}
-
+	mono_domain_unlock (target_domain);
 	return p;
 }
 
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list