Re: [Mono-dev] Afallon: open source WPF implementation
There is a subset of the WPF framework implemented in the .net microframework. It might be a good starting point (xaml parsing, data binding scaffolding perhaps?) - you'd almost certainly need to rewrite all the rendering code however as I believe it is a software renderer. On Thu, Jun 13, 2013 at 3:45 PM, Stephen Shaw ss...@decriptor.com wrote: Do you have the code published somewhere? Cheers, Stephen PS. good luck on this big task. On Thu, Jun 13, 2013 at 1:41 PM, Jonathan Lima greenbo...@gmail.com wrote: In my view, WPF is the most complex and powerful UI system ever created(the layout and the composing system are amazing) and I really need an opensource implementation of the Presentation Framework to use it on other platforms and to have more control about it(rendering it into an OpenGL window maybe). I know that this will be a long road and that maybe it would never be 100% complete, but I'm starting to develop Afallon(it's another way to write Avalon :D), an opensource implementation of the current version of WPF. I'll develop it aiming in a good platform abstraction and a good performance. I already have a good base done, I think. Now I want to ask: Is there someone that would want to help in the development? It's a fairly large project and I need all help possible x.x Thanks for your time, Jonathan Lima ___ 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] Afallon: open source WPF implementation
I believe .net mf is apache licensed On Thu, Jun 13, 2013 at 4:31 PM, Jonathan Lima greenbo...@gmail.com wrote: Would I have licensing problems using Micro Framework code? I want to use any opensource license that I could use it on commercial projects(MIT probably). @Stephen I'm organizing the code as it is splitted across some projects, soon I'll put it into a git repo. On Thu, Jun 13, 2013 at 5:28 PM, Jeremy Bell bell.jer...@gmail.comwrote: There is a subset of the WPF framework implemented in the .net microframework. It might be a good starting point (xaml parsing, data binding scaffolding perhaps?) - you'd almost certainly need to rewrite all the rendering code however as I believe it is a software renderer. On Thu, Jun 13, 2013 at 3:45 PM, Stephen Shaw ss...@decriptor.comwrote: Do you have the code published somewhere? Cheers, Stephen PS. good luck on this big task. On Thu, Jun 13, 2013 at 1:41 PM, Jonathan Lima greenbo...@gmail.com wrote: In my view, WPF is the most complex and powerful UI system ever created(the layout and the composing system are amazing) and I really need an opensource implementation of the Presentation Framework to use it on other platforms and to have more control about it(rendering it into an OpenGL window maybe). I know that this will be a long road and that maybe it would never be 100% complete, but I'm starting to develop Afallon(it's another way to write Avalon :D), an opensource implementation of the current version of WPF. I'll develop it aiming in a good platform abstraction and a good performance. I already have a good base done, I think. Now I want to ask: Is there someone that would want to help in the development? It's a fairly large project and I need all help possible x.x Thanks for your time, Jonathan Lima ___ 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] compile error (3.0.10) on my linux box.
Is the website itself on github? If not, I think this would be worthwhile. Then the community could submit pull requests to update the site - would free up the Xamarin devs to work on more useful things. On Fri, May 31, 2013 at 12:09 PM, eb65 e...@pipeline.com wrote: ...and, the libgdiplus-3.0.tar.bz2 package discussed in the v3 release notes for installation isn't available on the download page yet, and v3 is still listed as a beta version with v2.10 still listed as the latest stable version. C'mon guys, please update your website. -- View this message in context: http://mono.1490590.n4.nabble.com/compile-error-3-0-10-on-my-linux-box-tp4659534p4659831.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] make install doesn't copy monodroid profile assemblies to the prefix directory
Thanks Rodrigo. If you would, could you clarify on the issue of the AMQP driver? Do you mean the RabbitMQ library? So this would affect System.Messaging.dll, Mono.Messaging.dll, Mono.Messaging.RabbitMQ.dll, and RabbitMQ.Client.dll, correct? I'm not familiar with this RabbitMQ project but it is listed as being dual licensed under The Apache License v2 and The Mozilla Public License, although it has commercial support options. The Apache license should allow for modifications to the original library (and thus indirectly any generated code) and also distribution in binary form without the end-user reverse engineering requirement of the LGPL. As for the other DLLs - the source for those are all under mono/mcs/class, which lists the MIT license at the root of that directory, so in theory these should be free to distribute. Am I missing some dependency in the driver or the above DLLs? Thanks again, Jeremy On Wed, May 29, 2013 at 9:05 PM, Rodrigo Kumpera kump...@gmail.com wrote: The runtime is a mixture of LGPL and MIT and the BCL is mixture of MIT/X11 and compatible licenses such as the Microsoft variant of MIT. As the Debian guys found out there are some non-free files used to generate some files, but the byproduct is fine. This is for the AMQP driver, I believe. They are non-free because they cannot be changed even if they can be distributed freely. On Wed, May 29, 2013 at 12:59 PM, Jeremy Bell bell.jer...@gmail.comwrote: Thanks Rodrigo. Copying sounds like the way to go. As an aside, this is for an open source project and the intent is to use the core mono runtime under the terms of the LGPL as stated in the licensing documentation. If there is any code in the mono repository that isn't dual licensed (in other words, commercial only, with no option for LGPL use), that needs to be made explicitly clear, as currently there is no mention of such in the licensing doc. Regards, Jeremy On Wed, May 29, 2013 at 12:22 PM, Rodrigo Kumpera kump...@gmail.comwrote: There are no install target as those assemblies are not consumed in a standard way, it's very useful to have them on either the GAC or a profile directory. What we do at Xamarin is to have them consumed as part of our product build, mostly due to historical reasons. If you're using Xamarin.Android beta and have a paid license[1], you can copy them over. Yes, it's brittle, I'm sorry for that. But it's something that should be fixed on the build system. Cheers, Rodrigo [1]Starter edition doesn't allow random assemblies be used for the BCL. On Wed, May 29, 2013 at 12:10 PM, Jeremy Bell bell.jer...@gmail.comwrote: Hmm, is there a separate install target that does install them? It's easy enough to copy the directory in a build script after make install, but that's a little brittle. Better that the build system handle that, I think. On Wed, May 29, 2013 at 11:58 AM, Rodrigo Kumpera kump...@gmail.comwrote: Yes, it's not copied because those assemblies are not very useful on the desktop. On Wed, May 29, 2013 at 11:40 AM, Jeremy Bell bell.jer...@gmail.comwrote: When I build the monodroid assemblies with the configure option --with-monodroid=yes, the profile is built correctly in the master branch, but when you make install, the monodroid profile assemblies are not copied to the install prefix directory with the other profiles. Is this expected behavior? Here is my config options: ./autogen.sh --with-glib=embedded --prefix=$INSTALL_PREFIX --with-monodroid=yes make make install ___ 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/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen
Yes, this fixes the build. Thanks. The cff0ecb816fdd10419550b549137f48b5a14ff88 checkin did break the build for me, though it looks like you've reverted it (haven't tested it since then). 655afb183bd8abac0b60307645c9b43ff37b3082 appears to build fine. Here is my build script, if you're interested: https://github.com/JeroMiya/androidmono/blob/mono3update/get-mono.sh Thanks! Jeremy On Wed, May 29, 2013 at 11:15 PM, Zoltan Varga var...@gmail.com wrote: Hi, This should be fixed now by 655afb183bd8abac0b60307645c9b43ff37b3082. Could you try it out ? Zoltan On Wed, May 29, 2013 at 6:00 PM, Jeremy Bell bell.jer...@gmail.comwrote: I'm not sure if this is the best way to fix the issue, but I've submitted a pull request with a small fix: https://github.com/mono/mono/pull/650 This is my first mono pull request, so please let me know if there are any contrib guidelines I missed. Regards, Jeremy On Thu, May 23, 2013 at 2:25 PM, Jeremy Bell bell.jer...@gmail.comwrote: These: export SYSROOT=$NDK/platforms/android-14/arch-arm export PATH=$NDK_STANDALONE/bin:$PATH export CC=arm-linux-androideabi-gcc export CXX=arm-linux-androideabi-g++ export AR=arm-linux-androideabi-ar export AS=arm-linux-androideabi-as export CPP=arm-linux-androideabi-cpp export LD=arm-linux-androideabi-ld export RANLIB=arm-linux-androideabi-ranlib export STRIP=arm-linux-androideabi-strip ./autogen.sh --build=i686-pc-linux-gnu --host=arm-linux-androideabi --target=arm-linux-androideabi --enable-nls=no --with-mcs-docs=no --with-mcs-build=no CFLAGS=-DARM_FPU_NONE=1 CXXFLAGS=-DARM_FPU_NONE=1 --prefix=$PREFIX Same issue with the armv7-a build: export SYSROOT=$NDK/platforms/android-14/arch-arm export PATH=$NDK_STANDALONE/bin:$PATH export CC=arm-linux-androideabi-gcc export CXX=arm-linux-androideabi-g++ export AR=arm-linux-androideabi-ar export AS=arm-linux-androideabi-as export CPP=arm-linux-androideabi-cpp export LD=arm-linux-androideabi-ld export RANLIB=arm-linux-androideabi-ranlib export STRIP=arm-linux-androideabi-strip ./autogen.sh --build=i686-pc-linux-gnu --host=armv7-a-linux-androideabi --target=armv7-a-linux-androideabi --enable-nls=no --with-mcs-docs=no --with-mcs-build=no CFLAGS=-DARM_FPU_VFP=1 CXXFLAGS=-DARM_FPU_VFP --prefix=$INSTALL_PREFIX My system: Ubuntu 13.04 Thanks, Jeremy On Thu, May 23, 2013 at 1:39 PM, Zoltan Varga var...@gmail.com wrote: Hi, buildver.h is always built unless some configure flag disables it. What configure arguments are you using ? Zoltan On Thu, May 23, 2013 at 5:01 PM, Jeremy Bell bell.jer...@gmail.comwrote: At some point between branch mono-2-10-9 and branch master, a change was made to /mono/mini/main.c: branch mono-2-10-9: main.c: #include config.h #include mini.h #ifndef HOST_WIN32 #include buildver.h #endif branch master: #include config.h #include mini.h #ifndef HOST_WIN32 #ifdef HAVE_SGEN_GC #include buildver-sgen.h #else #include buildver.h #endif #endif This makes main.c impossible to compile when buildver-sgen.h is generated and not buildver.h. First of all, HAVE_SGEN_GC is never defined for files in /mini as far as I can tell, so main.c always attempts to include buildver.h, which does not exist when buildver-sgen.h is generated instead. However, even if you explicitly define HAVE_SGEN_GC in CFLAGS, etc... then you will still get an error, in mini.h, because it believes it is an error to have either HAVE_SGEN_GC or HAVE_BOEHM_GC defined when mini.h is included, as /mini code should not have dependencies on the GC being used, so it says: mini.h: /* * The mini code should not have any compile time dependencies on the GC being used, so the same object file from mini/ * can be linked into both mono and mono-sgen. */ #if defined(HAVE_BOEHM_GC) || defined(HAVE_SGEN_GC) #error The code in mini/ should not depend on these defines. #endif So, either way, main.c won't compile without modification. Is the error in /mono/mini/mini.h no longer valid? Or was the change to /mono/mini/main.c to depend on the HAVE_SGEN_GC define a regression? Thanks, Jeremy ___ 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] make install doesn't copy monodroid profile assemblies to the prefix directory
When I build the monodroid assemblies with the configure option --with-monodroid=yes, the profile is built correctly in the master branch, but when you make install, the monodroid profile assemblies are not copied to the install prefix directory with the other profiles. Is this expected behavior? Here is my config options: ./autogen.sh --with-glib=embedded --prefix=$INSTALL_PREFIX --with-monodroid=yes make make install ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen
I'm not sure if this is the best way to fix the issue, but I've submitted a pull request with a small fix: https://github.com/mono/mono/pull/650 This is my first mono pull request, so please let me know if there are any contrib guidelines I missed. Regards, Jeremy On Thu, May 23, 2013 at 2:25 PM, Jeremy Bell bell.jer...@gmail.com wrote: These: export SYSROOT=$NDK/platforms/android-14/arch-arm export PATH=$NDK_STANDALONE/bin:$PATH export CC=arm-linux-androideabi-gcc export CXX=arm-linux-androideabi-g++ export AR=arm-linux-androideabi-ar export AS=arm-linux-androideabi-as export CPP=arm-linux-androideabi-cpp export LD=arm-linux-androideabi-ld export RANLIB=arm-linux-androideabi-ranlib export STRIP=arm-linux-androideabi-strip ./autogen.sh --build=i686-pc-linux-gnu --host=arm-linux-androideabi --target=arm-linux-androideabi --enable-nls=no --with-mcs-docs=no --with-mcs-build=no CFLAGS=-DARM_FPU_NONE=1 CXXFLAGS=-DARM_FPU_NONE=1 --prefix=$PREFIX Same issue with the armv7-a build: export SYSROOT=$NDK/platforms/android-14/arch-arm export PATH=$NDK_STANDALONE/bin:$PATH export CC=arm-linux-androideabi-gcc export CXX=arm-linux-androideabi-g++ export AR=arm-linux-androideabi-ar export AS=arm-linux-androideabi-as export CPP=arm-linux-androideabi-cpp export LD=arm-linux-androideabi-ld export RANLIB=arm-linux-androideabi-ranlib export STRIP=arm-linux-androideabi-strip ./autogen.sh --build=i686-pc-linux-gnu --host=armv7-a-linux-androideabi --target=armv7-a-linux-androideabi --enable-nls=no --with-mcs-docs=no --with-mcs-build=no CFLAGS=-DARM_FPU_VFP=1 CXXFLAGS=-DARM_FPU_VFP --prefix=$INSTALL_PREFIX My system: Ubuntu 13.04 Thanks, Jeremy On Thu, May 23, 2013 at 1:39 PM, Zoltan Varga var...@gmail.com wrote: Hi, buildver.h is always built unless some configure flag disables it. What configure arguments are you using ? Zoltan On Thu, May 23, 2013 at 5:01 PM, Jeremy Bell bell.jer...@gmail.comwrote: At some point between branch mono-2-10-9 and branch master, a change was made to /mono/mini/main.c: branch mono-2-10-9: main.c: #include config.h #include mini.h #ifndef HOST_WIN32 #include buildver.h #endif branch master: #include config.h #include mini.h #ifndef HOST_WIN32 #ifdef HAVE_SGEN_GC #include buildver-sgen.h #else #include buildver.h #endif #endif This makes main.c impossible to compile when buildver-sgen.h is generated and not buildver.h. First of all, HAVE_SGEN_GC is never defined for files in /mini as far as I can tell, so main.c always attempts to include buildver.h, which does not exist when buildver-sgen.h is generated instead. However, even if you explicitly define HAVE_SGEN_GC in CFLAGS, etc... then you will still get an error, in mini.h, because it believes it is an error to have either HAVE_SGEN_GC or HAVE_BOEHM_GC defined when mini.h is included, as /mini code should not have dependencies on the GC being used, so it says: mini.h: /* * The mini code should not have any compile time dependencies on the GC being used, so the same object file from mini/ * can be linked into both mono and mono-sgen. */ #if defined(HAVE_BOEHM_GC) || defined(HAVE_SGEN_GC) #error The code in mini/ should not depend on these defines. #endif So, either way, main.c won't compile without modification. Is the error in /mono/mini/mini.h no longer valid? Or was the change to /mono/mini/main.c to depend on the HAVE_SGEN_GC define a regression? Thanks, Jeremy ___ 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] make install doesn't copy monodroid profile assemblies to the prefix directory
Hmm, is there a separate install target that does install them? It's easy enough to copy the directory in a build script after make install, but that's a little brittle. Better that the build system handle that, I think. On Wed, May 29, 2013 at 11:58 AM, Rodrigo Kumpera kump...@gmail.com wrote: Yes, it's not copied because those assemblies are not very useful on the desktop. On Wed, May 29, 2013 at 11:40 AM, Jeremy Bell bell.jer...@gmail.comwrote: When I build the monodroid assemblies with the configure option --with-monodroid=yes, the profile is built correctly in the master branch, but when you make install, the monodroid profile assemblies are not copied to the install prefix directory with the other profiles. Is this expected behavior? Here is my config options: ./autogen.sh --with-glib=embedded --prefix=$INSTALL_PREFIX --with-monodroid=yes make make install ___ 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] make install doesn't copy monodroid profile assemblies to the prefix directory
Thanks Rodrigo. Copying sounds like the way to go. As an aside, this is for an open source project and the intent is to use the core mono runtime under the terms of the LGPL as stated in the licensing documentation. If there is any code in the mono repository that isn't dual licensed (in other words, commercial only, with no option for LGPL use), that needs to be made explicitly clear, as currently there is no mention of such in the licensing doc. Regards, Jeremy On Wed, May 29, 2013 at 12:22 PM, Rodrigo Kumpera kump...@gmail.com wrote: There are no install target as those assemblies are not consumed in a standard way, it's very useful to have them on either the GAC or a profile directory. What we do at Xamarin is to have them consumed as part of our product build, mostly due to historical reasons. If you're using Xamarin.Android beta and have a paid license[1], you can copy them over. Yes, it's brittle, I'm sorry for that. But it's something that should be fixed on the build system. Cheers, Rodrigo [1]Starter edition doesn't allow random assemblies be used for the BCL. On Wed, May 29, 2013 at 12:10 PM, Jeremy Bell bell.jer...@gmail.comwrote: Hmm, is there a separate install target that does install them? It's easy enough to copy the directory in a build script after make install, but that's a little brittle. Better that the build system handle that, I think. On Wed, May 29, 2013 at 11:58 AM, Rodrigo Kumpera kump...@gmail.comwrote: Yes, it's not copied because those assemblies are not very useful on the desktop. On Wed, May 29, 2013 at 11:40 AM, Jeremy Bell bell.jer...@gmail.comwrote: When I build the monodroid assemblies with the configure option --with-monodroid=yes, the profile is built correctly in the master branch, but when you make install, the monodroid profile assemblies are not copied to the install prefix directory with the other profiles. Is this expected behavior? Here is my config options: ./autogen.sh --with-glib=embedded --prefix=$INSTALL_PREFIX --with-monodroid=yes make make install ___ 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] Top again
'I love this project, and want to see it succeed in more than just mobile.' I share these sentiments! :) At first glance, this seems like a big opportunity. There is likely to be a lot of ASP.NET/WebAPI/socket based enterprise server software currently running on IIS via MS-CLR where the company wants to get out of that expensive MSDN vendor lock-in to an open source solution, given several free/open source competitors (including some Apache/MIT licensed options). However, these companies seem to be more inclined to move to a JVM based solution, as there seems to be robust support for servers on that side of the fence, rather than simply porting their existing .net code to Mono. Unfortunately, I've heard it said that paid support plans for open source projects have not had a great history of producing significant revenue - at least not at the levels needed to put some full-time engineers to it. You'd have to have people on it full-time, and have priority consideration for bugs/pull requests/etc... to make it worth paying for, at the very least. It's unclear how well the economics of it would play out in practice. On Wed, May 29, 2013 at 1:03 PM, Rafael Teixeira mono...@gmail.com wrote: 'I love this project, and want to see it succeed in more than just mobile.' Very well said! Rafael Teixeira O..:.) On Wed, May 29, 2013 at 1:52 PM, Jeremiah Gowdy jeremiah.go...@freedomvoice.com wrote: Has Xamarin considered offering professional support plans for the other major consumer of Mono, those of us who want to use C# to develop our service applications but would prefer to host them on Linux for obvious reasons? As a representative of one of the aforementioned companies who is trying to run production services on Mono+Linux, I’m concerned that we’re building a model that’s dependent on a runtime supported by a company which is focused on mobile naturally because that’s where the revenue is. Unfortunately, we have no way to change that. If Xamarin were to offer support for enterprises, perhaps we could become a larger part of the overall revenue stream and our bugs would get better prioritization. I don’t think this would be bad for the project, since the classes our applications rely on are the core classes of .NET. Nothing fancy, just Sockets, Threads, collections, etc. The bugs we’ve experienced are: The Socket.Send and Socket.BeginSend in blocking mode returning without finishing the entire send, which we had to fix in our code by not using async and looping on blocking Send() until the entire send is actually complete. Work that by spec should be done by Send and BeginSend. It works, but it’s Mono-specific and/or Linux-specific hacks that aren’t needed on Windows+CLR. Mono’s BlockingCollectionT performance as a producer consumer queue for a pool of threads is really really bad. As the number of threads waiting on the collection goes up, the thrashing rapidly gets out of control. There is no such issue on Windows+CLR. I ended up copying Mono’s BlockingCollection.cs, copying it into my project as MonoBlockingCollection.cs and rewriting parts of it to make the performance reasonable. We finally changed the design of the service so we could remove the custom class, and it works fine that way, but our goal is to minimize or eliminate any Mono specific changes to our code because we aren’t yet convinced that the project considers service applications a first class consumer of the platform. We have to choose between running Boehm GC and hitting too many roots failures, or running sgen and getting crashes due to bugs. We are constantly testing running our application on different nodes in either mode in the hopes that one will prove more stability than the other. We have also had to modify our code significantly in ways that seem less likely to reproduce either crash. Now we are certainly a fault here too. The send bug is reported in bug 3844, but we don’t have a test case that reproduces it. It’s difficult to reproduce, because it happens under load, in a multithreaded socket server. But it seems like it would be very easy to add a check if we’re in blocking mode and if Send doesn’t honor the spec, loop until we’re done sending so that consumers get expected behavior. I should write that patch and submit it. I’m pretty sure I haven’t written a bug for the BlockingCollectionT performance issue, nor have I submitted my improved version. I’m capable of contributing to Mono, and I should do so since it’s relevant to my interests and business. That being said, giving companies with different business models a way to contribute to the bottom line and thus get more attention for their needs seems like it would help everyone. Considering what Mono saves us on administrative overhead and licensing costs, there’s no
[Mono-dev] /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen
At some point between branch mono-2-10-9 and branch master, a change was made to /mono/mini/main.c: branch mono-2-10-9: main.c: #include config.h #include mini.h #ifndef HOST_WIN32 #include buildver.h #endif branch master: #include config.h #include mini.h #ifndef HOST_WIN32 #ifdef HAVE_SGEN_GC #include buildver-sgen.h #else #include buildver.h #endif #endif This makes main.c impossible to compile when buildver-sgen.h is generated and not buildver.h. First of all, HAVE_SGEN_GC is never defined for files in /mini as far as I can tell, so main.c always attempts to include buildver.h, which does not exist when buildver-sgen.h is generated instead. However, even if you explicitly define HAVE_SGEN_GC in CFLAGS, etc... then you will still get an error, in mini.h, because it believes it is an error to have either HAVE_SGEN_GC or HAVE_BOEHM_GC defined when mini.h is included, as /mini code should not have dependencies on the GC being used, so it says: mini.h: /* * The mini code should not have any compile time dependencies on the GC being used, so the same object file from mini/ * can be linked into both mono and mono-sgen. */ #if defined(HAVE_BOEHM_GC) || defined(HAVE_SGEN_GC) #error The code in mini/ should not depend on these defines. #endif So, either way, main.c won't compile without modification. Is the error in /mono/mini/mini.h no longer valid? Or was the change to /mono/mini/main.c to depend on the HAVE_SGEN_GC define a regression? Thanks, Jeremy ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] /mono/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen
Thanks! I assumed I was moving to mono 3 by moving to the master branch on git (I'm building from git). Is this not correct? Or am I missing some configuration step? This issue is actually in the master branch (the mono-2-10-9 branch builds just fine), which I assume is where the latest development for mono 3.0 is being done. Thanks, Jeremy On Thu, May 23, 2013 at 11:29 AM, Rodrigo Kumpera kump...@gmail.com wrote: mini.c should not have this. All files in mini should no longer depends on either defines. But please move to mono 3.0 as 2.10 is not longer been actively maintained. On Thu, May 23, 2013 at 11:01 AM, Jeremy Bell bell.jer...@gmail.comwrote: At some point between branch mono-2-10-9 and branch master, a change was made to /mono/mini/main.c: branch mono-2-10-9: main.c: #include config.h #include mini.h #ifndef HOST_WIN32 #include buildver.h #endif branch master: #include config.h #include mini.h #ifndef HOST_WIN32 #ifdef HAVE_SGEN_GC #include buildver-sgen.h #else #include buildver.h #endif #endif This makes main.c impossible to compile when buildver-sgen.h is generated and not buildver.h. First of all, HAVE_SGEN_GC is never defined for files in /mini as far as I can tell, so main.c always attempts to include buildver.h, which does not exist when buildver-sgen.h is generated instead. However, even if you explicitly define HAVE_SGEN_GC in CFLAGS, etc... then you will still get an error, in mini.h, because it believes it is an error to have either HAVE_SGEN_GC or HAVE_BOEHM_GC defined when mini.h is included, as /mini code should not have dependencies on the GC being used, so it says: mini.h: /* * The mini code should not have any compile time dependencies on the GC being used, so the same object file from mini/ * can be linked into both mono and mono-sgen. */ #if defined(HAVE_BOEHM_GC) || defined(HAVE_SGEN_GC) #error The code in mini/ should not depend on these defines. #endif So, either way, main.c won't compile without modification. Is the error in /mono/mini/mini.h no longer valid? Or was the change to /mono/mini/main.c to depend on the HAVE_SGEN_GC define a regression? Thanks, Jeremy ___ 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/mini/main.c build error: depends on HAVE_SGEN_GC define, making it impossible to compile for sgen
These: export SYSROOT=$NDK/platforms/android-14/arch-arm export PATH=$NDK_STANDALONE/bin:$PATH export CC=arm-linux-androideabi-gcc export CXX=arm-linux-androideabi-g++ export AR=arm-linux-androideabi-ar export AS=arm-linux-androideabi-as export CPP=arm-linux-androideabi-cpp export LD=arm-linux-androideabi-ld export RANLIB=arm-linux-androideabi-ranlib export STRIP=arm-linux-androideabi-strip ./autogen.sh --build=i686-pc-linux-gnu --host=arm-linux-androideabi --target=arm-linux-androideabi --enable-nls=no --with-mcs-docs=no --with-mcs-build=no CFLAGS=-DARM_FPU_NONE=1 CXXFLAGS=-DARM_FPU_NONE=1 --prefix=$PREFIX Same issue with the armv7-a build: export SYSROOT=$NDK/platforms/android-14/arch-arm export PATH=$NDK_STANDALONE/bin:$PATH export CC=arm-linux-androideabi-gcc export CXX=arm-linux-androideabi-g++ export AR=arm-linux-androideabi-ar export AS=arm-linux-androideabi-as export CPP=arm-linux-androideabi-cpp export LD=arm-linux-androideabi-ld export RANLIB=arm-linux-androideabi-ranlib export STRIP=arm-linux-androideabi-strip ./autogen.sh --build=i686-pc-linux-gnu --host=armv7-a-linux-androideabi --target=armv7-a-linux-androideabi --enable-nls=no --with-mcs-docs=no --with-mcs-build=no CFLAGS=-DARM_FPU_VFP=1 CXXFLAGS=-DARM_FPU_VFP --prefix=$INSTALL_PREFIX My system: Ubuntu 13.04 Thanks, Jeremy On Thu, May 23, 2013 at 1:39 PM, Zoltan Varga var...@gmail.com wrote: Hi, buildver.h is always built unless some configure flag disables it. What configure arguments are you using ? Zoltan On Thu, May 23, 2013 at 5:01 PM, Jeremy Bell bell.jer...@gmail.comwrote: At some point between branch mono-2-10-9 and branch master, a change was made to /mono/mini/main.c: branch mono-2-10-9: main.c: #include config.h #include mini.h #ifndef HOST_WIN32 #include buildver.h #endif branch master: #include config.h #include mini.h #ifndef HOST_WIN32 #ifdef HAVE_SGEN_GC #include buildver-sgen.h #else #include buildver.h #endif #endif This makes main.c impossible to compile when buildver-sgen.h is generated and not buildver.h. First of all, HAVE_SGEN_GC is never defined for files in /mini as far as I can tell, so main.c always attempts to include buildver.h, which does not exist when buildver-sgen.h is generated instead. However, even if you explicitly define HAVE_SGEN_GC in CFLAGS, etc... then you will still get an error, in mini.h, because it believes it is an error to have either HAVE_SGEN_GC or HAVE_BOEHM_GC defined when mini.h is included, as /mini code should not have dependencies on the GC being used, so it says: mini.h: /* * The mini code should not have any compile time dependencies on the GC being used, so the same object file from mini/ * can be linked into both mono and mono-sgen. */ #if defined(HAVE_BOEHM_GC) || defined(HAVE_SGEN_GC) #error The code in mini/ should not depend on these defines. #endif So, either way, main.c won't compile without modification. Is the error in /mono/mini/mini.h no longer valid? Or was the change to /mono/mini/main.c to depend on the HAVE_SGEN_GC define a regression? Thanks, Jeremy ___ 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] Building mono with android ndk standalone toolchain (android ndk r8e)
config output: same as first attempt above build error: Making all in mini make[3]: Entering directory `/home/jeremybell/Desktop/monodevsrc/mono/mono/mini' if test -d ../../.git; then \ (cd ../..; \ LANG=C; export LANG; \ branch=`git branch | grep '^\*' | cut -d ' ' -f 2`; \ version=`git log --no-color --first-parent -n1 --pretty=format:%h`; \ echo #define FULL_VERSION \$branch/$version\; \ ); \ else \ echo #define FULL_VERSION \tarball\; \ fi version.h CC genmdesc-genmdesc.o In file included from genmdesc.c:9:0: mini.h:52:2: error: #error The code in mini/ should not depend on these defines. make[3]: *** [genmdesc-genmdesc.o] Error 1 Regards, Jeremy On Fri, May 10, 2013 at 10:25 AM, Jonathan Pryor jonpr...@vt.edu wrote: On May 8, 2013, at 4:29 PM, Jeremy Bell bell.jer...@gmail.com wrote: So, it looks like HAVE_SGEN_GC is not defined, but should be? Have I missed a step somewhere? Yes, it should be. From the commit message you mention: The Android NDK/bionic is interesting, in that it's lacking header files and macros normally present on Linux which otherwise break the build (e.g. no link.h which breaks Boehm support). breaks Boehm support means only sgen works. You need to disable Boehm, and enable sgen. - Jon -- Jeremy Bell Sleepy Daddy Software™ - Have a little one? Try Giggle Pad© for Windows Phone 7, a fun and educational game for children 9 months and older: http://social.zune.net/redirect?type=phoneAppid=5858669e-88d5-df11-a844-00237de2db9e Does your brand new Windows Phone 7 have dead pixels or screen discoloration? Find out with Pixel Checkup© for Windows Phone 7: http://social.zune.net/redirect?type=phoneAppid=1f5d0cf5-a2d8-df11-a844-00237de2db9e Giggle Pad and Pixel Checkup are copyright © 2010 Jeremy Bell and Sleepy Daddy Software™ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building mono with android ndk standalone toolchain (android ndk r8e)
I'm attempting to build mono using the ndk standalone toolchain from the android ndk (version r8e), but I am unable to complete the build. I setup my standalone environment like so: export SYSROOT=/home/jeremybell/Desktop/android-ndk-r8e/platforms/android-14/arch-arm /home/jeremybell/Desktop/android-ndk-r8e/build/tools/make-standalone-toolchain.sh --platform=android-14 --install-dir=./android-14-toolchain Next, I configure mono. I'm using something similar to the example shown here: http://permalink.gmane.org/gmane.comp.gnome.mono.patches/181374 Except for a few differences. First, I export each of the variables (AR, AS, CC, etc..) including SYSROOT (the configure script no longer takes a --sysroot=/path/to/sysroot option) prior to running configure. Second, I added --with-sgen=yes --disable-boehm Here's my environment and my autogen.sh command: export NDK=/home/jeremybell/Desktop/android-ndk-r8e export SYSROOT=$NDK/platforms/android-14/arch-arm export NDK_STANDALONE=/home/jeremybell/Desktop/monodevsrc/ndk_standalone export PATH=$NDK_STANDALONE/bin:$PATH export CC=arm-linux-androideabi-gcc export CXX=arm-linux-androideabi-g++ export AR=arm-linux-androideabi-ar export AS=arm-linux-androideabi-as export CPP=arm-linux-androideabi-cpp export LD=arm-linux-androideabi-ld export RANLIB=arm-linux-androideabi-ranlib export STRIP=arm-linux-androideabi-strip ./autogen.sh --build=`./config.guess` --host=armv5-linux-androideabi --target=armv5-linux-androideabi --enable-nls=no --with-mcs-docs=no --enable-mcs-build=no --with-glib=embedded --with-monodroid=yes CFLAGS=-DARM_FPU_NONE=1 CXXFLAGS=-DARM_FPU_NONE=1 Configure appears to run fine, but make fails while building mono_sgen-main.o: CC libmini_static_la-tramp-arm.lo CC libmini_static_la-mini-posix.lo CXXLD libmini-static.la CC mono_sgen-main.o main.c:7:22: fatal error: buildver.h: No such file or directory compilation terminated. make[4]: *** [mono_sgen-main.o] Error 1 make[4]: Leaving directory `/home/jeremybell/Desktop/monodevsrc/mono/mono/mini' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/jeremybell/Desktop/monodevsrc/mono/mono/mini' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jeremybell/Desktop/monodevsrc/mono/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jeremybell/Desktop/monodevsrc/mono' make: *** [all] Error 2 The offending line: #include config.h #include mini.h #ifndef HOST_WIN32 #ifdef HAVE_SGEN_GC #include buildver-sgen.h #else #include buildver.h #endif #endif So, it looks like HAVE_SGEN_GC is not defined, but should be? Have I missed a step somewhere? Thanks! Jeremy ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] IL-based regex engine
How about Mono.Simd support for arm NEON? On Sun, Sep 12, 2010 at 4:07 AM, Eddy Zavaleta e...@mictlanix.org wrote: Hi, Thanks for the reply, I realized that the engine already existed when I browsed the mono's source code tree after sending this email. I have two big areas of interest OS stuff and graphical tools. I would like to work on some graphics related project, maybe help to support XAML in desktop development, moonlight desklets, there is no much information about this. Or build a new mono application, some crazy ideas are a structured graphics app like a mind maping tool or a basic prototyping tool like sketchflow. On Sat, Sep 11, 2010 at 11:35 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: On Tue, Aug 24, 2010 at 1:54 AM, Eddy Zavaleta e...@mictlanix.org wrote: Hi, My name is Eddy Zavaleta I'm currently a senior in college at Instituto Politécnico Nacional in Mexico. I need to make a final project to gradute and I'm looking for something to work on. I have been an floss enthusiast for many years especially for GNOME/Mono projects so I would like to make some contribution to Mono. I just check the ToDo list in the mono-project site and I'm interested in the regular expression engine. Anyone can give me additional information about this task, some recomendations about what path I should take. I would appreciate any help with this. Hi, Unfortunately the ToDo list is out of date - the IL Regex engine exists now, though it has bugs. What kinds of things are you interested in working on? -- 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoDroid?
Miguel recently said on twitter that they are releasing the first 1024 MonoDroid invites, so I assume they have already done so? I wasn't on the list heh, so I'll have to wait. On Wed, Aug 18, 2010 at 10:05 AM, Kris Ray k...@landmarkdigital.com wrote: Any updates on the first MonoDroid release? My Droid X is in dire need... :) thanks, Kris ___ 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] MonoDroid?
And it looks like they have. Except there are only 257 testers right now. On Wed, Aug 18, 2010 at 2:14 PM, Jeremy Bell bell.jer...@gmail.com wrote: Miguel recently said on twitter that they are releasing the first 1024 MonoDroid invites, so I assume they have already done so? I wasn't on the list heh, so I'll have to wait. On Wed, Aug 18, 2010 at 10:05 AM, Kris Ray k...@landmarkdigital.comwrote: Any updates on the first MonoDroid release? My Droid X is in dire need... :) thanks, Kris ___ 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] Mono and Android: Licensing questions
As the official MonoDroid SDK is getting closer to release (relatively speaking), I have a few questions regarding licensing. What part of the Mono project is covered only under the commercial license and what is covered under the general license, with respect to using Mono for commercial android applications? In other words, would I be required to purchase a MonoDroid license under the following scenarios? My current understanding is that I would not need to do so for the first two scenarios, but I would probably need to purchase a license for the fourth scenario. I'm not sure about the third scenario however. 1. I build mono from source myself, use only the runtime, and write all of my own bindings to the android SDK. 2. I build mono from source using Koush's patches and tools (he uses jni4net to facilitate the android/mono bindings, and he wrote his own MonoDevelop add-in). 3. I build mono from source myself, and the application is written using Moonlight (assuming android support is added to moonlight). Any other Android SDK bindings I would write myself or use Koush's bindings. 4. I use the official MonoDroid SDK, distribute the application for free, but the app has advertisements for which I receive income. Are my assumptions regarding scenarios 1, 2, and 4 correct, and what about the third scenario? Also, another question I have is will there be any sort of staggered licensing? I'd like to write android apps as a hobby in my spare time - I don't expect the apps to draw enough income to buy more than a pizza now and then. Will there be a less expensive hobbyist commercial license in the $50-$100 range? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Incremental monodroid releases?
Will there be incremental monodroid releases before the final product is released? Also, how will monodroid applications be deployed? Will they bundle mono in the app itself or will it be a shared Mono application/activity that launches CLI apps in response to an intent or broadcast? ___ 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 Android: state of the union?
Koush responded to my tweet saying that he stopped working on it when Novell announced their own plans for Droid bindings. I don't think he ever committed the binding generator code to his git repository. It's a pity, because as a hobbyist mobile developer I certainly couldn't afford the licensing fee for a commercial monodroid license, but given even basic bindings without the kind of Visual Studio/MonoDevelop tooling support one would expect in the official MonoDroid, I could certainly make due. It would be easy to allow the user to replace the runtime on their phone - just distribute the code for the bindings and the eclipse project to build the android package that installs it. I believe that would satisfy the requirements of the LGPL. Or am I missing something? On Thu, Apr 8, 2010 at 1:15 PM, Joe Dluzen jdlu...@gmail.com wrote: I would think that you could develop your own bindings, as there are at least 3 other implementations that I know of. However, like most of us, IANAL. The MonoDroid and the efforts by Koushik Dutta[1] may be one and the same, but I don't know right now. On Novell's side, there is quite literally no information other than we're working on it and here's the name. I'm eagerly watching Koush's RSS for anything Android + Mono related. It appears that the last part of the puzzle which is still missing, is a tool to generate the C# bindings from the Java API. As for the LGPL, the mono runtime binaries installed on the phone should easily be user replaceable. And if it's an open source app, then there's no problem at all. If anyone has any more info, please reply. I'd imagine that many people are waiting for any information at all. Joe [1] http://www.koushikdutta.com/2010/01/androiddll.html Message: 2 Date: Thu, 8 Apr 2010 05:20:16 -0800 (PST) From: JeroMiya bell.jer...@gmail.com Subject: Re: [Mono-dev] Mono on Android: state of the union? To: mono-devel-list@lists.ximian.com Message-ID: 1270732816608-1774004.p...@n4.nabble.com Content-Type: text/plain; charset=us-ascii Would I be allowed to develop my own java bindings (obviously they wouldn't be as high-quality as Novell's commercial product) for mono on android and deploy mono-based applications without licensing Novell's commercial product? Would I subsequently be able to release said bindings under an appropriate open source license? It seems natural to assume so, but you need to be a lawyer to understand software licensing these days. ___ 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 Android: state of the union?
There might be a possibility that the core runtime will be free, but not the bindings that would let you use the native Android APIs that would allow you to do anything outside of a hello world console program: Quote from Miquel de Icaza: It seems like you can use Mono on the Android today, but there is no binding to their Java-based APIs. At Novell we are going to offer a commercial product to target the Android with the native APIs, but do not have yet a timeline ready. On Thu, Apr 8, 2010 at 3:07 PM, Stifu st...@free.fr wrote: Is it a given that MonoDroid won't be free? I know MonoTouch isn't, but Mono for MeeGo is free, for example... JeroMiya wrote: Koush responded to my tweet saying that he stopped working on it when Novell announced their own plans for Droid bindings. I don't think he ever committed the binding generator code to his git repository. It's a pity, because as a hobbyist mobile developer I certainly couldn't afford the licensing fee for a commercial monodroid license, but given even basic bindings without the kind of Visual Studio/MonoDevelop tooling support one would expect in the official MonoDroid, I could certainly make due. It would be easy to allow the user to replace the runtime on their phone - just distribute the code for the bindings and the eclipse project to build the android package that installs it. I believe that would satisfy the requirements of the LGPL. Or am I missing something? On Thu, Apr 8, 2010 at 1:15 PM, Joe Dluzen jdlu...@gmail.com wrote: I would think that you could develop your own bindings, as there are at least 3 other implementations that I know of. However, like most of us, IANAL. The MonoDroid and the efforts by Koushik Dutta[1] may be one and the same, but I don't know right now. On Novell's side, there is quite literally no information other than we're working on it and here's the name. I'm eagerly watching Koush's RSS for anything Android + Mono related. It appears that the last part of the puzzle which is still missing, is a tool to generate the C# bindings from the Java API. As for the LGPL, the mono runtime binaries installed on the phone should easily be user replaceable. And if it's an open source app, then there's no problem at all. If anyone has any more info, please reply. I'd imagine that many people are waiting for any information at all. Joe [1] http://www.koushikdutta.com/2010/01/androiddll.html Message: 2 Date: Thu, 8 Apr 2010 05:20:16 -0800 (PST) From: JeroMiya bell.jer...@gmail.com Subject: Re: [Mono-dev] Mono on Android: state of the union? To: mono-devel-list@lists.ximian.com Message-ID: 1270732816608-1774004.p...@n4.nabble.com Content-Type: text/plain; charset=us-ascii Would I be allowed to develop my own java bindings (obviously they wouldn't be as high-quality as Novell's commercial product) for mono on android and deploy mono-based applications without licensing Novell's commercial product? Would I subsequently be able to release said bindings under an appropriate open source license? It seems natural to assume so, but you need to be a lawyer to understand software licensing these days. ___ 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 -- View this message in context: http://n4.nabble.com/Mono-on-Android-state-of-the-union-tp1528216p1782206.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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
