Re: [Mono-dev] Develop for iPad on the iPad
Hi Mauricio, buhochile...@gmail.com wrote: Well, you are in did really positive this morning, you just forget to mention that the future of monotouch is at least uncertain at this moment (may be is worse than that)... Better to be honest with people than keep selling licence for something that may it can't be used later.. [citation needed] In all seriousness, I think that it's not as bad as people are making it out to be. Everyone who is been the loudest are not under an NDA, and the people I talk to who are under the NDA seem to hint that it is not as big of a deal as it is made out to be. Somehow I think that if the Mono guys have been able to do what they've done with .NET and Microsoft, that Monotouch will come out Ok. *IANAL, nor am I on the Mono team, nor do I speak officially for anyone. YMMV. HAND. -- Cory Foy http://www.coryfoy.com http://twitter.com/cory_foy ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Develop for iPad on the iPad
Hi Mauricio [Mods: This is my last reply, then I'm letting this drop. Promise.] buhochile...@gmail.com wrote: In all seriousness, I think that it's not as bad as people are making it Not as bad, are you serious?, you must read the NDA again, is very, very clear and specific, there is no room for misunderstandings. I've read the NDA. I understand the implications. I have plenty of ideas on how to work around it. I'm no stranger to idiotic licensing schemes. I'm not suggesting you are wrong, I'm saying that the lack of information coming from the MT team may simply be a reflection of them understanding clearly how to work around it, having worked with a legal team to understand it, and not being able to say a word because of the NDA they are under. Never explain with malice that which can be explained by being hit with a stuffed monkey. -- Cory Foy http://www.coryfoy.com http://twitter.com/cory_foy ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Make System.IO.Ports work on UNIX systems other than Linux
Hi Robert, Robert Nagy wrote: Hey Basically on linux ttyS* and ttyUSB* is used for serial device names, but this is not the case for *BSD, Solaris and probably OS X. If this helps: macbook-pro:dev foyc$ ls tty* tty ttyse tty.BlackBerry9530-BlackBer-1 ttysf tty.Bluetooth-Modem ttyt0 tty.Bluetooth-PDA-Sync ttyt1 ttyp0 ttyt2 ttyp1 ttyt3 ttyp2 ttyt4 ttyp3 ttyt5 ttyp4 ttyt6 ttyp5 ttyt7 ttyp6 ttyt8 ttyp7 ttyt9 ttyp8 ttyta ttyp9 ttytb ttypa ttytc ttypb ttytd ttypc ttyte ttypd ttytf ttype ttyu0 ttypf ttyu1 ttyq0 ttyu2 ttyq1 ttyu3 ttyq2 ttyu4 ttyq3 ttyu5 ttyq4 ttyu6 ttyq5 ttyu7 ttyq6 ttyu8 ttyq7 ttyu9 ttyq8 ttyua ttyq9 ttyub ttyqa ttyuc ttyqb ttyud ttyqc ttyue ttyqd ttyuf ttyqe ttyv0 ttyqf ttyv1 ttyr0 ttyv2 ttyr1 ttyv3 ttyr2 ttyv4 ttyr3 ttyv5 ttyr4 ttyv6 ttyr5 ttyv7 ttyr6 ttyv8 ttyr7 ttyv9 ttyr8 ttyva ttyr9 ttyvb ttyra ttyvc ttyrb ttyvd ttyrc ttyve ttyrd ttyvf ttyre ttyw0 ttyrf ttyw1 ttys0 ttyw2 ttys000 ttyw3 ttys1 ttyw4 ttys2 ttyw5 ttys3 ttyw6 ttys4 ttyw7 ttys5 ttyw8 ttys6 ttyw9 ttys7 ttywa ttys8 ttywb ttys9 ttywc ttysa ttywd ttysb ttywe ttysc ttywf ttysd -- Cory Foy http://www.coryfoy.com http://twitter.com/cory_foy ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing #region and #endregion from source code`
Atsushi Eno wrote: I disagree; the only people who actually hack the source file should have the right to decision. When I read comments like that, it makes me think that there is an air of elitism to it, and that if you aren't touching source, you don't have a say. I don't know if that's what you intended, but I wonder if it would be better to have the community come to a consensus about it, rather than excluding certain opinions. -- Cory Foy http://www.cornetdesign.com http://www.agileflorida.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building Mono from Source
Hi All, I had previously written about a problem compiling Mono from source on Gentoo. I didn't get any responses, but I did come across the following posting: http://lists.ximian.com/pipermail/mono-devel-list/2005-November/015886.html which said to go into the libgc directory and run autogen. I did, but I got the message: configure: error: This module is now part of `mono' and can't be built as a stand-alone module any longer. I tried running autogen back on the mono directory again anyway, and it didn't change anything, so I'm hoping someone else has some insight into what the next steps would be. Thanks! -- Cory Foy http://www.cornetdesign.com ___ 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 from Source
Zoltan Varga wrote: This should be fixed in SVN. In the meantime, try deleting libgc/libtool.m4 and rerunning autogen.sh. Aha! Yep, that fixed it exactly. Thanks! -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building from Source failing - libtool version mismatch
Hi All, Trying to build mono from source. I grabbed the latest head from SVN, and kicked off ./autogen.sh --prefix=/usr/local. After much printing, I get the following: == checking for correct ltmain.sh version... no configure: error: *** [Gentoo] sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.22, ltmain.sh = 1.5.6) *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. configure: error: /bin/sh './configure' failed for libgc == I'm using Gentoo, and looking at emerge, I'm running the latest stable version of libtool. Should I grab an unstable version, or is there something else I need to do? Thanks! -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Where is System.Windows.Forms?
Silly question, but I can't seem to find the source for System.Windows.Forms anywhere. I downloaded the sources for mono and other platforms like gtksharp. Can somebody thump me upside the head and point me to where the code is? Thanks! -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Where is System.Windows.Forms?
Peter Dennis Bartok wrote: They're in the mcs module, path mcs/class/Managed.Windows.Forms Aha. Much appreciated! -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] implement me in class.c
Hi All, I've been working on getting the NUnit GUI working with Mono on Linux, and got the following: ** (unknown:16782): WARNING **: implement me 0x00 ** ERROR **: file class.c: line 3190 (mono_class_from_mono_type): should not be reached aborting... Aborted looking in class.c, I see that happens when the type passed in to mono_class_from_mono_type falls through the case statements. But I don't see how to determine what the type was that caused it to fall through. Any thoughts? -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] implement me in class.c
Peter Dennis Bartok wrote: What exactly are you doing when you get that? What version of nunit? What version of mono? Because nunit-gui (these days I believe it's just called nunit.exe) starts (and runs for the most part) fine for me. On you on Windows? I'm on Linux, running the latest 2.4 code from HEAD (modified to allow the GUI components to build on Linux). I start up the GUI with: mono nunit.exe nunit-console.tests.dll The GUI comes up, but I've been battling problems when I try to run the tests. Generally they've been SIGSEGVing when it tries to make what appears to be the cross-domain call into the tests, but for some reason this run let me get this far. -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Invariant Culture question
Thanks for the replies of why CultureInfo.ToString was empty - because it was an invariant culture, which doesn't have a name. My question now is, why is it Invariant Culture? Is it a Linux specific thing? Is there a reason we couldn't determine the culture for the platform in Mono? Any help or pointers would be gladly appreciated. I'm trying to determine if we should just limit our CultureInfo tests to the .NET platform only, or if there is something that could be done to determine the local CultureInfo. Thanks! -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CurrentCulture Empty?
Can anyone provide some info about whether CultureInfo should be
working? Thanks!
Cory
Cory Foy wrote:
Hi All,
We noticed that our tests in NUnit around CultureInfo were failing with
an empty culture info. I was going to dig through the Mono source, but
CultureInfo is apparantly not the most straightforward thing to pull.
Do I need to open a bug report on this?
Thanks!
Cory
-
[EMAIL PROTECTED] ~/workspace/monobugs $ mono -V
Mono JIT compiler version 1.1.15, (C) 2002-2005 Novell, Inc and
Contributors. www.mono-project.com
TLS: normal
GC:Included Boehm (with typed GC)
SIGSEGV: normal
Disabled: none
[EMAIL PROTECTED] ~/workspace/monobugs $ cat CultureBug.cs
using System;
using System.Globalization;
public class TestCultureInfo
{
public static void Main(String[] args)
{
Console.WriteLine(Current Culture: +
CultureInfo.CurrentCulture.ToString());
Console.WriteLine(Current UICulture: +
CultureInfo.CurrentUICulture.ToString());
}
}
[EMAIL PROTECTED] ~/workspace/monobugs $ mcs CultureBug.cs
[EMAIL PROTECTED] ~/workspace/monobugs $ mono CultureBug.exe
Current Culture:
Current UICulture:
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Cory Foy
http://www.cornetdesign.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: Registry Bug still around?
[Reposting - I forgot to CC the list] Hi Robert, Robert Jordan wrote: RegistryKey.GetSubKeyNames() returns unix paths instead of key names. Please file a bug. Consider it done. If I didn't get any part of it right, let me know. I also included your comments into it: http://bugzilla.ximian.com/show_bug.cgi?id=78519 -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: 1.1.14 and UnixRegistryApi
Robert Jordan wrote: Robert Jordan wrote: Since there is no cast in UnixRegistryApi:DeleteValue any more, I suppose you didn't update correctly or the stack trace above is wrong. Please reopen http://bugzilla.ximian.com/show_bug.cgi?id=2 and attach a test case. You were right! It did only on the stable branch. It's now in SVN head too. Oh good. I've been traveling and hadn't had a chance to look at it, but my next question was going to be how to tell what Mono version NAnt was using. But I'm glad that it's in there! Thanks for taking the time to check it out - I'll grab the latest source this weekend and see if we can't get these NUnit tests passing. Cory ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 1.1.14 and UnixRegistryApi
Hello, I just downloaded the latest 1.14 and am still getting the UnixRegistryApi error I had posted about before: [exec] 8) NUnit.Util.Tests.NUnitRegistryTests.TestClearRoutines : System.InvalidCastException : Cannot cast from source type to destination type. [exec] in 0x0008a Microsoft.Win32.UnixRegistryApi:DeleteValue (Microsoft.Win32.RegistryKey rkey, System.String value, Boolean throw_if_missing) [exec] in 0x00035 Microsoft.Win32.RegistryKey:DeleteValue (System.String value, Boolean shouldThrowWhenKeyMissing) [exec] in 0xf Microsoft.Win32.RegistryKey:DeleteValue (System.String value) [exec] in (wrapper remoting-invoke-with-check) Microsoft.Win32.RegistryKey:DeleteValue (string) Did the patch not make it into the build? This is the main thing keeping NUnit at being from 100% tests run on Mono/Linux. Thanks! Cory ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: UnixRegistryApi question
Robert Jordan wrote: We both made the mistake not filling a bug. If you want to speed this up, please fill a bug report at http://bugzilla.ximian.com/ product: Mono class libraries, CORLIB. Sorry! http://bugzilla.ximian.com/show_bug.cgi?id=2 Cory ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UnixRegistryApi question
Hi All,
I'm building NUnit on Linux with the latest version of Mono (.14) and am
getting the following:
[exec] 5) NUnit.Util.Tests.NUnitRegistryTests.TestClearRoutines :
System.InvalidCastException : Cannot cast from source type to
destination type.
[exec] in 0x00095 Microsoft.Win32.UnixRegistryApi:DeleteValue
(Microsoft.Win32.RegistryKey rkey, System.String value, Boolean
throw_if_missing)
[exec] in 0x00038 Microsoft.Win32.RegistryKey:DeleteValue
(System.String value, Boolean shouldThrowWhenKeyMissing)
[exec] in 0xf Microsoft.Win32.RegistryKey:DeleteValue
(System.String value)
[exec] in (wrapper remoting-invoke-with-check)
Microsoft.Win32.RegistryKey:DeleteValue (string)
[exec] in 0x00070 NUnit.Util.NUnitRegistry:ClearKey
(Microsoft.Win32.RegistryKey key)
[exec] in 0x00030 NUnit.Util.NUnitRegistry:ClearSubKey
(Microsoft.Win32.RegistryKey baseKey, System.String subKey)
[exec] in 0x00023 NUnit.Util.NUnitRegistry:ClearTestKeys ()
[exec] in 0x00139
NUnit.Util.Tests.NUnitRegistryTests:TestClearRoutines ()
[exec] in 0x0 unknown method
[exec] in (wrapper managed-to-native)
System.Reflection.MonoMethod:InternalInvoke (object,object[])
[exec] in 0x0008d System.Reflection.MonoMethod:Invoke
(System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder
binder, System.Object[] parameters, System.Globalization.CultureInfo
culture)
The code is pretty straightforward:
public static void ClearKey( RegistryKey key )
{
foreach( string name in key.GetValueNames() )
key.DeleteValue( name );
foreach( string name in key.GetSubKeyNames() )
key.DeleteSubKeyTree( name );
}
Does this look to you all to be a bug in the UnixRegistryApi, or
something innocuous like an invalid name? The code that is calling
ClearKey verifies that the RegistryKey it is passing in isn't null. Any
pointers would be appreciated. Thanks!
Cory
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
