Re: [Mono-dev] Status of CodeAccessSecurity (CAS)?
On 11/14/07 David Wolinsky wrote: In mono version r88278 ... this code crashes really bad (see below). I just wanted to know if anyone was actively working on this? Also is anyone working on the FileIOPermission? Please file a bug report, though implementing CAS is not a priority for us some other people (or you:) may want to contribute. In this particular case we likely do the CAS initialization from the wrong place so you end up with a circular initialization issue. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Tracking test runs...
On 11/13/07 David Miller wrote: https://bugzilla.novell.com/tr_list_runs.cgi?plan_id=702 Do I really have to create a novell login just to look at the test runs? I've been trying to avoid having to create an account, and I can understand requiring it for submitting new bugs, but for looking at existing public bugs and testrun results, that simply doesn't make any sense and seem to me to deter new contributors. I agree that the results should be readily available, this test setup has just been started, so allow for some teething problems:) Once the current release work is completed I'd also like the testopia features to be available to contributors, so that testing for architectures and systems we don't have access to (or we don't have testing bandwith for) can be done by contributors and collected in the same place as the test runs we do in house. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH]: Rewrite instruction list handling.
On 11/12/07 David Miller wrote: In fact, significant chunks special list handling code got removed. And I am certain many other significant cleanups and simplifications become possible after this patch goes in. I agree with the general change, but it's better to just add a prev field in MonoInst. This way we don't need to change all the code in all the architectures and risk regressions (some of which can be subtle as with many low-level JIT changes). With the new field in MonoInst that change can be done much more incrementally and so it can also be incrementally tested. Thanks! lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MONO_LOG_MASK type
On 11/08/07 Sanghyeon Seo wrote: mono(1) lists type as a possible value for MONO_LOG_MASK, but it doesn't seem to do anything. I thought it would log when types are loaded (is that the intended purpose?). Is there other way to see what types are loaded? There is curently no trace event associated with TYPE. You can use the profiler interface for this, though. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix.
Hi all, Please review the attached patch. It contains synchronization fix for the class WebClientAsyncResult and light changes for the class WebClientProtocol that is a base of SoapHttpClientProtocol for thread safety purpose. WebServicesProtocolPatch.patch Description: WebServicesProtocolPatch.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] 64-bit installer
On 11/06/07 Sharique uddin Ahmed Farooqui wrote: Now 64 bit system are become norms, more linux users are moving 64-bit version of their distro. I think we should hav 64-bit installer now. We do provide packages for many 64 bit systems and packages are the suggested way to install mono. The single binary installer is provided only for the desperate cases. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH]: Rewrite instruction list handling.
On 11/15/07 David Miller wrote: All it takes is someone able to test my patch on those remaining platforms and about an hour of developer time to weed out any regressions. I'm just saying that waiting for that is likely going to take several days, as we don't have the power to force contributors of, say, the alpha, hppa and mips ports to do the needed testing. And in the meantime you risk having to deal with any merge conflicts that arise with such a large patch. I disagree that adding a 'prev' field is the way to implement these changes especially since I've done all the work already. Changing your code to use the existing next field and adding a prev field should be a minimal change and it wouldn't require all the architectures to be updated at once, so we could commit it sooner. If you don't have time for that, I could look at it as my time permits. Thanks! lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Tracking test runs...
Paolo Molaro wrote: On 11/13/07 David Miller wrote: https://bugzilla.novell.com/tr_list_runs.cgi?plan_id=702 Do I really have to create a novell login just to look at the test runs? Actually, it looks like right now only Novell employees have access to Testopia. There's a bug filed to open Testopia up to external people. I talked with the guy who's overseeing this, and he said that they hope to have all of their security audits and whatnot done in the next few months. I've been trying to avoid having to create an account, and I can understand requiring it for submitting new bugs, but for looking at existing public bugs and testrun results, that simply doesn't make any sense and seem to me to deter new contributors. Actually, all of the non-security related Mono bugs can be seen without having to login. Mono bugs are completely open to the public by default. When filing a new bug, you actually have to manually change the bug to internal. I agree that the results should be readily available, this test setup has just been started, so allow for some teething problems:) Exactly! :) Once the current release work is completed I'd also like the testopia features to be available to contributors, so that testing for architectures and systems we don't have access to (or we don't have testing bandwith for) can be done by contributors and collected in the same place as the test runs we do in house. The Mono QA team would like this very much. We understand just how much the OSS community helps us out, and we'd love for Testopia to be a coordination point for this work. Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] GTK# NUnit Gui
Hi All, Is anyone currently maintaining this? Would you be interested in putting it under the umbrella of the (new) NUnit 3.0 Testing Platform - shortly to be announced more widely? I'm seeing this as a sort of meta-project, so component projects could stay where they are, but we would be making sure that each component stayed up to date with the latest NUnit. BTW, I'm considering using Launchpad, at least for the coordination and packaging level of the various projects. If anyone has experience using it, I'd be glad to have your thoughts on how well it works - offline most likely is best. Alternatively, you can jump in on the nunitv3 group on Google, which is now public. Charlie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] String comparison failing between C# and C
Hello,
I'm currently testing Mono's interoperability between C# and C code, and
have run into an interesting scenario.
In my test case I have a C shared object that implements two functions:
setString and getString. The first function, setString, simply copies the
string into a local buffer. The second function, getString, returns a
pointer to the internal buffer holding the string.
What's interesting is that the first case (in the below C# code) fails when
it tries to compare hello against the return value of getString. Is this
a problem with trying to compare a unicode string with an ansi string? This
test case passes when running under Windows via CLR...fails in Linux via
Mono.
The second case, hello == s, passes.
namespace MonoEvaluation.Interop
{
public class Tester : ITester
{
[DllImport(InteropServerDllC)]
static extern void setString(string s);
[DllImport(InteropServerDllC)]
static extern string getString();
bool StringTest()
{
setString(hello);
string s = getString();
if (hello == getString())
{
Console.WriteLine(hello == getString passed!);
}
else
{
Console.WriteLine(hello == getString failed!);
return false;
}
if ((hello == s)
{
Console.WriteLine(hello == s passed!);
}
else
{
Console.WriteLine(hello == s failed!);
return false;
}
return true;
}
}
}
I'm running this on an embedded PPC Arabella Linux system, using mono
version 1.2.5.1.
Thanks in Advance,
Dan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] String comparison failing between C# and C
Dan Osawa wrote:
Hello,
I'm currently testing Mono's interoperability between C# and C code, and
have run into an interesting scenario.
In my test case I have a C shared object that implements two functions:
setString and getString. The first function, setString, simply copies the
string into a local buffer. The second function, getString, returns a
pointer to the internal buffer holding the string.
What's interesting is that the first case (in the below C# code) fails when
it tries to compare hello against the return value of getString. Is this
a problem with trying to compare a unicode string with an ansi string? This
test case passes when running under Windows via CLR...fails in Linux via
Mono.
The error is most likely in your C code you didn't post.
You're probably returning a const ptr to a string:
char *
getString ()
{
return hello;
}
This is wrong. The interop rules demand that that string was
allocated from the heap:
char *
getString ()
{
return strdup (hello);
}
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] String comparison failing between C# and C
Hi Dan,
please reply to the list.
After invoking getString() the first time, mono will free the
unmanaged string, which will corrupt your global _cp field.
Change you code to always return new instances of the string,
allocated from the heap either using malloc or functions using
malloc, e.g. strdup.
Robert
Dan Osawa wrote:
Sorry, I should have included the C code. I am actually allocating memory
from the heap.
char * _cp=0;
void setString(char * cp)
{
if(_cp != 0)
delete[] _cp;
_cp = new char[strlen(cp)+1];
strcpy(_cp, cp);
}
char * getString()
{
return _cp;
}
On 11/15/07, Robert Jordan [EMAIL PROTECTED] wrote:
Dan Osawa wrote:
Hello,
I'm currently testing Mono's interoperability between C# and C code, and
have run into an interesting scenario.
In my test case I have a C shared object that implements two functions:
setString and getString. The first function, setString, simply copies
the
string into a local buffer. The second function, getString, returns a
pointer to the internal buffer holding the string.
What's interesting is that the first case (in the below C# code) fails
when
it tries to compare hello against the return value of getString. Is
this
a problem with trying to compare a unicode string with an ansi
string? This
test case passes when running under Windows via CLR...fails in Linux via
Mono.
The error is most likely in your C code you didn't post.
You're probably returning a const ptr to a string:
char *
getString ()
{
return hello;
}
This is wrong. The interop rules demand that that string was
allocated from the heap:
char *
getString ()
{
return strdup (hello);
}
Robert
___
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] DllNotFoundException: gdiplus.so
Gents, you will probably laugh at me, but I cannot for the life of me figure out how to get this to work. I am using monodevelop to write a little app. As soon as I want to see any widget properties or the toolbox, I get an unhandled exception saying that it could not find gdiplus.dll. So I look up the relevant stuff (such as http://www.mono-project.com/DllNotFoundException), I follow all the advice, and still, no luck. The relevant config files have been updated, i.e. they contain a dllmap entry and now it is complaining about not being able to load libgdiplus.so. I have added the relevant folders to my path variable, added a LD_LIBRARY_PATH variable, you name it, no success. System runs debian etch, monodevelop was compiled from source. Most other things seem to work fine (haven't tried everything yet). Any pointers would be highly appreciated. regards Wolfgang ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Remoting question
Hi to all: Is posbile to use Mono.Remotng with classes that have methods with class return type or object as return? thanks Mauricio ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH]: Rewrite instruction list handling.
I forgot to specify in my initial patch posting that the code is being contributed under MIT/X11 terms. Sorry for not making that clear from the beginning. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Would reading this contaminate a programer inthe eyes of Mono?
Would reading this contaminate a programer inthe eyes of Mono? (the quote is from the sharp OS list (an atempt to write an os using the maximum amount of C#)) Thanks, Dennis http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/ A nice article, from 2 years ago, talking in detail about how .NET 1.1 JITs, what its vtables look like, and how its various heaps line up. Straight from the horses mouth. - Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now.___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Would reading this contaminate a programer inthe eyes of Mono?
Would reading this contaminate a programer inthe eyes of Mono? (the quote is from the sharp OS list (an atempt to write an os using the maximum amount of C#)) Not at all. But the concepts on that article might not apply to Mono directly. It would be useful if someone wrote the equivalent for Mono as many of the concepts there just do not exist in Mono, we have a different implementation approach. Thanks, Dennis http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/ A nice article, from 2 years ago, talking in detail about how .NET 1.1 JITs, what its vtables look like, and how its various heaps line up. Straight from the horses mouth. __ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. ___ 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
