Re: [Mono-dev] fastcgi-mono-server4 does not answer nor log anything and timeout
On 07/05/14 21:36, sven falempin wrote: i guess some of the patches should be included ins the source tree These seem to be great contributions! But please follow the official workflow for proposing patches: create a pull request in github for each separate issue, explaining in each git commit message not only what you're doing, but why you're doing it (the problem you got before you did the change). Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Repeat builds of core assemblies
On 23/04/14 04:14, Miguel de Icaza wrote: How about if we simplify this, by using the following strategy: - Move the interdependent types of those assemblies to corlib. - Mark them as internal. - Add InternalsVisibleTo for those assemblies towards mscorlib. - Use type forwarders to bring those types back from mscorlib to the correct places. This way the build would be much simpler, without dependency cycles. The dependency cycles are embedded in the public API contracts. So the libraries must be built with those cycles to match Microsoft's public API. I didn't propose to build binaries without dependency cycles, I just proposed to push the implementation towards a unique assembly (which BTW could be System.dll, no need to push it to mscorlib I guess). The build cycles merely encode the steps that must be taken to bring up those cycles on binaries. I'm guessing that what you mean is that by using the type forwarders to bring the types to the same assembly as they appear in MS, the metadata would be different and therefore the ABI/API would not be the same? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Repeat builds of core assemblies
Hey Miguel, On 22/04/14 21:53, Miguel de Icaza wrote: Hey guys, The problem is that System, System.XML and System.Configuration are each defined in terms of the other assemblies. So we gradually bring up each one of those assemblies up by first compiling a stub System, which we use to build System.XML and System.Configuration. Then we rebuild System, this time referencing System.XML and System.Configuration so we can take a dependency on them, and so on. How about if we simplify this, by using the following strategy: - Move the interdependent types of those assemblies to corlib. - Mark them as internal. - Add InternalsVisibleTo for those assemblies towards mscorlib. - Use type forwarders to bring those types back from mscorlib to the correct places. This way the build would be much simpler, without dependency cycles. HTH, Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono build bug
On 01/04/14 17:22, Kuba Vaněk wrote: Hello everybody, I cloned mono 897e95954ec2b1bb7bc76572dff6071b3ae4c64b from git. When I try to build Mono, it prints this (yes, I also tried to delete original folder and then reclone): $ ./autogen.sh --prefix=/usr Running libtoolize... libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Running aclocal -I m4 -I . ... aclocal: error: configure.ac is required **Error**: aclocal failed. This may mean that you have not installed all of the packages you need, or you may need to set ACLOCAL_FLAGS to include -I $prefix/share/aclocal for the prefix where you installed the packages whose macros were not found I think it's because mono is using configure.in instead configure.ac (the former may be finally deprecated). Try to rename the file and see if it works. If it doesn't, you will need the help of some autohell^H^H^H^Htools expert. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono build bug
Great, can you submit a pull request to fix the bug upstream? Please specify the versions of your tools in the commit message, to better document about the failure (i.e. version of your distro, version of aclocal, version of autoconf, version of automake...). Cheers! On 1 April 2014 18:10, Kuba Vaněk vanek.jak...@seznam.cz wrote: Hello, thank you very much. That worked, but I also had to rename libgc/ configure.in to libgc/configure.ac Jakub Vanek -- Original message -- From: Andrés G. Aragoneses kno...@gmail.com For: mono-devel-list@lists.ximian.com Date: 1. 4. 2014 17:59:19 Subject: Re: [Mono-dev] Mono build bug On 01/04/14 17:22, Kuba Vaněk wrote: Hello everybody, I cloned mono 897e95954ec2b1bb7bc76572dff6071b3ae4c64b from git. When I try to build Mono, it prints this (yes, I also tried to delete original folder and then reclone): $ ./autogen.sh --prefix=/usr Running libtoolize... libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Running aclocal -I m4 -I . ... aclocal: error: configure.ac is required **Error**: aclocal failed. This may mean that you have not installed all of the packages you need, or you may need to set ACLOCAL_FLAGS to include -I $prefix/share/aclocal for the prefix where you installed the packages whose macros were not found I think it's because mono is using configure.in instead configure.ac (the former may be finally deprecated). Try to rename the file and see if it works. If it doesn't, you will need the help of some autohell^H^H^H^Htools expert. ___ 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] (no subject)
On 20/03/14 18:08, Greg Young wrote: Before go searching for what happening and whether its something odd here can anyone build trunk right now? I can build 3.2.8 no problem Attaching the error message you get might help. (Also putting a subject in your email is not yet old-fashioned AFAIK) PS: I guess you mean 'master' (subversion is no more ;) ) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Library path bug in Makefile?
On 06/03/14 03:09, Edward Ned Harvey (mono) wrote: But I have to say, learning to roll your own packages is difficult. It is not if you use fpm (https://github.com/jordansissel/fpm), instead of a distro-specific build toolchain, as I recommended in a previous message (i.e. simple script to create a mono package: https://github.com/knocte/7digital-mono/blob/master/build-mono-package.bash). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Library path bug in Makefile?
On 04/03/14 17:23, Edward Ned Harvey (mono) wrote: From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Andrés G. Aragoneses As far as I understand, LD_LIBRARY_PATH is a system setting that mono doesn't modify. Thanks for your response - from the link I originally posted (http://www.cc.dtu.dk/?page_id=304) please see this quote: There is the ldd command, that shows you which libraries are needed by a dynamically linked executable, e.g. $ ldd /usr/bin/file linux-vdso.so.1 = (0x7fff9646c000) libmagic.so.1 = /usr/lib64/libmagic.so.1 (0x0030f9a0) libz.so.1 = /lib64/libz.so.1 (0x0030f8e0) libc.so.6 = /lib64/libc.so.6 (0x0030f820) /lib64/ld-linux-x86-64.so.2 (0x0030f7a0) snip If you compile your application(s) yourself, you can solve the problem by specifying the correct location of the shared libraries and tell the linker to add those to the runpath of your executable, specifying the path in the '-rpath' linker option: cc -o myprog obj1.o ... objn.o -Wl,-rpath=/path/to/lib \ -L/path/to/lib -lmylib The linker also reads the LD_RUN_PATH environment variable, The main point here is to say, the library search path is hard-coded into the binary at the time of compile/linking. In fact, you're correct. LD_LIBRARY_PATH is an environment variable, and in fact, mono doesn't modify it. (Rightly so.) Normally, LD_LIBRARY_PATH is actually empty. Completely blank. And rightly so. Because normally it should not be needed, if the binaries are linked properly. Right, LD_LIBRARY_PATH may be simply a fallback. But the thing is, you don't need LD_LIBRARY_PATH when installing libs in standard prefixes like /usr or /usr/local, so as you mention that LD_LIBRARY_PATH is empty, maybe what happens is that PATH is checked before LD_LIBRARY_PATH? (In that case, LD_LIBRARY_PATH is the fallback of the fallback.) In the case of building mono from source, it seems clear, this should come from --libdir=DIR, which is derived from --exec-prefix=EPREFIX, which is derived from --prefix=PREFIX The goal I'm driving toward is to provide a modern version of mono on systems (for example centos) which don't have anything remotely usable available in their standard package repositories. (In the default centos/rhel repositories, there is *no* mono available, but if you add epel, then suddenly mono 2.4.3 becomes available, which is pathetic.) It's very easy to build from source, but without a package manager, you DON'T want to install into default locations, as that makes it very difficult and messy to upgrade to later versions of mono as they're released, with security and bugfixes. The methodology I've described in the original post about building to /usr/local/mono-VERSION and then providing a symlink /usr/local/mono -- mono-VERSION is very easily supportable and sustainable. But even if you symlink /usr/local/mono to /usr/local/mono-3.2.8, that is *not* /usr/local. I mean, its lib folder would be in /usr/local/mono/lib instead of /usr/local/lib, which means that if /usr/local is considered standard for your distro (included in PATH?), that would not apply in this case. If mono is simply the only software you install from sources, you can simply install it in /usr/local, and when you need to uninstall it, you simply wipe /usr/local. If you're worried about mixing different mono versions around the same prefix, then what you could do is dummy packages using fpm (an example of how to create a .deb package is here: https://github.com/knocte/7digital-mono, but you can create an rpm as easily as that, changing a flag). Then uninstalling becomes easy. You can build and install the new 3.2.9 when it's available, test it yourself, and then cutover the symlink when it's ready for general usage by the users of the machine. http://www.mono-project.com/Parallel_Mono_Environments Thank you for the link. In fact, I read it. Fundamentally, they're suggesting you override the LD_LIBRARY_PATH (and some other environment variables.) It also seems, they are in agreement with all the other info about LD_LIBRARY_PATH conventions out there on the internet, they are *not* suggesting that you do this in production. They are operating under the assumption that you are building multiple versions of mono for development and testing purposes. They assume you have some other mono in system default locations, and you don't want the system default mono to interfere with your experimental build (or vice-versa). Yes I know that guide is not meant to help you with your production environment, but by reading it you understand that using non-standard prefixes (like /opt/mono or /usr/local/mono-3.2.9) only really works if you use them along with an isolated environment (a script you 'source' into, etc
Re: [Mono-dev] Library path bug in Makefile?
As far as I understand, LD_LIBRARY_PATH is a system setting that mono doesn't modify. If you want Mono to work out of the box without the need to adjust LD_LIBRARY_PATH you need to install it in a standard prefix. Some distributions consider /usr and /usr/local to be standard (note: /usr/local/mono-3.2.8 != /usr/local), but I've also seen/heard issues about people installing in /usr/local, so the safest bet is /usr (although choosing /usr has the disadvantage that it can clash with your system mono packages if you're not careful). This is also a good read in case you need to use two different versions of mono in the same system at the same time: http://www.mono-project.com/Parallel_Mono_Environments On 03/03/14 03:58, Edward Ned Harvey (mono) wrote: I had a problem, and I figured it out, thanks to this page: http://www.cc.dtu.dk/?page_id=304 I have a system with mono built as follows: ./configure --prefix=/usr/local/mono-3.2.8 make echo echo Done echo followed by sudo make install echo echo Ok Ok Ok echo I would expect, based on the above webpage, that the ./configure make should have built mono using LD_RUN_PATH set to /usr/local/mono-3.2.8/lib, but apparently it doesn't - Should that be considered a bug in the Makefile? The workaround is to specify the LD_LIBRARY_PATH on each call to mono env LD_LIBRARY_PATH=/usr/local/mono-3.2.8/lib /usr/local/mono-3.2.8/bin/mono FunWithFooBar.exe ___ 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] ms .net source updated and license modified
On 25/02/14 18:11, theUser BL wrote: »Um die Arbeit mit dem Quellcode noch einfacher zu machen, hat Microsoft auch die Lizenzbestimmungen klarer gefasst. Denn bisher mussten beispielsweise die Entwickler von Open Source-Klonen aufpassen, dass sie nur Erkenntnisse aus dem Reverse Engineering verwenden und nicht aus dem Studium des originalen Quellcodes. Denn in vielen Fällen würde dann die Gefahr drohen, dass man sich verschiedener Rechteverletzungen schuldig macht. Die Microsoft Reference Source License wurde daher nun so angepasst, dass beispielsweise die Entwickler des Mono-Teams problemlos die .Net-Sourcen anschauen und das Framework dann unter Linux klonen können. « GoogleTranslate output is: To make the work with the source code even easier, Microsoft has also the license terms clarified. Because so far had For example, the developers of open source clones careful that they only use insights from the reverse engineering and not from the study of the original source code. Because in many cases would then the danger threatening that one different in rights violations guilty. The Microsoft Reference Source License was therefore now adapted so that for example, the developer of the mono-teams easily see the. Net sources and the framework then in Linux can clone. If this translation is (kind of) correct, it still is very confusing because that license (MS-RSL [1]) is not opensource. [1] http://en.wikipedia.org/wiki/Shared_source#Microsoft_Reference_Source_License_.28Ms-RSL.29 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] which branch is recent SqlBulkCopy fix in?
On 20/02/14 06:14, doncl wrote: Hi, my apologies if this question is better sent to another list. It's my understanding Miguel recently merged in fixes to SqlBulkCopy. I could really use that for what I'm working on right now; SqlBulkCopy is not working for me in 3.2.6, Ubuntu 13.10. When I checkout Master and build, I get a different error; glad to give full details if desired. Give them. But rather in bugzilla.xamarin.com. It's my hope that I simply have the wrong git branch to get this fix. Any pointers would be greatly appreciated.' git master should be the branch that has the latest. If this post were better sent to the regular mono list, again, my apologies.also, glad to provide a very short program sample that demonstrates the issue, if anyone wants. Yes, that short program is very welcome, please include it in the bug that you file in bugzilla. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Failure to compile Mono 3.2.7-branch from source
AFAIU the fix for this was already in master, and Antonious sent a pull-request to backport the fix to this branch, which has just been committed by Alex: https://github.com/mono/mono/pull/893 On 18/02/14 06:10, jean-michel.perr...@csiro.au wrote: Hi, I am trying to test an app on Mono 3.2.7, but cannot seem to get it to build properly. I can check out the 3.2.3 branch, and build/install it bootstrapped with the prepackaged 3.0.6, but whether I use 3.2.3 or 3.0.6 as a bootstrap the build of 3.2.7 fails. If anyone has a hunch or advice. Cheers Repro information: Linux 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux (Debian Unstable, just updated all packages) Mono JIT compiler version 3.2.3 (mono-3.2.3-branch/4d8ba16 Tuesday 18 February 15:23:35 EST 2014) Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC:sgen git checkout mono-3.2.7-branch git pull ./autogen.sh --prefix=/usr/local make MCS [build] mscorlib.dll Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x001f7 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: /home/xyz/src/mono/mono/mini/mono() [0x4b6398] /home/xyz/src/mono/mono/mini/mono() [0x50d81b] /home/xyz/src/mono/mono/mini/mono() [0x423ae2] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf210) [0x2b284160e210] /lib/x86_64-linux-gnu/libpthread.so.0(pthread_join+0x24) [0x2b2841607f64] /home/xyz/src/mono/mono/mini/mono() [0x5a9e84] /home/xyz/src/mono/mono/mini/mono(mono_runtime_cleanup+0xe) [0x5a1d5e] /home/xyz/src/mono/mono/mini/mono() [0x41b6b6] /home/xyz/src/mono/mono/mini/mono() [0x53d4db] [0x41aed82d] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 3 questions about AOT and the JIT
Hi! Just 3 quick questions: a) This full-AOT limitation about using interfaces with generics (http://www.mono-project.com/AOT#Limitation:_Generic_Interface_Instantiation) is it only a problem when using value types, or any type? b) Why the above limitation is not listed here? http://docs.xamarin.com/guides/ios/advanced_topics/limitations/ c) Would it be possible to instruct the JIT to do a whole compilation of all the methods of all the types of all the assemblies currently loaded by the runtime, at startup? (To prevent them to be lazy loaded.) (I ask the last question because I'm not sure I will be able to achieve FullAOT for certain codebase due to its restrictions, and in this case I would want at least to have the full compilation at startup, which is worse than at compilation time, but better than slowing down the app for all first times that a certain feature is used.) Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TcpListener.AcceptTcpClient leaks a socket at each call
Sounds good, then can the SetTcpClient() method be removed?
(If it can't because other places in the code are using it, you would
need to:
- Either make them use the new ctor.
- Or fix SetTcpClient() to close the previous socket?
)
If it can be removed because there are no more things using it, I say
simply create a pull request with your change.
On 23/01/14 16:59, Jonathan Gagnon wrote:
Here is the proposed change. See attached files.
I'm not too familiar with sending diffs so let me know if I didn't send
it in the expected format.
*Jonathan Gagnon*
Architecte d'application / Application Architect
600, boulevard Armand-Frappier, bureau 200
Laval (Québec) H7V 4B4
Canada
T : 450-662-6101 poste 234
http://www.croesus.com
http://www.facebook.com/pages/Croesus-Finansoft/345020305606240http://www.linkedin.com/company/croesus-finansoft?trk=hb_tab_compy_id_26141https://twitter.com/CroesusFin
On Wed, Jan 22, 2014 at 5:15 PM, Andrés G. Aragoneses
kno...@gmail.com mailto:kno...@gmail.com wrote:
On 22/01/14 22:32, Jonathan Gagnon wrote:
I found a leak in TcpListener.AcceptTcpClient :
public TcpClient AcceptTcpClient ()
{
if (!active)
throw new InvalidOperationException (Socket is not listening);
Socket clientSocket = server.Accept ();
TcpClient client = new TcpClient(); // this call creates a socket
even
though we don't need it
// use internal method SetTcpClient to make a
// client with the specified socket
client.SetTcpClient (clientSocket); // This method leaks the socket
created by the default constructor.
return client;
}
The method calls the default TcpClient constructor which creates a new
socket. SetTcpClient is then called to assign the accepted socket to
the TcpClient object. The problem is that the SetTcpClient simply
replaces the old socket reference by the new without closing the old
socket. The result is that the socket created by the default
constructor remains until the GC reclaims it.
The fix would be really easy. Instead of calling the default
TcpClient
constructor, a new constructor could be created taking the socket as
parameter. We would then avoid creating and leaking a socket
every time
the method is called. The fixed method would look like this :
public TcpClient AcceptTcpClient ()
{
if (!active)
throw new InvalidOperationException (Socket is not listening);
Socket clientSocket = server.Accept ();
TcpClient client = new TcpClient(clientSocket);
return client;
}
I could create a fix with the proposed solution. Any thoughts?
Propose your solution as diff format please, it's much easier to
understand and review.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
mailto: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] TcpListener.AcceptTcpClient leaks a socket at each call
On 22/01/14 22:32, Jonathan Gagnon wrote:
I found a leak in TcpListener.AcceptTcpClient :
public TcpClient AcceptTcpClient ()
{
if (!active)
throw new InvalidOperationException (Socket is not listening);
Socket clientSocket = server.Accept ();
TcpClient client = new TcpClient(); // this call creates a socket even
though we don't need it
// use internal method SetTcpClient to make a
// client with the specified socket
client.SetTcpClient (clientSocket); // This method leaks the socket
created by the default constructor.
return client;
}
The method calls the default TcpClient constructor which creates a new
socket. SetTcpClient is then called to assign the accepted socket to
the TcpClient object. The problem is that the SetTcpClient simply
replaces the old socket reference by the new without closing the old
socket. The result is that the socket created by the default
constructor remains until the GC reclaims it.
The fix would be really easy. Instead of calling the default TcpClient
constructor, a new constructor could be created taking the socket as
parameter. We would then avoid creating and leaking a socket every time
the method is called. The fixed method would look like this :
public TcpClient AcceptTcpClient ()
{
if (!active)
throw new InvalidOperationException (Socket is not listening);
Socket clientSocket = server.Accept ();
TcpClient client = new TcpClient(clientSocket);
return client;
}
I could create a fix with the proposed solution. Any thoughts?
Propose your solution as diff format please, it's much easier to
understand and review.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Assert: condition `ret == 0' not met
Bassam, I bisected it and I think the culprit is in this commit: https://github.com/mono/mono/commit/a0afa38296b8a3b0382bf34ce777357d2553c0f0 Can you confirm my finding by trying to build the previous commit to this one? Thanks On 14/01/14 02:55, Andrés G. Aragoneses wrote: I confirm the problem, I also get it in Linux64bits On 14/01/14 00:33, Bassam Tabbara wrote: Yes. This is a clean build from mono/master. On Jan 13, 2014, at 3:07 PM, Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com wrote: Are you trying to build mono/master without any changes? That has not happen with our bots at xamarin. On Mon, Jan 13, 2014 at 4:47 PM, Bassam Tabbara bas...@symform.com mailto:bas...@symform.com wrote: Hello, I’m seeing the following exception while building MCS from the latest in master. This is on my mac (OSX 10.9). Any thoughts? System.Collections.Concurrent/BlockingCollection.cs(396,9): warning CS0219: The variable `index' is assigned but its value is never used System.Diagnostics/TraceImpl.cs(44,15): warning CS0649: Field `System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and will always have its default value `false' Compilation succeeded - 5 warning(s) * Assertion at gc.c:1216, condition `ret == 0' not met Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x002b3 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 mono0x000109261dfb mono_handle_native_sigsegv + 363 1 libsystem_platform.dylib0x7fff88bf05aa _sigtramp + 26 2 libsystem_c.dylib 0x7fff81b9ed8b __sprintf_chk + 153 3 libsystem_c.dylib 0x7fff81b7abba abort + 125 4 mono0x0001093eee11 monoeg_g_logv + 161 5 mono0x0001093eef4f monoeg_assertion_message + 143 6 mono0x000109365524 mono_gc_cleanup + 260 7 mono0x00010935bc1e mono_runtime_cleanup + 14 8 mono0x0001091d900c mini_cleanup + 956 9 mono0x0001092e6525 ves_icall_System_Environment_Exit + 37 10 ??? 0x0001119d2324 0x0 + 4590478116 11 mono0x0001091d88f5 mono_jit_runtime_invoke + 1653 12 mono0x00010936871b mono_runtime_invoke + 107 13 mono0x00010936e726 mono_runtime_exec_main + 374 14 mono0x0001092358d9 mono_main + 6121 15 mono0x0001091cc6ec main + 588 16 libdyld.dylib 0x7fff8d2195fd start + 1 17 ??? 0x001b 0x0 + 27 Debug info from gdb: Process 93570 stopped * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP thread #2: tid = 0x2507a0, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #3: tid = 0x2507a1, 0x7fff8da89662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager thread #4: tid = 0x2507a2, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10 frame #1: 0x000109261ed4 mono`mono_handle_native_sigsegv(signal=unavailable, ctx=unavailable) + 580 at mini-exceptions.c:2299 frame #2: 0x7fff88bf05aa libsystem_platform.dylib`_sigtramp + 26 frame #3: 0x7fff8da88867 libsystem_kernel.dylib`__pthread_kill + 11 frame #4: 0x7fff81b9ed8b libsystem_c.dylib`__sprintf_chk + 153 frame #5: 0x7fff81b7abba libsystem_c.dylib`abort + 125 frame #6: 0x0001093eee11 mono`monoeg_g_logv(log_domain=unavailable, log_level=unavailable, format=unavailable, args=unavailable) + 161 at goutput.c:175 frame #7: 0x0001093eef4f mono`monoeg_assertion_message(format=unavailable) + 143 at goutput.c:195
Re: [Mono-dev] Assert: condition `ret == 0' not met
I confirm the problem, I also get it in Linux64bits On 14/01/14 00:33, Bassam Tabbara wrote: Yes. This is a clean build from mono/master. On Jan 13, 2014, at 3:07 PM, Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com wrote: Are you trying to build mono/master without any changes? That has not happen with our bots at xamarin. On Mon, Jan 13, 2014 at 4:47 PM, Bassam Tabbara bas...@symform.com mailto:bas...@symform.com wrote: Hello, I’m seeing the following exception while building MCS from the latest in master. This is on my mac (OSX 10.9). Any thoughts? System.Collections.Concurrent/BlockingCollection.cs(396,9): warning CS0219: The variable `index' is assigned but its value is never used System.Diagnostics/TraceImpl.cs(44,15): warning CS0649: Field `System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and will always have its default value `false' Compilation succeeded - 5 warning(s) * Assertion at gc.c:1216, condition `ret == 0' not met Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x002b3 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 mono0x000109261dfb mono_handle_native_sigsegv + 363 1 libsystem_platform.dylib0x7fff88bf05aa _sigtramp + 26 2 libsystem_c.dylib 0x7fff81b9ed8b __sprintf_chk + 153 3 libsystem_c.dylib 0x7fff81b7abba abort + 125 4 mono0x0001093eee11 monoeg_g_logv + 161 5 mono0x0001093eef4f monoeg_assertion_message + 143 6 mono0x000109365524 mono_gc_cleanup + 260 7 mono0x00010935bc1e mono_runtime_cleanup + 14 8 mono0x0001091d900c mini_cleanup + 956 9 mono0x0001092e6525 ves_icall_System_Environment_Exit + 37 10 ??? 0x0001119d2324 0x0 + 4590478116 11 mono0x0001091d88f5 mono_jit_runtime_invoke + 1653 12 mono0x00010936871b mono_runtime_invoke + 107 13 mono0x00010936e726 mono_runtime_exec_main + 374 14 mono0x0001092358d9 mono_main + 6121 15 mono0x0001091cc6ec main + 588 16 libdyld.dylib 0x7fff8d2195fd start + 1 17 ??? 0x001b 0x0 + 27 Debug info from gdb: Process 93570 stopped * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP thread #2: tid = 0x2507a0, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #3: tid = 0x2507a1, 0x7fff8da89662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager thread #4: tid = 0x2507a2, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10 frame #1: 0x000109261ed4 mono`mono_handle_native_sigsegv(signal=unavailable, ctx=unavailable) + 580 at mini-exceptions.c:2299 frame #2: 0x7fff88bf05aa libsystem_platform.dylib`_sigtramp + 26 frame #3: 0x7fff8da88867 libsystem_kernel.dylib`__pthread_kill + 11 frame #4: 0x7fff81b9ed8b libsystem_c.dylib`__sprintf_chk + 153 frame #5: 0x7fff81b7abba libsystem_c.dylib`abort + 125 frame #6: 0x0001093eee11 mono`monoeg_g_logv(log_domain=unavailable, log_level=unavailable, format=unavailable, args=unavailable) + 161 at goutput.c:175 frame #7: 0x0001093eef4f mono`monoeg_assertion_message(format=unavailable) + 143 at goutput.c:195 frame #8: 0x000109365524 mono`mono_gc_cleanup + 260 at gc.c:1216 frame #9: 0x00010935bc1e mono`mono_runtime_cleanup(domain=unavailable) + 14 at appdomain.c:354 frame #10: 0x0001091d900c
Re: [Mono-dev] mono-2.11.4 on Solaris 11.1
On 11/01/14 22:00, Grüninger, Andreas (LGL Extern) wrote: Hi all I compiled mono-2.11.4 on Solaris 11.1 and after excluding some tests the other tests succeeded. Only 2 failures. I prepared an upstream branch with the patches at https://github.com/grueni/mono/commits/upstream-mono-2.11.4. Why such an old version and not master? Should I create pull requests? Yes. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] (no subject)
What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Aborted -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ 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] (no subject)
This 64bits-only bug could be the culprit: https://bugzilla.xamarin.com/show_bug.cgi?id=14834 It's fixed already in master branch. Try master. On 10/01/14 11:34, Andrés G. Aragoneses wrote: What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Aborted -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ 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] (no subject)
If it still crashes with master, run it with gdb and obtain a backtrace, and attach it to a bug report. On 10/01/14 11:43, James Nugent wrote: Thanks, I'll try this today. Cheers, James On 10 Jan 2014, at 10:42, Andrés G. Aragoneses kno...@gmail.com wrote: This 64bits-only bug could be the culprit: https://bugzilla.xamarin.com/show_bug.cgi?id=14834 It's fixed already in master branch. Try master. On 10/01/14 11:34, Andrés G. Aragoneses wrote: What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Aborted -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ 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] System.ExecutionEngineException: Failed to create shadow copy (CopyFile).
What version of mono are you running? On 23/12/13 12:57, Alistair Bush wrote: I have be working to get the fubu (mvc) framework and associated tools working on mono/linux. I have gotten most of the way to running a basic app but have sadly come stuck on the following and am running out of ideas. Basically I have setup a 'web' project using fubu new and am attempting to run it by calling fubu run. Sadly i'm getting the output [1] and as you will be able to see this is caused by a ExecutionEngineException when attempting to call Type.IsAssignableFrom. At this particular point in the code it is my understanding that the application is within a separate app domain ( see Bottles.Services.Remote.RemoteServicesProxy ). This is anything which should be stopping mono from inspecting Type information on a Type when within a separate app domain? Also it the moment im a little stuck on how to get more information to debug this issue. Any suggestions would be welcomed. Thanks. [1] $ fubu run --directory src/fubutest Alias is returning '/home/alistair/Projects/fubu/tests/fubutest' Alias is returning 'src/fubutest' Assembly bin path is bin The configuration file is /home/alistair/Projects/fubu/tests/fubutest/src/fubutest/Web.config Started service Fubu.Running.RemoteFubuMvcBootstrapper Trying to start application /home/alistair/Projects/fubu/tests/fubutest/src/fubutest with port number 5500 FubuMode = Development ERROR: System.ExecutionEngineException: Failed to create shadow copy (CopyFile). Server stack trace: at (wrapper managed-to-native) System.Type:type_is_assignable_from (System.Type,System.Type) at System.Type.IsAssignableFrom (System.Type c) [0x0] in filename unknown:0 at FubuCore.TypeExtensions.IsConcreteTypeOf[IApplicationSource] (System.Type pluggedType) [0x0] in filename unknown:0 at Fubu.Running.ApplicationSourceFinder.Findm__1 (System.Type x) [0x0] in filename unknown:0 at System.Linq.Enumerable+CreateWhereIteratorc__Iterator1E`1[System.Type].MoveNext () [0x0] in filename unknown:0 at System.Linq.Enumerable+CreateDistinctIteratorc__Iterator3`1[System.Type].MoveNext () [0x0] in filename unknown:0 at System.Linq.Enumerable.Any[Type] (IEnumerable`1 source) [0x0] in filename unknown:0 at Fubu.Running.ApplicationSourceChooser.Find (Fubu.Running.StartApplication message, System.Action`1 onFound) [0x0] in filename unknown:0 at Fubu.Running.RemoteFubuMvcBootstrapper.Receive (Fubu.Running.StartApplication message) [0x0] in filename unknown:0 at Bottles.Services.Messaging.MessagingHub+c__DisplayClass3`1[Fubu.Running.StartApplication].Sendb__1 (IListener`1 x) [0x0] in filename unknown:0 at System.Collections.Generic.GenericEnumerableExtensions.Each[IListener`1] (IEnumerable`1 values, System.Action`1 eachAction) [0x0] in filename unknown:0 at Bottles.Services.Messaging.MessagingHub.Send[StartApplication] (Fubu.Running.StartApplication message) [0x0] in filename unknown:0 at Bottles.Services.Messaging.MessagingHub+Sender`1[Fubu.Running.StartApplication].Send (System.Object o, Bottles.Services.Messaging.MessagingHub listeners) [0x0] in filename unknown:0 at Bottles.Services.Messaging.MessagingHub.SendJson (System.String json) [0x0] in filename unknown:0 at Bottles.Services.Remote.RemoteServicesProxy.SendJson (System.String json) [0x0] in filename unknown:0 at (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices:InternalExecute (System.Reflection.MethodBase,object,object[],object[]) at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage (System.MarshalByRefObject target, IMethodCallMessage reqMsg) [0x0] in filename unknown:0 Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] in filename unknown:0 Shutting down finalizer thread timed out. Failed to destroy mutex 0x965988 error code 16 errno 2 ___ 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] Installing mono via copy
/usr/local is the default prefix if you don't supply one. This is normally the standard in most open source projects and the motivation of it is not to conflict with software installed by packages (which goes to /usr instead). But given that you're in an embedded system I would just use the /usr prefix to prevent incompatibilities that normally arise when integrating software between /usr and /usr/local So to answer your question: yes, you still need to specify the prefix at configure time, but define a DESTDIR at installation time. Maybe this example script can clear any more doubts you have (it's used to create .deb packages): https://github.com/7digital/7digital-mono/blob/master/build-mono-package.bash On 13/12/13 20:08, Chris Tacke wrote: So if I make install DESTDIR /path/to/temp do I still need to install on the target at /usr/local (te default prefix), or will “anywhere” work? I assume the former, but am trying to understand. -Chris *From:*mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Nikita Tsukanov *Sent:* Friday, December 13, 2013 1:06 PM *To:* mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Installing mono via copy - set a custom prefix (and other stuff) during configure That's the problem. It tries to look for mscorlib at $prefix/lib/mono/blablablah instead of /usr/lib. Instead of using custom prefix just configure it with normal (i. e. /usr) and use make install DESTDIR=/path/to/temp/dir. It will install all files to that directory, and you'll be able to create your tarball. 2013/12/13 Chris Tacke cta...@opennetcf.com mailto:cta...@opennetcf.com I have an embedded Linux platform on which I need to install Mono. The platform does not have any installer tools like apt or whatever. I have to custom build Mono for the platform for a variety of reasons. I am successfully building Mono from source under an Ubuntu machine. That works just fine. The problem I'm now facing is how to distribute the resulting build. Due to size contraints, I've compiled only the 4.5 stuff, plus I've pulled out a variety of things like System.Drawing, all of the WinForms stuff, etc. I've also stripped the binaries. What I did was: - set a custom prefix (and other stuff) during configure - make make install. - Go into the install folder and trim out stuff I don't need and strip binaries So now I have a set of folders that contain Mono. My hope was that I could tar these up, copy that to the destination, untar it in the /usr directory so that the mono bin files end up in /usr/bin, the mono lib files end up in /usr/lib etc. Doing this I success if I do a mono -V. I get version info. However, if I try to actually run a mono app, it complains about not finding mscorlib.dll. It's looking in the path where I set the prefix back on the build machine. How should I be going about doing an installation like this? What am I missing in my process? -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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] Installing mono via copy
If you were right, DESTDIR env var would not exist, and one would simply use the --prefix flag at configure time. DESTDIR is used as a prefix to the prefix, that is, if your prefix was /foo and you set DESTDIR to /bar, then the files go to /bar/foo, to let you tar them up easily from /bar/foo but still having built binaries and scripts that are meant to be placed in /foo. After you compress /bar/foo, then you should later untar to /foo to make it work, obviously. This is essentially how deb/rpm packaging works, kinda. On 13/12/13 21:02, Nikita Tsukanov wrote: You should install to the _same_ prefix you configured your sources. ./configure script hardcodes some paths based on prefix value and compiled code will expect to find needed files there. 2013/12/13 Andrés G. Aragoneses kno...@gmail.com mailto:kno...@gmail.com /usr/local is the default prefix if you don't supply one. This is normally the standard in most open source projects and the motivation of it is not to conflict with software installed by packages (which goes to /usr instead). But given that you're in an embedded system I would just use the /usr prefix to prevent incompatibilities that normally arise when integrating software between /usr and /usr/local So to answer your question: yes, you still need to specify the prefix at configure time, but define a DESTDIR at installation time. Maybe this example script can clear any more doubts you have (it's used to create .deb packages): https://github.com/7digital/7digital-mono/blob/master/build-mono-package.bash On 13/12/13 20:08, Chris Tacke wrote: So if I make install DESTDIR /path/to/temp do I still need to install on the target at /usr/local (te default prefix), or will “anywhere” work? I assume the former, but am trying to understand. -Chris *From:*mono-devel-list-boun...@lists.ximian.com mailto:mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com mailto:mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Nikita Tsukanov *Sent:* Friday, December 13, 2013 1:06 PM *To:* mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Installing mono via copy - set a custom prefix (and other stuff) during configure That's the problem. It tries to look for mscorlib at $prefix/lib/mono/blablablah instead of /usr/lib. Instead of using custom prefix just configure it with normal (i. e. /usr) and use make install DESTDIR=/path/to/temp/dir. It will install all files to that directory, and you'll be able to create your tarball. 2013/12/13 Chris Tacke cta...@opennetcf.com mailto:cta...@opennetcf.com mailto:cta...@opennetcf.com mailto:cta...@opennetcf.com I have an embedded Linux platform on which I need to install Mono. The platform does not have any installer tools like apt or whatever. I have to custom build Mono for the platform for a variety of reasons. I am successfully building Mono from source under an Ubuntu machine. That works just fine. The problem I'm now facing is how to distribute the resulting build. Due to size contraints, I've compiled only the 4.5 stuff, plus I've pulled out a variety of things like System.Drawing, all of the WinForms stuff, etc. I've also stripped the binaries. What I did was: - set a custom prefix (and other stuff) during configure - make make install. - Go into the install folder and trim out stuff I don't need and strip binaries So now I have a set of folders that contain Mono. My hope was that I could tar these up, copy that to the destination, untar it in the /usr directory so that the mono bin files end up in /usr/bin, the mono lib files end up in /usr/lib etc. Doing this I success if I do a mono -V. I get version info. However, if I try to actually run a mono app, it complains about not finding mscorlib.dll. It's looking in the path where I set the prefix back on the build machine. How should I be going about doing an installation like this? What am I missing in my process? -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman
Re: [Mono-dev] AppDomain Support
On 11/12/13 03:33, Christian Smith wrote: I was wondering what the current status of AppDomain support is and what the plans for this are? I.e. is it not implemented? 70% implemented etc... AFAIK it's fully implemented. Do you see any problems with it? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Threading.Monitor.IsEntered? Will this be implemented?
Seems very straightforward to implement. If I were you I would just have
a crack at it, and propose it as a pull request. It's the best way to
get unblocked.
On 10/12/13 00:50, vbguy81 wrote:
Hi,
I have a project in .NET 4.5 that utilizes Monitor.IsEntered to check if
there is still a lock on a particular reference. You can lock multiple times
by doing something like the following.
Monitor.Enter(MyLock);
Monitor.Enter(MyLock);
//..Do something..
Monitor.Exit(MyLock);
//there is still a lock.
As a precaution, when an exception is thrown, I'll loop over MyLock with
Monitor.Exit until IsEnter() returns false. In some of my more complicated
Multi-threaded programs the reference and at times these can get locked
twice (Try to avoid this, but it happens). For me, using Monitor.IsEntered
is an easy way to make sure everything gets cleaned up.
In Thread.cs, I found the following:
#if NET_4_5
[MonoTODO]
public static bool IsEntered (object obj)
{
throw new NotImplementedException ();
}
#endif
Does anyone have a timeline when this might be implemented?
Thanks,
Harry
--
View this message in context:
http://mono.1490590.n4.nabble.com/System-Threading-Monitor-IsEntered-Will-this-be-implemented-tp4661494.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
Re: [Mono-dev] Compiling Mono 3.2.3 libraries - Windows/Visual Studio/3264bit
On 07/12/13 10:25, BearishSun wrote: Hello, I have managed to compile Mono 3.2.3. on Windows with Visual Studio 2012 using both 32bit and 64bit configurations but had some issues along the way. As I have found little to none up-to-date information regarding this topic, thought I'd share them with people in case anyone finds them useful. I have only compiled the native libraries (mono-2.0.dll, mono.exe). Here goes: snip / These changes would have been much easier to grok if each of them was in .diff format. Bonus points if you can create a pull request (with 12 commits) in github. Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] why does DateTime.Now.IsDaylightSavingTime() returns false when it should be true.
Seconded.
On 07/11/13 11:16, Stifu wrote:
I'm in no position to accept or review your patch, but I wanted to thank you
for taking the time and putting in the efforts needed to make Mono better
for everyone.
I hope this pull request gets attention soon.
Alistair Bush wrote
Hi guys,
Please note that I have cleaned this up and bit and submitted a pull
request
https://github.com/mono/mono/pull/800
Feedback welcome.
On Wed, Oct 30, 2013 at 11:51 PM, Alistair Bush lt;
alistair.bush@
gt; wrote:
Ok so firstly this is like the MOST C ive ever written in my life..
and it looks ugly and ive only vagely checked that it doesn't break
the northern hemisphere.
But isn't this a better patch of the method?
(https://github.com/alistair/mono/commit/6912202aab5a424e98bc44d7b988c2791f91)
Any help turning this into an acceptable pull request would be really
appreciated.
diff --git a/mono/metadata/icall.c b/mono/metadata/icall.c
index 618e4da..7f47624 100644
--- a/mono/metadata/icall.c
+++ b/mono/metadata/icall.c
@@ -5930,10 +5930,12 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
struct tm start, tt;
time_t t;
- long int gmtoff;
- int is_daylight = 0, day;
+ long int gmtoff, gmtoff_st, gmtoff_ds;
+ int day, transitioned;
char tzone [64];
+ gmtoff_st = gmtoff_ds = transitioned = 0;
+
MONO_ARCH_SAVE_REGS;
MONO_CHECK_ARG_NULL (data);
@@ -5974,8 +5976,10 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
t += 3600*24;
tt = *localtime (t);
+long int gmtoff_after = gmt_offset(tt, t);
+
/* Daylight saving starts or ends here. */
- if (gmt_offset (tt, t) != gmtoff) {
+ if (gmtoff_after != gmtoff) {
struct tm tt1;
time_t t1;
@@ -5995,36 +5999,37 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
strftime (tzone, sizeof (tzone), %Z, tt);
/* Write data, if we're already in daylight saving, we're done. */
- if (is_daylight) {
- mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
- mono_array_set ((*data), gint64, 1, ((gint64)t1 + EPOCH_ADJUST) *
1000L);
- return 1;
+ if (tt.tm_isdst) {
+ mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
+ mono_array_set ((*data), gint64, 0, ((gint64)t1 + EPOCH_ADJUST) *
1000L);
+ if (gmtoff_ds == 0) {
+ gmtoff_st = gmtoff;
+ gmtoff_ds = gmtoff_after;
+ }
+ transitioned++;
} else {
- struct tm end;
time_t te;
+ te = mktime (tt);
- memset (end, 0, sizeof (end));
- end.tm_year = year-1900 + 1;
- end.tm_mday = 1;
-
- te = mktime (end);
-
- mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
- mono_array_set ((*data), gint64, 0, ((gint64)t1 + EPOCH_ADJUST) *
1000L);
mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
mono_array_set ((*data), gint64, 1, ((gint64)te + EPOCH_ADJUST) *
1000L);
- is_daylight = 1;
+ if (gmtoff_ds == 0) {
+ gmtoff_st = gmtoff_after;
+ gmtoff_ds = gmtoff;
+ }
+ transitioned++;
}
/* This is only set once when we enter daylight saving. */
- mono_array_set ((*data), gint64, 2, (gint64)gmtoff * 1000L);
- mono_array_set ((*data), gint64, 3, (gint64)(gmt_offset (tt, t) -
gmtoff) * 1000L);
-
+ if (tt1.tm_isdst) {
+ mono_array_set ((*data), gint64, 2, (gint64)gmtoff_st * 1000L);
+ mono_array_set ((*data), gint64, 3, (gint64)(gmtoff_ds - gmtoff_st)
* 1000L);
+ }
gmtoff = gmt_offset (tt, t);
}
}
- if (!is_daylight) {
+ if (transitioned 2) {
strftime (tzone, sizeof (tzone), %Z, tt);
mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
On Tue, Oct 29, 2013 at 9:13 AM, Alistair Bush lt;
alistair.bush@
gt; wrote:
Well that certainly sucks.
On Tue, Oct 29, 2013 at 3:03 AM, Robert Jordan lt;
robertj@
gt; wrote:
On 28.10.2013 07:35, Alistair Bush wrote:
I am trying to figure out why exactly running
DateTime.Now.IsDaylightSavingTIme() returns false.
I live in the Auckland/Pacific timezone and pretty much everywhere I
look it confirms that yes it is daylight saving time.
Unfortunately, I don't remember the details, but I'm pretty
sure that ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData
has a bug w/ respect to the Southern Hemisphere.
The code assumes that a year always begins outside a DST zone,
and this is obviously incorrect for the Southern Hemisphere.
To fix this, the local var is_daylight must be properly
initialized. Currently, it's always 0 at start, but it must
be initialized with 1 when January, 1st is inside a DST
zone.
Maybe this:
is_daylight = start.tm_isdst 0;
just before
/* For each day of the year, calculate the tm_gmtoff. */
for (day = 0; day 365; day++) {
Robert
___
Mono-devel-list mailing list
Mono-devel-list@.ximian
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fix for using GTK# in mono embedded application
On 03/11/13 15:58, Vardar Sahin wrote:
Environment.GetCommandLineArgs is an internal call and my assumption was
that the internal call is not registered to a C function. But now I see
that I can call Environment.GetCommandLineArgs.
I checked it out and Environment.GetCommandLineArgs returns null if you
embed mono into your application.
So you have to check for a null reference.
Ok thanks, I updated the pull request adding a null check
And and maybe you have to set
GLib.Global.ProgramName to static name in case.
What do you mean? GLib.Global.ProgramName is already static.
Thanks
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
Being not registered means that accessing GetCommandLineArgs throws
an exception? If yes, what kind?
On 02/11/13 22:10, Vardar Sahin wrote:
Hey Andrés,
thanks for the quick replay. I am not sure if this will fix the
problem.
I think the problem is that you can not call
Environment.__GetCommandLineArgs() when you embed mono.
Environment.__GetCommandLineArgs() is an internal call and it
seems like
it is not registered when you embed mono.
Best
Sahin
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
On 02/11/13 21:42, Vardar Sahin wrote:
Hey monodev fellows,
first of all I appreciate all your hard work and want to
contribute this
to the mono project.
Right now it is not possible to use GTK# with an
application which
embeds mono. GTK# works just fine if you use mono as a
standalone
application eg mono.exe.
The reason why GTK# does not works when you embed mono
is as
fallowing.
Each GTK# Application has to call Application.Init().
This functions is like this.
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
SynchronizationContext.SetSynchronizationContext (new
GLib.GLibSynchronizationContext ());}
Init will fail on SetPrgname (); when mono is embedded
in an
application.
static void SetPrgname ()
{
GLib.Global.ProgramName =
System.IO.Path.GetFileNameWithoutExtension
(Environment.GetCommandLineArgs () [0]);
}
When embedding Mono, Environment.GetCommandLineArgs ()
will fail
because
it is not set to anything. When you run the same on
mono as a
standalone
application it will work because mono will pass the
command line
argument via Environment.GetCommandLineArgs().
I fixed it by registering the internal call for
Environment.GetCommandLineArgs to my own fucntion and
return just a
dummy string.
My suggestion would be to do the same in mono when you
embed it
or to
change SetPrgname to not relay on
Environment.GetCommandLineArgs ().
Sahin, wouldn't this also fix your use case?
https://github.com/mono/gtk-sharp/pull/90/files
https://github.com/mono/gtk-__sharp/pull/90/files
https://github.com/mono/gtk-__sharp/pull/90/files
https://github.com/mono/gtk-sharp/pull/90/files
Thanks
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
mailto:Mono-devel-list@lists.__ximian.com
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.__com
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.__com
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/__mailman/listinfo
Re: [Mono-dev] Fix for using GTK# in mono embedded application
Why do you assume that there is a bad consequence if g_set_prgname() is
not called? Please test it, and if you confirm any bad behaviour, come
back with more info.
On 03/11/13 20:50, Vardar Sahin wrote:
I think that GLib.Global.ProgramName has to be set to a value.I am not
sure what will happen when it is not set.
In case args == null and we should set GLib.Global.ProgramName to a
static value like this.
var args = Environment.GetCommandLineArgs ();
if (args != null args.Length 0){
GLib.Global.ProgramName =
System.IO.Path.GetFileNameWithoutExtension (args [0]);
}else
{
GLib.Global.ProgramName = EmbeddedMono;
}
2013/11/3 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
On 03/11/13 15:58, Vardar Sahin wrote:
Environment.GetCommandLineArgs is an internal call and my
assumption was
that the internal call is not registered to a C function. But
now I see
that I can call Environment.__GetCommandLineArgs.
I checked it out and Environment.GetCommandLineArgs returns null
if you
embed mono into your application.
So you have to check for a null reference.
Ok thanks, I updated the pull request adding a null check
And and maybe you have to set
GLib.Global.ProgramName to static name in case.
What do you mean? GLib.Global.ProgramName is already static.
Thanks
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
Being not registered means that accessing
GetCommandLineArgs throws
an exception? If yes, what kind?
On 02/11/13 22:10, Vardar Sahin wrote:
Hey Andrés,
thanks for the quick replay. I am not sure if this will
fix the
problem.
I think the problem is that you can not call
Environment.GetCommandLineArgs() when you embed mono.
Environment.GetCommandLineArgs() is an internal
call and it
seems like
it is not registered when you embed mono.
Best
Sahin
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
On 02/11/13 21:42, Vardar Sahin wrote:
Hey monodev fellows,
first of all I appreciate all your hard work
and want to
contribute this
to the mono project.
Right now it is not possible to use GTK# with an
application which
embeds mono. GTK# works just fine if you use
mono as a
standalone
application eg mono.exe.
The reason why GTK# does not works when you
embed mono
is as
fallowing.
Each GTK# Application has to call
Application.Init().
This functions is like this.
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
SynchronizationContext.__SetSynchronizationContext (new
GLib.__GLibSynchronizationContext ());}
Init will fail on SetPrgname (); when mono is
embedded
in an
application.
static void SetPrgname ()
{
GLib.Global.ProgramName =
System.IO.Path.__GetFileNameWithoutExtension
(Environment.__GetCommandLineArgs () [0]);
}
When embedding Mono,
Environment.GetCommandLineArgs ()
will fail
because
it is not set to anything. When you run the
same on
mono as a
standalone
application it will work because mono will
pass the
command line
argument via
Environment.__GetCommandLineArgs().
I fixed it by registering the internal call for
Environment.GetCommandLineArgs to my own
fucntion and
return just
Re: [Mono-dev] Fix for using GTK# in mono embedded application
On 02/11/13 21:42, Vardar Sahin wrote:
Hey monodev fellows,
first of all I appreciate all your hard work and want to contribute this
to the mono project.
Right now it is not possible to use GTK# with an application which
embeds mono. GTK# works just fine if you use mono as a standalone
application eg mono.exe.
The reason why GTK# does not works when you embed mono is as fallowing.
Each GTK# Application has to call Application.Init().
This functions is like this.
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
SynchronizationContext.SetSynchronizationContext (new
GLib.GLibSynchronizationContext ());}
Init will fail on SetPrgname (); when mono is embedded in an application.
static void SetPrgname ()
{
GLib.Global.ProgramName = System.IO.Path.GetFileNameWithoutExtension
(Environment.GetCommandLineArgs () [0]);
}
When embedding Mono, Environment.GetCommandLineArgs () will fail because
it is not set to anything. When you run the same on mono as a standalone
application it will work because mono will pass the command line
argument via Environment.GetCommandLineArgs().
I fixed it by registering the internal call for
Environment.GetCommandLineArgs to my own fucntion and return just a
dummy string.
My suggestion would be to do the same in mono when you embed it or to
change SetPrgname to not relay on Environment.GetCommandLineArgs ().
Sahin, wouldn't this also fix your use case?
https://github.com/mono/gtk-sharp/pull/90/files
Thanks
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fix for using GTK# in mono embedded application
Being not registered means that accessing GetCommandLineArgs throws an
exception? If yes, what kind?
On 02/11/13 22:10, Vardar Sahin wrote:
Hey Andrés,
thanks for the quick replay. I am not sure if this will fix the problem.
I think the problem is that you can not call
Environment.GetCommandLineArgs() when you embed mono.
Environment.GetCommandLineArgs() is an internal call and it seems like
it is not registered when you embed mono.
Best
Sahin
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
On 02/11/13 21:42, Vardar Sahin wrote:
Hey monodev fellows,
first of all I appreciate all your hard work and want to
contribute this
to the mono project.
Right now it is not possible to use GTK# with an application which
embeds mono. GTK# works just fine if you use mono as a standalone
application eg mono.exe.
The reason why GTK# does not works when you embed mono is as
fallowing.
Each GTK# Application has to call Application.Init().
This functions is like this.
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
SynchronizationContext.__SetSynchronizationContext (new
GLib.__GLibSynchronizationContext ());}
Init will fail on SetPrgname (); when mono is embedded in an
application.
static void SetPrgname ()
{
GLib.Global.ProgramName =
System.IO.Path.__GetFileNameWithoutExtension
(Environment.__GetCommandLineArgs () [0]);
}
When embedding Mono, Environment.GetCommandLineArgs () will fail
because
it is not set to anything. When you run the same on mono as a
standalone
application it will work because mono will pass the command line
argument via Environment.__GetCommandLineArgs().
I fixed it by registering the internal call for
Environment.GetCommandLineArgs to my own fucntion and return just a
dummy string.
My suggestion would be to do the same in mono when you embed it
or to
change SetPrgname to not relay on
Environment.GetCommandLineArgs ().
Sahin, wouldn't this also fix your use case?
https://github.com/mono/gtk-__sharp/pull/90/files
https://github.com/mono/gtk-sharp/pull/90/files
Thanks
_
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.__com
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
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] sgen optimizing
On 28/10/13 15:42, Rodrigo Kumpera wrote: The downside of a larger nursery is the increased pause times for minor collections. The concurrent-garbage-collector announced at the Mono 3.0 release would also be an alternative to avoid the pause times, right? If yes, is the concurrent-garbage-collector the default for multi-core archs? If not, why not? Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing NET_2_0 define
On 18/10/13 14:58, Jonathan Pryor wrote: On Oct 16, 2013, at 10:00 AM, Alexander Köplinger alex.koeplin...@outlook.com wrote: Wouldn’t it make sense to remove the #if NET_2_0 checks in the codebase as those are now unnecessary (every profile is now 2.0 or later)? Or are they actually required for something? If not, I’d provide a pull request to clean up those checks. They are not required, but removing them would add extra commit noise, which isn't necessary. Current policy (as it were) is to remove nearby `#if`s when modifying nearby code, so things can be improved in an ongoing basis without littering commit history. WRT git-blame, changing whitespace in existing code clutters commit history, but removing code doesn't. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
If you're able to reproduce it with 3.3 and not with 2.10.x, you should
definitely open a bug report for it in http://bugzilla.xamarin.com/
stating [regression] in the bug summary.
Also, I would open a separate bug report for the segfault you're getting
when running with MONO_DISABLE_AIO (pasting the backtrace of the
segfault, with debug symbols installed).
On 07/08/13 14:02, Alfred Hall wrote:
Tried running it with sgen or boehm on 2.10? Worth trying both I think.
Also how about 3.3 (master) ?
-Original message-
*From:* Nikita Tsukanov kek...@gmail.com
*Sent:* Wednesday 7th August 2013 12:54
*To:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener)
locking up on linux
I've rewritten my SCGI server to work with TPL directly instead of
using async/await to make it run on mono 2.10. Then I've tried to
run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets
backend and to hammer it with jmeter. 500K requests without any
lockups on Mono 2.10, lockup at 22164th request on mono 3.2.
Server source code is still on GitHub -
https://github.com/kekekeks/scgi-sharp
2013/8/7 Greg Young gregoryyou...@gmail.com
mailto:gregoryyou...@gmail.com
I believe attaching a debugger changes things like optimizations
from occurring (not positive but it does in clr)
On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
Huh, it doesn't require debugger to be _attched_, just
debugging subsystem initialized i. e. if I launch this
program as a debugger it doesn't lock up.
publicstaticvoidMain(string[]args)
{
intport=27042;
if(args.Length !=0)
port=int.Parse(args[0]);
while(true)
{
varvm=
Mono.Debugger.Soft.VirtualMachineManager.Listen(newIPEndPoint(IPAddress.Loopback,port));
vm.Resume();
vm.Detach();
}
}
I'll use running with
--debugger-agent=transport=dt_socket,address=127.0.0.1:27042
http://127.0.0.1:27042 as a temporary workaround since
performance doesn't degrade a lot.
2013/8/7 Nikita Tsukanov kek...@gmail.com
I suspect that the problem is actually with thread pool
itself. I've created socket layer implementation using
libevent (wrapped with Oars) and send/recv that utilizes
thread pool for cases when it's unable to complete
operation synchronously. It survives longer, but still
locks up after a while. Same behavior with debugger -
I'm unable to reproduce the issue when running under it.
I also unable to grab thread stack traces, it prints
Full thread dump: and nothing else.
2013/8/7 Greg Young gregoryyou...@gmail.com
We will see your test then as it will probably
affect us as well
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Greg, I've tried running my server with mono
compiled from master (with pull request #703
merged in), still freezes after a while.
2013/8/7 Greg Young gregoryyou...@gmail.com
Do you have our pull req? We are stable
after (and seriously read history of this list)
On Tuesday, August 6, 2013, Nikita Tsukanov
wrote:
https://github.com/kekekeks/scgi-sharp -
here is my SCGI server with host for
NancyFx. If you run Sandbox.exe with
--echo-server it will not use nancy
infrastructure and will respond
directly. It locks up after several
thousands of requests under jmeter.
Simple nginx configuration:
location /
{
include /etc/nginx/scgi_params;
scgi_pass 127.0.0.1:10081
http://127.0.0.1:10081;
}
Now I'm looking for alternative socket
library to use it as a replacement for
System.Net.Sockets.
2013/8/6 Greg Young
gregoryyou...@gmail.com
Actually not that surprised we also
found out file stream.flush(true)
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
On 06/08/13 18:42, Nikita Tsukanov wrote: Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00 UTC 2013) Mono 3.2.0 does *not* have Yuri's patch. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
I guess it means that it is a race condition which is not reproducible inside the debugger (as the debugger slows things down). On 06/08/13 21:18, Nikita Tsukanov wrote: Running with mono from master haven't helped. And I'm not sure what the hell is going on, but I cann't reproduce the issue when running under... Monodevelop's debugger. It runs perfectly under it, but when I try to run the same binary from console (even with --debug option) it locks up or segfaults. Does anyone know what does it mean? 2013/8/6 Nikita Tsukanov kek...@gmail.com mailto:kek...@gmail.com Great. It locked up with my more complex logic. Funny fact: NancyFx increases request processing time from 2ms to 70ms with the same echo response. Another funny fact: with MONO_DISABLE_AIO I've got segfault. Now I'll try to use build patched mono. Not sure that it's the same issue, because in my case it never tries to read and write simultaneously on the same socket. 2013/8/6 Greg Young gregoryyou...@gmail.com mailto:gregoryyou...@gmail.com There are many cases the patch we provided does not affect eg no overlap in io between send/receive On Tuesday, August 6, 2013, Nikita Tsukanov wrote: Interesting... I've written a simple server using only Socket.BeginRecieve and Socket.BeginSend. It just reads 100 bytes and then sends hardcoded HTTP response. Now jmeter is working for 5 minutes and it still responds with Lorem ipsum ... perfectly. I'll try to port my SCGI server logic from NetworkStream to Socket and see what will happen. 2013/8/6 Andrés G. Aragoneses kno...@gmail.com On 06/08/13 18:42, Nikita Tsukanov wrote: Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00 UTC 2013) Mono 3.2.0 does *not* have Yuri's patch. _ Mono-devel-list mailing list Mono-devel-list@lists.ximian.__com http://lists.ximian.com/__mailman/listinfo/mono-devel-__list http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ 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] NancyFX self hosting (HttpListener) locking up on linux
On 04/08/13 03:07, Alfred Hall wrote: Hi there. I'm running the NancyFX web framework in self hosting mode which is using HttpListener which basically means I deploy an executable and run it and it will start a webserver on localhost on a TCP port of choice. I then use nginx to proxy to it. I first ran my executable on my macbook pro and bombarded it with jmeter and it coped fine and no issues. I then deployed on my debian wheezy 64 bit linux box running on top of KVM using mono 3.2.0 and performed the same jmeter experiment. It locks up fairly quickly and wont take any new requests. I've tried using both sgen and boehm but they behave similarly although it seems to lock up faster when using sgen. I also tried enabling MONO_DISABLE_AIO but it doesn't make any difference. Anyone had similar issues? I tried using self hosted ServiceStack which also uses HttpListener and had similar issues so I'm finding it unlikely that the bug is in NancyFX itself. I tried installing mono 2.10.8 to check if this is a regression, but getting exactly the same results. Any idea how I can debug this further or what could be going on. Hey Alfred. Could you try mono master (3.3) instead of 3.2? I mention this because this pull request [1] has been merged recently, which could help in this situation (and wouldn't make much difference in Mac since the problem in this platform is worked-around by avoiding kqueue [2]). [1] https://github.com/mono/mono/pull/703 [2] https://github.com/mono/mono/blob/master/configure.in#L1823 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DataRowCollection.Remove performance
On 01/08/13 06:58, Julian Hamilton wrote: In my own testing this sped up row deletions by approximately 360%, but you can ascertain a more accurate measure for yourself. Good catch! It might be better to provide this contribution in the form of a github pull request. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FIXED: Problems with html in ListItems
On 30/07/13 10:45, APS wrote: I filed a bugreport and suggested a fix https://bugzilla.xamarin.com/process_bug.cgi I removed the html encoding when the text is written on the inner html part of the tag. It seems to work on my app that is pretty large. As I have another wanna-be fix that I described here and on bugreports, what's the best way to have it reviewed? Create a Pull Request on git or keep on describing the fix here? Create a pull request on github, and reference the pullrequest URL in bugzilla. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] error when building libgdiplus
On 26/07/13 09:13, Kostas Cibulskas wrote: Hi, When running make, there is an error in libgdiplus/tests: libtool: link: gcc -g -O2 -pthread -o .libs/testgdi testgdi.o ../src/.libs/libgdiplus.so -lpthread -lfontconfig -pthread /usr/bin/ld: testgdi.o: undefined reference to symbol 'g_print' /usr/bin/ld: note: 'g_print' is defined in DSO /lib/x86_64-linux-gnu/libglib-2.0.so.0 so try adding it to the linker command line I see the missing library added in a Makefile, but for some reason it is not linked. Fix to this is to add -lglib-2.0 and -lX11 to LIBS variable inside Makefile. I cloned libgdiplus from github yesterday, so the problem is new I guess. No idea how could I fix it in a commit, so I though I should let you guys know about this. This is fixed already by this pull request: https://github.com/mono/libgdiplus/pull/7 You could +1 in the PR to ping the maintainers ;) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Random Internal Compiler Error with extension methods on interfaces?
It doesn't compile with Mono 3.0.x. When I said it doesn't throw an error,
I meant that it doesn't throw an exception (internal compiler error), but
it shows the compiler error you describe (ambiguity). So there's no bug
anymore. Upgrade Mono.
On 3 February 2013 19:36, Jordan Earls ea...@lastyearswishes.com wrote:
I'll attempt that. In the mean time, I uncovered the core underlying
cause. It doesn't properly detect an ambiguity I had in my code. This
code shouldn't compile. It should give a compiler error at the `Foo`
constructors
public class Foo
{
public Foo(int? s=null, string m=null)
{
}
public Foo(string m=null, int? s=null)
{
}
public void Get()
{
throw new NotImplementedException();
}
}
class MainClass
{
public static void Main(string[] args)
{
var f=new Foo();
Console.WriteLine(Hello World!);
}
}
The fact that this compiled on latest Mono makes me think it's a bug.
if you replace the `int?` on the Foo constructors with `object`, it'll
throw a compiler error about ambiguous calls. This actually has
nothing to do with extension methods. It's the compiler not detecting
ambiguity where there is some.
On Sun, Feb 3, 2013 at 5:58 AM, Daniel Lo Nigro li...@dan.cx wrote:
I tried comparing Mono 2.10.8 to 3.0.2 in Github but there's 6,566
commits
between them so it's hard to tell exactly which one fixed it :)
If you have time to, you could try a few different Mono versions and
narrow
it down to a release that fixes it. I'd try the last release of 2.10, the
first and last (2.11.4) releases of 2.11, and the first release of 3.0.
It
was probably fixed between 2.10 - 2.11 or 2.11 - 3.0.
On Sun, Feb 3, 2013 at 2:10 PM, Jordan Earls ea...@lastyearswishes.com
wrote:
Awesome.. Is there any reports of bugs that could've caused this? I'd
really like to workaround this issue for compatibility reasons with
older versions of mono
On Sat, Feb 2, 2013 at 9:46 PM, Andres G. Aragoneses kno...@gmail.com
wrote:
On 03/02/13 02:37, Jordan Earls wrote:
If anyone wants to see the bug in action, extract
http://earlz.net/static/repro.tgz
I just tested compiling with Mono 3.0.2 and there is no compiler
error,
so
the bug is fixed in this version.
___
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] Mono on SMARTOS
On 10 October 2012 15:48, Autif Khan autif.ml...@gmail.com wrote: On Tue, Oct 9, 2012 at 3:42 PM, Andres G. Aragoneses kno...@gmail.com wrote: On 09/10/12 14:53, Autif Khan wrote: On Tue, Oct 9, 2012 at 8:11 AM, Fatih Soydan [Personal] fatihsoy...@fatihsoydan.com wrote: Hi; Are there any pre compiled packages for smartos ? SmartOS seems to be catching fire :-) While there are no binaries, there are some tweaks needed to compile mono on SmartOS. Take a look at the following thread from a few weeks ago. http://lists.ximian.com/pipermail/mono-devel-list/2012-August/039520.html If you send a pull request with the change, it will most likely be merged to master so nobody needs tweaks or forks. Will do, I am still trying to get gcc to work on openindiana, will Cool catch you (knocte) up on #mono-dev one of these days - once I am ready. No need, somebody will most likely reply/merge to the pull-request. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is there any reason to not add instead a flag?
Ok fair enough, I'll implement your suggestions. You know, it's not that I don't like to document stuff (I'm almost done porting [1] to [2] so we can replace it in [3] ;) ) Regards, Andrés [1] http://www.mono-project.com/Compiling_Mono_From_SVN [2] http://www.mono-project.com/Compiling_Mono_From_Git [3] http://www.mono-project.com/Compiling El 12/08/10 04:39, Miguel de Icaza escribió: Hello, I thought about this, but it would be a bit weird to use a tool called mono-api-info if you don't want the API but the ABI. This is why I thought it would be more intuitive this way. Minor issue. It goes against the If it is not documented, it does not exist rule. Then mono-api-info doesn't exist either :) (there's no man page for it) What we have here is an opportunity. You now get to write the man page and document what both do. I'm thinking I can get it to be the same executable, but can it be a different script called mono-abi-info which internally calls mono-api-info.exe passing the flag? I do not want that, it is a minor aesthetic issue. Just change it to --abi and let us be done. If there's no man page for mono-api-info, I prefer to do it in a wiki page, ok? (Don't know man format enough to not copy-paste the structure ;) ) I realize it is more convenient for you, but it is not more convenient for the user that has to wonder What the hell does this do? Granted, there is no man page, so this is why we are going to turn a negative into a positive. ___ 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] Is there any reason to not add instead a flag?
Hey Miguel, sorry for the small delay to reply:
El 10/08/10 21:41, Miguel de Icaza escribió:
In your recent commit, you added a new command to mcs/tools/corcompare,
the mono-abi-info tool. I do not know what this tool does, and I do
not know why we could not just have used mono-api-info with a new flag
--abi instead of installing another executable.
I thought about this, but it would be a bit weird to use a tool called
mono-api-info if you don't want the API but the ABI. This is why I
thought it would be more intuitive this way.
It goes against the If it is not documented, it does not exist rule.
Then mono-api-info doesn't exist either :) (there's no man page for it)
So can we:
(a) get this merged into mono-api-info
I'm thinking I can get it to be the same executable, but can it be a
different script called mono-abi-info which internally calls
mono-api-info.exe passing the flag?
(b) document this on the wiki or the relevant man pages?
If there's no man page for mono-api-info, I prefer to do it in a wiki
page, ok? (Don't know man format enough to not copy-paste the structure ;) )
I'll work on it tomorrow. Thanks for the feedback.
Andres
miguel
Branch: refs/heads/master
Home: http://github.com/mono/mono
Commit: c508a786c106ceff274b9b985919368b6b404342
Author: Andrés G. Aragoneses kno...@gmail.com
Date: 08/10/2010 14:36:27
URL:
http://github.com/mono/mono/commit/c508a786c106ceff274b9b985919368b6b404342
Added new ABI mode to mono-api-info tool, wrapped in a mono-abi-info script.
2010-08-05 Andrés G. Aragoneses and...@lindenlab.com
* mcs/tools/corcompare/mono-api-info.cs: Implemented new mode to show ABI.
* mcs/tools/corcompare/Makefile: added mono-abi-info autofoo.
* scripts/.gitignore: added mono-abi-info.
* scripts/Makefile.am: added mono-abi-info autofoo.
Changed paths:
M ChangeLog
M mcs/tools/corcompare/ChangeLog
M mcs/tools/corcompare/Makefile
M mcs/tools/corcompare/mono-api-info.cs
M scripts/.gitignore
M scripts/Makefile.am
Modified: ChangeLog
===
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2010-08-05 Andr??s G. Aragoneses and...@lindenlab.com
+
+* scripts/.gitignore: added mono-abi-info.
+* scripts/Makefile.am: added mono-abi-info autofoo.
+
2010-07-16 Zoltan Varga var...@gmail.com
* configure.in: Remove the 'LLVM backend is experimental' warning.
Modified: mcs/tools/corcompare/ChangeLog
===
--- a/mcs/tools/corcompare/ChangeLog
+++ b/mcs/tools/corcompare/ChangeLog
@@ -1,3 +1,8 @@
+2010-08-05 Andr??s G. Aragoneses and...@lindenlab.com
+
+* mono-api-info.cs: Implemented new mode to show ABI.
+* Makefile: added mono-abi-info autofoo.
+
2010-04-16 C.J. Adams-Collier c...@colliertech.org
* mono-api-diff.cs: revived from the mono-2-2 branch and applied
Modified: mcs/tools/corcompare/Makefile
===
--- a/mcs/tools/corcompare/Makefile
+++ b/mcs/tools/corcompare/Makefile
@@ -2,7 +2,7 @@ thisdir = tools/corcompare
SUBDIRS =
include ../../build/rules.make
-ALL_PROGRAMS = mono-api-info.exe
+ALL_PROGRAMS = mono-api-info.exe mono-abi-info.exe
CECIL = ../../class/lib/net_2_0/Mono.Cecil.dll
@@ -43,3 +43,6 @@ dist-local: dist-default
mono-api-info.exe: $(APIINFO_SOURCES)
$(CSCOMPILE) -r:$(CECIL) -out:$@ $^
+
+mono-abi-info.exe: $(APIINFO_SOURCES)
+$(CSCOMPILE) -r:$(CECIL) -d:ABI -out:$@ $^
Modified: mcs/tools/corcompare/mono-api-info.cs
===
--- a/mcs/tools/corcompare/mono-api-info.cs
+++ b/mcs/tools/corcompare/mono-api-info.cs
@@ -29,6 +29,9 @@ namespace CorCompare
if (args.Length == 0)
return 1;
+AbiMode = false;
+SetAbiMode ();
+
AssemblyCollection acoll = new AssemblyCollection ();
foreach (string fullName in args) {
@@ -45,6 +48,14 @@ namespace CorCompare
doc.WriteTo (writer);
return 0;
}
+
+[System.Diagnostics.Conditional (ABI)]
+private static void SetAbiMode ()
+{
+AbiMode = true;
+}
+
+internal static bool AbiMode { get; private set; }
}
public class Utils {
@@ -211,7 +222,7 @@ namespace CorCompare
if (string.IsNullOrEmpty (t.Namespace))
continue;
-if ((t.Attributes
TypeAttributes.VisibilityMask) != TypeAttributes.Public)
+if (!Driver.AbiMode ((t.Attributes
TypeAttributes.VisibilityMask) != TypeAttributes.Public
[Mono-dev] [PATCH] Fix mono-2-6 build
Hello.
I would like to propose this 2 patches for review, to fix the mono-2-6
branch. In LindenLab we use Debian Etch, and were having 2 issues
building mono 2.6.7:
1) Fix for first patch: avoiding the use of 'var' (Etch has mono 1.9):
http://monobin.com/__m138c04d6
2) Fix for TimeZoneInfo.cs in the NET_2_1 profile:
http://monobin.com/__m73a1fc74
Ok to push?
Thanks,
Andres
--
diff --git a/mcs/mcs/decl.cs b/mcs/mcs/decl.cs
index dc790d8..cd59d49 100644
--- a/mcs/mcs/decl.cs
+++ b/mcs/mcs/decl.cs
@@ -625,7 +625,7 @@ namespace Mono.CSharp {
// Both are private and share same parent
//
if (al == AccessLevel.Private) {
- var decl = mc.Parent;
+ DeclSpace decl = mc.Parent;
do {
same_access_restrictions = TypeManager.IsEqual (decl.TypeBuilder, p_parent);
} while (!same_access_restrictions !decl.IsTopLevel (decl = decl.Parent) != null);
diff --git a/mcs/class/System.Core/System/TimeZoneInfo.cs b/mcs/class/System.Core/System/TimeZoneInfo.cs
index 632227e..3206430 100644
--- a/mcs/class/System.Core/System/TimeZoneInfo.cs
+++ b/mcs/class/System.Core/System/TimeZoneInfo.cs
@@ -133,7 +133,7 @@ namespace System
#endif
private AdjustmentRule [] adjustmentRules;
-#if !MONOTOUCH
+#if !MONOTOUCH !NET_2_1
static RegistryKey timeZoneKey = null;
static bool timeZoneKeySet = false;
static RegistryKey TimeZoneKey {
@@ -309,7 +309,7 @@ namespace System
//FIXME: this method should check for cached values in systemTimeZones
if (id == null)
throw new ArgumentNullException (id);
-#if !MONOTOUCH
+#if !MONOTOUCH !NET_2_1
if (TimeZoneKey != null)
{
RegistryKey key = TimeZoneKey.OpenSubKey (id, false);
@@ -350,7 +350,7 @@ namespace System
}
#endif
-#if !MONOTOUCH
+#if !MONOTOUCH !NET_2_1
private static TimeZoneInfo FromRegistryKey (string id, RegistryKey key)
{
byte [] reg_tzi = (byte []) key.GetValue (TZI);
@@ -518,7 +518,7 @@ namespace System
{
if (systemTimeZones == null) {
systemTimeZones = new ListTimeZoneInfo ();
-#if !MONOTOUCH
+#if !MONOTOUCH !NET_2_1
if (TimeZoneKey != null) {
foreach (string id in TimeZoneKey.GetSubKeyNames ()) {
try {
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] - optimization for System.Xml.XmlNode::SelectSingleNode
El 10/05/10 21:06, tom hindle escribió: On Mon, 2010-05-10 at 19:28 +0100, Alan McGovern wrote: Why would a c-cast be so much slower than an 'as' cast? Surely they should be equivalent or the c-cast should be faster. sorry bad terminology... I meant syntactically c-style cast not an actual c-cast. I wasn't sure the C# name for it, maybe it called a prefix cast? I think the correct terminology is static cast vs dynamic cast because this is the way it's called in C++ (some time ago I liked to called the latter safe cast). That being said, I second Alan statement (or, question, to be more correct). And I think a dynamic cast shouldn't be used ever if you're not checking for null later (otherwise you're replacing the InvalidCastException chance with a NullReferenceException chance, which is much worse, uglier, and more incorrect). Regards, Andrés -- ___ 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 trunk on FreeBSD
So the configure script is missing the check for Bash? Maybe we should add something like http://lists.freedesktop.org/archives/xorg/2008-March/033417.html Regards El 10/02/10 12:27, pablosantosl...@terra.es escribió: Up and running! :-) On 10/02/2010 10:28, Robert Jordan wrote: On 10.02.2010 00:29, pablosantosl...@terra.es wrote: Using gmake it went much further but... Creating the per profile list ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources ... ./../../tools/gensources.sh net_2_0_System.ServiceModel.Web.dll.sources ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources env: bash: No such file or directory You need bash. Look at /mcs/tools/gensources.sh. 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] Version bump
Ok to commit?: http://monobin.com/__m15732ad4 (People using the latest 2-4 branch should be able to run apps which require mono = 2.4.2 , such as MonoDevelop.) Thanks, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Uri.LocalPath is not correct when path contains an '@' character
Can any System.Uri author/maintainer take a look at my patches in: https://bugzilla.novell.com/show_bug.cgi?id=533572 Thanks, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Coding guidelines nitpicks
Miguel de Icaza wrote: Hello, 1) Casting: which one is correct? a) x = ((int)GetPropertyValue ()).ToString (); b) x = ((int) GetPropertyValue ()).ToString (); No strong opinion on the space after the cast. 2) Generics: which one is correct? a) x = new Listint (); b) x = new List int (); No space before the generic Would you mind updating the Wiki? Done. Any other opinions on casts? Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.4 Preview Packages for Debian/Unstable (now also for AMD64)
Grzegorz Sobanski wrote: * Mirco Bauer mee...@debian.org [2009-05-22 21:36]: I still lack positive feedback btw! Do the packages work for you? As in does the upgrade work without any issues and does your software still work with the new packages? Ubuntu jaunty, no problems upgrading. All software seems to work fine. Although those packages were removed: libmono-corlib2.1-cil libmono-system2.1-cil mono-2.0-runtime mono-common mono-jit mono-smcs because they are only in 2.0.1 in repository. So no smcs is available in those pacages. Is it delayed for a later packages? I think that now smcs is built in the moonlight tree, so I believe it will evolve to a moonlight-devel-sdk package... Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Coding guidelines nitpicks
I've found two cases which are not mentioned in the Mono Coding Guidelines [1]: 1) Casting: which one is correct? a) x = ((int)GetPropertyValue ()).ToString (); b) x = ((int) GetPropertyValue ()).ToString (); 2) Generics: which one is correct? a) x = new Listint (); b) x = new List int (); Thanks, Andres [1] http://www.mono-project.com/Coding_Guidelines -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Andrés -- Index: class/corlib/Makefile === --- class/corlib/Makefile (revision 131333) +++ class/corlib/Makefile (working copy) @@ -25,6 +25,12 @@ corlib_flags = -unsafe -nostdlib LOCAL_MCS_FLAGS = -nowarn:612,618 -d:INSIDE_CORLIB +# this hack will be dropped once we get this working: +# http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +ifdef MOON_A11Y_INTERNAL_HACK + MCS_FLAGS += -define:MOON_A11Y_INTERNAL_HACK +endif + # System.IO/DirectoryInfoTest.cs needs Mono.Posix TEST_MCS_FLAGS = -debug+ -debug:full -nowarn:168,219,618,672 -unsafe -r:$(topdir)/class/lib/$(PROFILE)/Mono.Posix.dll -define:MONO_DATACONVERTER_STATIC_METHODS Index: class/corlib/Assembly/AssemblyInfo.cs === --- class/corlib/Assembly/AssemblyInfo.cs (revision 131333) +++ class/corlib/Assembly/AssemblyInfo.cs (working copy) @@ -92,3 +92,12 @@ [assembly: InternalsVisibleTo (System.Net, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Runtime.Serialization, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] #endif + +#if NET_2_1 + +// this hack will be dropped once we get this working: +// http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading + MOON_A11Y_INTERNAL_HACK + + [assembly: InternalsVisibleTo (MoonAtkBridge, PublicKey=002404809400060200245253413100040100010071eb6c5575529cbf7244f7a6ea056284f9eae03bcff2cc132c9c490ab309eab0b56bce449df503d9c0a81e520585cdbe70e2fb90434bac04fa6222a80098b7a1a7b3af991a412324bb4325f6b865bb64ebf6d1c206d5732ddfbc70a7389ee53e0c246e3279741ad00503e49842e19bf37b198b402126cb3689c2ea6496a47cb4)] +#endif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
Andrés G. Aragoneses wrote: This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Patch updated. Index: class/corlib/Makefile === --- class/corlib/Makefile (revision 131333) +++ class/corlib/Makefile (working copy) @@ -25,6 +25,12 @@ corlib_flags = -unsafe -nostdlib LOCAL_MCS_FLAGS = -nowarn:612,618 -d:INSIDE_CORLIB +# this hack will be dropped once we get this working: +# http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +ifdef MOON_A11Y_INTERNAL_HACK + MCS_FLAGS += -define:MOON_A11Y_INTERNAL_HACK +endif + # System.IO/DirectoryInfoTest.cs needs Mono.Posix TEST_MCS_FLAGS = -debug+ -debug:full -nowarn:168,219,618,672 -unsafe -r:$(topdir)/class/lib/$(PROFILE)/Mono.Posix.dll -define:MONO_DATACONVERTER_STATIC_METHODS Index: class/corlib/Assembly/AssemblyInfo.cs === --- class/corlib/Assembly/AssemblyInfo.cs (revision 131333) +++ class/corlib/Assembly/AssemblyInfo.cs (working copy) @@ -91,4 +91,12 @@ [assembly: InternalsVisibleTo (System.Windows, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Net, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Runtime.Serialization, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] + +// this hack will be dropped once we get this working: +// http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +#if MOON_A11Y_INTERNAL_HACK + [assembly: InternalsVisibleTo (MoonAtkBridge, PublicKey=002404809400060200245253413100040100010071eb6c5575529cbf7244f7a6ea056284f9eae03bcff2cc132c9c490ab309eab0b56bce449df503d9c0a81e520585cdbe70e2fb90434bac04fa6222a80098b7a1a7b3af991a412324bb4325f6b865bb64ebf6d1c206d5732ddfbc70a7389ee53e0c246e3279741ad00503e49842e19bf37b198b402126cb3689c2ea6496a47cb4)] #endif + +#endif + ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
Andrés G. Aragoneses wrote: Andrés G. Aragoneses wrote: This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Patch updated. As already explained in moon-list, this is needed because glib-sharp and atk-sharp (which will now be merged in one assembly called MoonAtkBridge) access some Marshaling API which is not public anymore in the 2.1 profile. We're also looking at generating spec files for the monolinker to consume, in order for it to not strip the API we need, but this will come later. Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] LinkedList fix for Remove()
Hey, I attached a patch to this bug: https://bugzilla.novell.com/show_bug.cgi?id=481621 Could someone review? Thanks, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Have you opened bugs on their bug tracking systems? If yes, this discussion should be placed there. If not, you should open them, and provide patches (maybe they didn't do it on purpose, and would be very grateful of someone trying to remove workarounds/hacks from their code). Regards, Andrés Lucas Meijer wrote: Hey, Our team has been busy porting some unit testing related frameworks to mono. porting is probably not the right word, it's mostly creating repro cases of mono bugs, reporting them, and waiting for them to be fixed. (Which happens fast by the way. Thanks!) So far we're looking at NInject, Moq and xUnit. There are / have been bugs in mono that prevent all of these projects from running. Most of them are valid mono bugs, nothing special here. In addition to real mono bugs, there's also the fact that many of these frameworks, use this commonly used trick: FieldInfo remoteStackTraceString = typeof(Exception).GetField(_remoteStackTraceString, BindingFlags.Instance | BindingFlags.NonPublic); This doesn't work on mono, since in mono the private field storing the stacktrace is called remote_stack_trace. This issue has been reported before as issue 425512 ( https://bugzilla.novell.com/show_bug.cgi?id=425512 ) One could argue, and the reason for the wontfix status of the issue does so, that these folks rely on undocumented internals. They shouldn't do it, and Mono shouldn't rename it's own private field to match that of the CLR. However, in the real world(tm), this prevents many projects from running on Mono unmodified. I would like to argue that in this specific case, where the (percieved by me, maybe incorrectly) amount of work for mono to change it's private fieldname to match that of the CLR, is a reasonable cost for enabling this quite frequently found in the wild trick of grabbing the internal stack trace of an exception. Maybe I'm underestimating the amount of work to rename the mono fieldname to match the clr one. If that's the case, please consider this message as another datapoint of three useful .net frameworks unable to run on mono unmodified. Here's a bit more info on the trick: Here is a bit more background on the trick: http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
I'm talking about bugs opened *against* the frameworks, not against Mono, because it's not a Mono bug. Andrés Stifu wrote: Hm yeah, he gave the link to the bug report (in the message you quoted), and it's obvious it's not been closed by mistake. And it's not about removing workarounds or hacks from Mono, the hacks would be in the programs working around the difference between .NET and Mono. :| knocte wrote: Have you opened bugs on their bug tracking systems? If yes, this discussion should be placed there. If not, you should open them, and provide patches (maybe they didn't do it on purpose, and would be very grateful of someone trying to remove workarounds/hacks from their code). Regards, Andrés ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Scott Peterson wrote: Any word on a wiki? If we don't use the mono-project one, on http://wik.is/ you can create one easily, and it turns out it's using Deki (powered by Mono) ;) Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Scott Peterson wrote: It sounds like the general reaction is cautiously favorable. New language features would be nice, but they would require a commitment to maintenance. As I see it, whether we are willing to invest ongoing effort in a feature depends on the strength of the feature. A sufficiently killer feature will motivate its own upkeep. So what is (are) the killer feature(s)? I would be interested in organizing a forum for proposing and discussing language features. If for no other reason than as an excuse to talk about language design with smart people. This forum could start as an informal bake-off of ideas and brainstorms. If momentum builds behind a particular feature, we could formalize a proposal for its inclusion in the compiler. This allows the exploration of many ideas without the looming specter of feature-creep. If other people are interested in geeking out over language features, I suggest we get ourselves a little organized. We could hold forth right here, on this list, or we could create our own Google Group. Bugzilla is maybe another option. Maybe. Thoughts? I really like this proposal. (Although I see why the people is worried about maintaining the features, this may be worth it because it may be an interesting incubator of proposals to Anders H. for next versions, no?). I have a big pile of ideas that I was gathering in order to blog as a 'C# wishlist', so I could contribute them to this discussion. My suggestion is to use the wiki hosted in mono-project. We could create a page with an index with links to all ideas (sub-pages). Every idea could be voted up (+1) or down (-1) by the community, giving comments or feedback about the vote, maybe causing the idea to mutate. And after some time, the best ideas could be then created in Bugzilla and tracked there... Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] 2.4 Preview - problem with reproducing a regression
Leszek Ciesielski wrote: On Wed, Feb 4, 2009 at 11:09 AM, Leszek Ciesielski skol...@gmail.com wrote: Hi, I'm getting a ERROR:mini-trampolines.c:122:mono_magic_trampoline: assertion failed: (vt) when running my NUnit tests on Mono 2.4 Preview 1 on Windows XP 32bit. However, there's not additional output to help pin down the problem, and the fact that the code that breaks uses an obfuscated external library (CoreLab.Oracle.dll) does not make things easier. What can I do to track down the regression (yes, this does work on 2.0, and on 2.4 Preview (and svn head) on Linux)? This no longer happens with Preview 2 :-) It's random: https://bugzilla.novell.com/show_bug.cgi?id=472654 Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 Preview 1...
Hey Thomas, This one is a regression because the workaround is to use the old RegExp engine: https://bugzilla.novell.com/show_bug.cgi?id=470827 Sorry, we haven't had time yet to isolate the issue into a testcase. But it's easy to reproduce with the steps mentioned in the bug. Regards, Andrés Thomas Wiest wrote: Hey Everyone, We've just released Mono 2.4 Preview 1 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.4 here: https://bugzilla.novell.com/buglist.cgi?query_format=advancedclassification=Monotarget_milestone=2.4.xorder=bugs.bug_status%2Cbugs.bug_severity The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you add [Regression] to the beginning of the summary of the bug, then it is much more likely your bug will get fixed. Please help the Mono team to make 2.4 the best ever. Thanks! Mono QA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FileSystemWatcher on Linux
Hey Pablo, do a quick search on bugzilla, there are some open bugs about FSW, maybe you're facing them ;) Andrés pablosantosl...@terra.es wrote: Hi, There's a variable in InotifyWatcher named new_name_needed which is not used since revision 63309 and avoids renames to work correctly. When a move a file (rename) I get a moved_from and moved_to pair of events, but they are not correctly processed since moved_to always have new_name_needed to false. pablosantosl...@terra.es escribió: Ok, a bit of more info I set the directory to be /home/pablo but I'm only getting rename notifications *inside* /home/pablo/somethingelse, never when the ops are directly in /home/pablo I'll take a look at the code pablo pablosantosl...@terra.es escribió: Hi, I'm running a test with FileSystemWatcher on linux. My problem is: - I never get rename events but removed and added event pairs - I also get a huge number of modified events for files I think no one is touching (I'm seeing that on a huge number of source files on my workspace, files that are not being edited (unless they're being acessed by beagle ... :-P, so just forget about this one) Also, one question: Inotify is able to *correctly* report moved files, isn't it? I mean, not like on windows where the *sad* FileSystemWatcher implementation is not able to track moved files, right? So, wouldn't it be better to modify the InotifyWatcher implementation to correctly fill moved events (I know it won't be the *standard* way, but it would be better, wouldn't it?) ___ Mono-osx mailing list mono-...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-osx ___ 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] Typed dataset serialization still failing in mono 2.0.1
You forgot the attachment.
But let's rather create a bug, and attach a simple .cs file that exposes
the problem.
Thanks,
Andrés
marcos b wrote:
I didn't added those things because the bug can be reproduced very easily.
You need to create one dataset in vs2008 or vs2005, add one datatable, and
one column to this datatable and try to serialize it using the test that I
provided.
I encapsulated this test in a project that have attached in this message.
Try it.
Thanks Rafael.
Rafael Teixeira wrote:
The stack trace for the exception, the generated typed dataset class, and
your blob binary-serialized by MS runtime, would increase immensely the
chance we can discover what is happening. If you already added that to
your
bug case citing the bug number here also helps.
:)
On Wed, Nov 26, 2008 at 9:37 AM, marcos b [EMAIL PROTECTED] wrote:
I have an extremelly simple typed dataset generated using vs 2005 with
one
datatable with a simple column
When I try to run this test I get the following exception (I get the same
error using vs 2008 typed dataset)
System.ArgumentException : The given name 'MyDataTable' matches atleast
two
namesin the collection object with different namespaces
[Test]
public void SimpleTypedDataSetSerialization()
{
MyDataSet ds = new MyDataSet();
BinaryFormatter f = new BinaryFormatter();
MemoryStream ms = new MemoryStream();
f.Serialize(ms, ds);
ms.Position = 0;
ds = (MyDataSet)f.Deserialize(ms);
}
It's extremelly important for me to have the possibility of serializing
and
deserializing typed datasets for the migration of my application to the
mono
platform. So I would be very happy to know if this issue is going to be
addressed soon.
I have posted the same issue a couple of months, even a file the bug in
mono
bugzilla but, but nothing happened.
The idea of the mono platform is great, but no supporting simple code
like
the posted above can make someone to give up porting his .net application
to
the linux world.
Thanks in advance
--
View this message in context:
http://www.nabble.com/Typed-dataset-serialization-still-failing-in-mono-2.0.1-tp20699241p20699241.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
--
Rafael Monoman Teixeira
---
I myself am made entirely of flaws, stitched together with good
intentions.
Augusten Burroughs
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
http://www.nabble.com/file/p20705237/TypedDataSetTest.rar
TypedDataSetTest.rar
http://www.nabble.com/file/p20705237/TypedDataSetTest.rar
TypedDataSetTest.rar
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
This is awesome news. However, this doesn't change the fact that a Windows developer will have to remember to change the makefiles if she contributes a patch with files included/removed (and a Win developer usually doesn't know how to do this as well). But if you write your tool to be able to do the opposite thing as well, you could just call it in the MSbuild files in order to change them as a part of the build, right? If this can be done, even the non-Windows developers that aren't used to AutoTools will benefit from it when xbuild is finished. Andrés Jonathan Chambers wrote: Paolo, Thanks for the response. On Thu, Nov 13, 2008 at 9:01 AM, Paolo Molaro [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 11/11/08 Jonathan Chambers wrote: 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. So this is already done by you, AFAIK. I even add new .c files to the MSVC build files (when I remember about it:). it). Another option is to moved to MSBuild/xbuild for the class libraries. I think you're taking it from the wrong side. There is no need to move the Linux build system to xbuild or whatever. As other have mentioned, the build files can be generated from the .sources files quite easily. You can write the conversion script in perl or even C# and we can have rules in the makefiles to run them automatically when the source files are modified. AFAIK, the only two things missing are: 1) a windows developer that volunteers writing the script and MSBuild/xbuild files. I have started writing this tool in C#. It correctly generates a csproj file from the Makefile and the library.dll.sources files. It already works on most assemblies in mcs/class. I'm working on generating the corresponding NUnit projects as well.I'll hopefully post something in a couple of days. 2) a windows developer that documents the thing for other windows developers so they are not tricked into going down the cygwin route anymore and just click on the right buttons instead. I can also look into this once a full build is working. Not to mention the fact the xbuild needs a good bit of work. As you see we only need some windows developer to step up to the plate. I suggest starting to build the complete assemblies first, without going into the details of bootstrapping. This should take an hour or two. And then we (mostly hari I guess) can help with the bootstrap details. So, who volunteers? I would appreciate any help offered by others ;-). Hacking on xbuild (including contributing tests) would be expecially useful... Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with Probing Path
So maybe it's time to reopen https://bugzilla.novell.com/show_bug.cgi?id=314478 Charlie Poole wrote: OK, I can run if I set MONO_PATH to ./lib but that still doesn't explain why the config entry is ignored AFAICS. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Poole Sent: Tuesday, November 11, 2008 12:17 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Problem with Probing Path Hi All, I was getting strange failures with the latest install of nunit.exe under Mono - no message, it just goes away. I finally figured out that some of my nunit assemblies were not being found. For this release, I moved the nunit library assemblies to a lib subdirectory, which I put on the probing path using the config. When I copy all the assemblies into the same directory as nunit.exe, it works OK. But when they are in the lib directory, the assemblies are not found. Here's what is in my config: assemblyBinding xmlns=urn:schemas-microsoft-com:asm.v1 probing privatePath=lib;addins / /assemblyBinding Any thoughts as to why this doesn't work? Carlie ___ 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] System_Runtime_Remoting-2.0 failure
Marc Christensen wrote: Hi everyone, Pleas take a look at the following error: http://mono.ximian.com/monobuild/builds/HEAD/sles-10-i586/mono/118193/logs/test-System_Runtime_Remoting-2.0.log This failure started happening between -r116743:117186 The large difference in revisions means that there were a lot of checkins which could have caused the error. The output of 'svn log -r116743:117186' is about 3k lines long. The people who checked in and made a log entry are during that time: ajorg alanmc andreia atsushi bgmerrell btaylor cachen calberto cedricv dick ebutler fejj gert gonzalo jbevain jonpryor jpobst knocte kumpera lewing lluis lupus martin mcarrion mgorse mhabersack mhutch miguel mkestner mkrueger mprobst nestor ngao pjohanson raywang rolf sandyarm spouliot stephane stshaw toshok twiest zoltan If your name is on the list, please take time to see if you were the one that caused the breakage. Hey Marc, I checked my commits (knocte) and they were all in uia2atk module. Most likely my teammates (btaylor, bgmerrell, cachen, ngao, mcarrion, stshaw, sandyarm, raywang) and other committers outside mono mcs are in the same situation as I already noticed on IRC. Thanks, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 LiveCD
[EMAIL PROTECTED] wrote: Hi folks, I've just downloaded and played around a little bit with Mono 2.0 LiveCD. Some comments/suggestions: - The included MonoDevelop doesn't come with the debugger - The mdb command is not available Since it's the first thing a lot of newcomers are going to see about Mono, I'd strongly recommend to include the debugger, now that it's available and announced at Miguel's post. Regards, pablo The debugger Addin for MD is going to be included in the upcoming MD new release (currently lives in trunk). I guess the LiveCD has the stable MD. Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re flection not working with System.Runtime.Remoting.Channels.CoreChannel
Mathflair wrote: I am having a problem with the following line of code: Type coreChannelType = binaryServerFormatterSinkProvider.GetType().Assembly.GetType(System.Runtime.Remoting.Channels.CoreChannel); This returns a null reference pointer. I can't figure out why this would happen. My only guess is that the reflection libraries are not properly grabbing the class since it is an internal class. Any help on getting this working would be great. Mono only follows public APIs, so if your code relies on internal bits, it won't work outside MS.NET. Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unable to build MD 1.9 against RC 1
Paul wrote: Hi, I'm in the process of rebuilding a number of packages for Fedora and seem to have hit a snag with MD 1.9 and Mono 2.0 RC 1. It could be a mono problem or an MD one, so I'll report it here then if needs be BZ it against MD or mono. First the minor one Parser/mcs/mcs/attribute.cs is giving a lot of warnings (all CS0618) that 'System.Reflection.Emit.UnmanagedMarshal' is obsolete and 'An alternate API is available: Emit the MarshalAs custom attribute instead'. This warning also appears in generic.cs and class.cs Now the stopper Parser/mcs/mcs/class.cs(5396,33): error CS1061: Type 'System.Reflection.Emit.MethodBuilder' does not contain a definition for 'SetGenericMethodSignature' and no extension method 'SetGenericMethodSignature' of type 'System.Reflection.Emit.MethodBuilder' could be found (are you missing a using directive or an assembly reference?) Using RC 1 (build from the tarballs) and MD 1.9 (from the unstable tarball). MD 1.9-5 is already in Fedora Rawhide, so it seems this problem may be more a mono one than MD. TTFN Paul This has already been fixed in the 1.9 branch, the commit: http://lists.ximian.com/pipermail/mono-patches/2008-September/126919.html So it's likely you have an old tarball. Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF in Moonlight
Miguel de Icaza wrote: How to do 2) properly then? Should we simply move those assemblies to mcs, and develop there, or continue to develop in olive, and merge changes when we feel confident into mcs? I'd rather simply move them, but then we would have unstable assemblies in mcs. Should we apply the same policy we apply for Cecil, that is not exposing it to the compiler without using a pkg? Lets move the assemblies into mcs. There are plenty of pros and cons to various other approaches (like stabilizing Olive and depending on it) but it will be cumbersome and will add another dependency. We were discussing about a similar issue inside the UIA team. Can we then take a similar approach for our assemblies in olive when our release dates arrive? Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Security: trivial fixes for XmlDsig transforms
Gert Driesen wrote: Perhaps we should include a table that clearly lists the bracing style we prefer: Namespace same line Types same line Methodsnew line Constructors new line (?) Properties same line Anonymous Methods same line (?) Anonymous Typessame line (?) Control Blocks same line It would be interesting to have such a recapitulating table inside the wiki. However such table, if/when existing, should not be interpreted as must be changed at first opportunity ;-) No, but at least we'd have something indisputable to redirect committers to for new sources. Can someone with write access add this to the wiki? Done. Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HEADS UP: Linear IR branch merge
Zoltan Varga wrote: [...] In case anyone wants to revert their tree to before the merge, the before merge revision is r108475. (Just FYI) It's a shame because, at that revision, there's an mcs bug that prevents you from compiling MonoDevelop: Exception caught by the compiler while compiling: Block that caused the problem begin at: ./MonoDevelop.SourceEditor/SourceEditorWidget.cs(253,22): Block being compiled: [./MonoDevelop.SourceEditor/SourceEditorWidget.cs(269,64):,./MonoDevelop.SourceEditor/SourceEditorWidget.cs(278,25):] System.InvalidCastException: Cannot cast from source type to destination type. Internal compiler error at ./MonoDevelop.SourceEditor/SourceEditorWidget.cs(253,22):: exception caught while emitting MethodBuilder [SourceEditorWidget::AddClass] Unhandled Exception: System.InvalidCastException: Cannot cast from source type to destination type. at Mono.CSharp.ConstantFold.BinaryFold (Mono.CSharp.EmitContext ec, Operator oper, Mono.CSharp.Constant left, Mono.CSharp.Constant right, Location loc) [0x0] at Mono.CSharp.Binary.DoResolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec, ResolveFlags flags) [0x0] at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Binary.DoResolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec, ResolveFlags flags) [0x0] at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Expression.ResolveBoolean (Mono.CSharp.EmitContext ec, Mono.CSharp.Expression e, Location loc) [0x0] at Mono.CSharp.If.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.ExplicitBlock.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach+CollectionForeachStatement.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.While.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach+CollectionForeach.ResolveLoop (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach+CollectionForeach+DisposableWrapper.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach+CollectionForeach.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.ExplicitBlock.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.ExplicitBlock.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.EmitContext.ResolveTopBlock (Mono.CSharp.EmitContext anonymous_method_host, Mono.CSharp.ToplevelBlock block, Mono.CSharp.Parameters ip, IMethodData md, System.Boolean unreachable) [0x0] I'll see if it's fixed in SVN, but then I have to stick with the linear-IR stuff merged so I maybe face unstability probs :/ (And this is not possible: ) svn up mcs svn up mono libgdiplus -r108475 (The reason: ) Corlib not in sync with this runtime: expected corlib version 68, found 69. Regards, Andrés On Tue, 2008-07-22 at 01:09 +0200, Zoltan Varga wrote: Hi All, Now that we have branched for mono 2.0, we would like to merge the work done on the linear IR branch to svn HEAD. The linear IR branch was created in 2005 October to explore some ideas on how to make our JIT simpler and how to make it generate better code. A lot of work has been put into the branch over the years, and now we are ready to merge it. Changes of this magnitude are never easy, so svn head might be a bit unstable for a few weeks as we work out the problems. Documentation for the new JIT and some benchmarks can be found at http://www.mono-project.com/Linear_IL I plan to do the merge tomorrow. Until then, please avoid checking in code to the mono/mini directory so as to not interfere with the merge. This is great news! Do we have a list of architectures that will be supported, and more importantly a list of architectures that will be broken when you do the merge? If I remember correctly, ARM, x86, x86-64, sparc, and itanium are ported already? Thanks -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HEADS UP: Linear IR branch merge
Andrés G. Aragoneses wrote: Zoltan Varga wrote: [...] In case anyone wants to revert their tree to before the merge, the before merge revision is r108475. (Just FYI) It's a shame because, at that revision, there's an mcs bug that prevents you from compiling MonoDevelop: Exception caught by the compiler while compiling: Block that caused the problem begin at: ./MonoDevelop.SourceEditor/SourceEditorWidget.cs(253,22): Block being compiled: [./MonoDevelop.SourceEditor/SourceEditorWidget.cs(269,64):,./MonoDevelop.SourceEditor/SourceEditorWidget.cs(278,25):] System.InvalidCastException: Cannot cast from source type to destination type. Internal compiler error at ./MonoDevelop.SourceEditor/SourceEditorWidget.cs(253,22):: exception caught while emitting MethodBuilder [SourceEditorWidget::AddClass] Unhandled Exception: System.InvalidCastException: Cannot cast from source type to destination type. at Mono.CSharp.ConstantFold.BinaryFold (Mono.CSharp.EmitContext ec, Operator oper, Mono.CSharp.Constant left, Mono.CSharp.Constant right, Location loc) [0x0] at Mono.CSharp.Binary.DoResolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec, ResolveFlags flags) [0x0] at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Binary.DoResolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec, ResolveFlags flags) [0x0] at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Expression.ResolveBoolean (Mono.CSharp.EmitContext ec, Mono.CSharp.Expression e, Location loc) [0x0] at Mono.CSharp.If.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.ExplicitBlock.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach+CollectionForeachStatement.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.While.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach+CollectionForeach.ResolveLoop (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach+CollectionForeach+DisposableWrapper.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach+CollectionForeach.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Foreach.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.ExplicitBlock.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.ExplicitBlock.Resolve (Mono.CSharp.EmitContext ec) [0x0] at Mono.CSharp.EmitContext.ResolveTopBlock (Mono.CSharp.EmitContext anonymous_method_host, Mono.CSharp.ToplevelBlock block, Mono.CSharp.Parameters ip, IMethodData md, System.Boolean unreachable) [0x0] I'll see if it's fixed in SVN... Arghh, same issue with gmcs from SVN. Marek, are you already aware of this issue or do you want me to file a bug..? Thanks, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] gmcs bug affecting MD from SVN (was: Re: HEADS UP: Linear IR branch merge)
Marek Safar wrote: Hello, Arghh, same issue with gmcs from SVN. Marek, are you already aware of this issue or do you want me to file a bug..? No, please fill a bug report. Thanks for your reply Marek!: https://bugzilla.novell.com/show_bug.cgi?id=412595 I'll try to cook a smaller testcase if I have enough time. FYI: checkout monodevelop rev 108914 as a workaround to this problem. Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HEADS UP: Linear IR branch merge
Andrés G. Aragoneses wrote: Andrés G. Aragoneses wrote: Zoltan Varga wrote: [...] In case anyone wants to revert their tree to before the merge, the before merge revision is r108475. (Just FYI) It's a shame because, at that revision, there's an mcs bug that prevents you from compiling MonoDevelop: [...] Zoltan, FYI: Running the version of MD (r108914) that doesn't generate the gmcs bug, with Mono SVN, I've been getting wierd behaviours: random NRE exceptions during MonoDevelop usage (note: I'm using 64bits arch). Reverting to mono r108475 fixed the problems. Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Let's not compare exception messages in nunit tests
Atsushi Eno wrote: Hey guys, I have seen a lot of bad NUnit tests that unnecessarily compare exception messages. They are wrong not only because they fail in non-English Windows environment but also because those tests will fail when Microsoft improves the messages. Furthermore, it blocks possible message translation in the future. They have been blocking me from checking NUnit test sanity. And thanks to that, now we actually have a lot of wrong compatibility assumptions in our own tests. (I don't say incompatibility is bad but they do not have to be asserted unnecessarily.) Let me repeat: let's not compare any localizable strings. Atsushi: do you know if there's a way of switching to the standard language as a fallback (en-US I presume) in order to fix these kind of tests in non-English Win environments? Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Forums added to Mono Website
jhill wrote: Web-based forums for Mono discussions have been added at http://www.go-mono.com/forums As you know, most active Mono community members participate in on-line discussions through our mailing lists; however, many Mono users have expressed a preference for web forums based discussions. In order to address this demand for an official forums for Mono, while keeping the community engaged in our mailing lists, we have embedded nabble.com into our site to create a bridge between the two groups. So, you can now use whichever method you prefer participate in the community. In order to post through the web interface, you will need to have a Nabble account. If you are already subscribed to this and/or other mailing lists, it would be preferable to register your Nabble account with your subscribed address. Alternatively, if you decide to create your account under a different address, you also have the option to modify your Nabble account settings to link in your other address(es). --Joseph This is great news! Just a question and a suggestion: - Does the integration effort include any open source code that we can reuse? (Sorry if I'm missing the point, I don't know how Nabble works.) I ask it because I only know other alternative for doing this type of synchronization, and I'd love to know another one (and more points if it's Mono-based!). - I would add some more forums to the system: the Gendarme mailing-list, and the Banshee mailing-list (well, this one is not Mono itself, but I think they have forums that are not synchronized, so maybe it's interesting for them to switch and start using this). Regards, Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CS0019 for value type != null
Marek Safar wrote: Hello Casey, I've noticed that on a recent SVN build of mono, I get a CS0019 error if I try to compare a value type against null. E.g.: DateTime dt; if (dt != null) Console.WriteLine(dt); As far as I can tell, this is the correct behavior, since a value type can't be null. I'm concerned, though, because this behavior seems to have been introduced recently in SVN, AND it looks like MS's compiler doesn't reject this statement (well, I haven't seen it accept it, but this is existing code which apparently compiles fine under Visual Studio). This code compiles correctly with the SVN HEAD version. IIRC this was a design flaw that some mono devs didn't agree about, right? Is gmcs compiler at least reporting a warning about this? If not, it would be interesting to do so although MS doesn't do it (in the past I remember fixing some bugs in a MS.NET project because gmcs reported more warnings than csc!). Regards, Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Support for heads with absolute URLs in Monologue
I didn't find a product for Monologue on BNC so here's the patch. Please
review, can I commit?
Thanks,
Andres
--
Index: ChangeLog
===
--- ChangeLog (revision 99902)
+++ ChangeLog (working copy)
@@ -1,5 +1,14 @@
2008-03-11 Andrés G. Aragoneses [EMAIL PROTECTED]
+ * worker/monologue-worker.cs: Support absolute URLs for heads,
+ use String.Empty instead of , and fix some indentation.
+ * worker/default.tpl: move local path for heads into the .cs
+ file in order to support absolute URLs.
+ * worker/Makefile: Use gmcs, since now we use String.IsNullOrEmpty
+ and Uri.IsAbsoluteUri.
+
+2008-03-11 Andrés G. Aragoneses [EMAIL PROTECTED]
+
* worker/bloggers.xml: Corrected the accent (HTMLish).
2008-03-11 Andrés G. Aragoneses [EMAIL PROTECTED]
Index: worker/monologue-worker.cs
===
--- worker/monologue-worker.cs (revision 99902)
+++ worker/monologue-worker.cs (working copy)
@@ -206,6 +206,20 @@
static string error_msg = div class='ircnick' style='color:red'Error retrieving/loading feed/div;
static string date_error_msg = div class='ircnick' style='color:red'Invalid dates in feed/div;
static string error_img = img src='images/error.png' alt='Error retrieving/loading feed';
+
+ static string ProcessHeadEntryAndReturnUrl(string head)
+ {
+ string localHeadsPath = images/heads/;
+
+ if (String.IsNullOrEmpty(head))
+ head = none.png;
+
+ if (!((new Uri(head, UriKind.RelativeOrAbsolute)).IsAbsoluteUri))
+ head = localHeadsPath + head;
+
+ return head;
+ }
+
static void Render ()
{
Template tpl = new Template(default.tpl);
@@ -216,16 +230,13 @@
tpl.setField (BLOGGER_ERROR_IMG, b.Error || b.DateError ? error_img : );
tpl.setField (BLOGGER_URL, b.HtmlUrl.ToString ());
tpl.setField (BLOGGER_NAME, b.Name);
-
- if (b.Head != null)
-tpl.setField (BLOGGER_HEAD, b.Head);
- else
-tpl.setField (BLOGGER_HEAD, none.png);
+ tpl.setField (BLOGGER_HEAD, ProcessHeadEntryAndReturnUrl(b.Head));
+
if (b.IrcNick != null)
- tpl.setField (BLOGGER_IRCNICK, b.IrcNick);
-else
- tpl.setField (BLOGGER_IRCNICK, );
+tpl.setField (BLOGGER_IRCNICK, b.IrcNick);
+ else
+tpl.setField (BLOGGER_IRCNICK, String.Empty);
tpl.setField (BLOGGER_RSSURL, b.RssUrl);
@@ -251,10 +262,7 @@
else
tpl.setField (ENTRY_PERSON_IRCNICK, );
- if (bl.Head != null)
- tpl.setField (ENTRY_PERSON_HEAD, bl.Head);
- else
- tpl.setField (ENTRY_PERSON_HEAD, none.png);
+ tpl.setField (ENTRY_PERSON_HEAD, ProcessHeadEntryAndReturnUrl(bl.Head));
tpl.setField (ENTRY_PERSON_URL, bl.HtmlUrl.ToString());
} else {
Index: worker/default.tpl
===
--- worker/default.tpl (revision 99902)
+++ worker/default.tpl (working copy)
@@ -29,7 +29,7 @@
div class=entry
div class=person-info
a href=@@ENTRY_PERSON_URL@@
- img class=face src=images/heads/@@ENTRY_PERSON_HEAD@@ alt=@@ENTRY_PERSON_IRCNICK@@/
+ img class=face src=@@ENTRY_PERSON_HEAD@@ alt=@@ENTRY_PERSON_IRCNICK@@/
br /br /
@@ENTRY_PERSON@@
br /@@ENTRY_PERSON_IRCNICK@@
@@ -68,7 +68,7 @@
h2Bloggers/h2
ul
!-- @@BLOGGER@@ --
-li@@BLOGGER_ERROR_IMG@@divimg class=head src=images/heads/@@BLOGGER_HEAD@@ alt=@@BLOGGER_IRCNICK@@ //div
+li@@BLOGGER_ERROR_IMG@@divimg class=head src=@@BLOGGER_HEAD@@ alt=@@BLOGGER_IRCNICK@@ //div
a href=@@BLOGGER_URLBLOGGER_NAME@@/a
div
a href=@@BLOGGER_RSSURL@@img src=images/feed.png alt=@@BLOGGER_IRCNICK@@ feed/a
Index: worker/bloggers.xml
===
--- worker/bloggers.xml (revision 99902)
+++ worker/bloggers.xml (working copy)
@@ -150,5 +150,9 @@
Blogger Name=Rusty Howell RssUrl=http://rustyhowell.blogspot.com/feeds/posts/default/-/mono?alt=rss; IrcNick=rusty/
Blogger Name=Calvin Gaisford RssUrl=http://calvinrg.blogspot.com/feeds/posts/default/-/mono?alt=rss; IrcNick=calvin Head=calvin.png/
Blogger Name=Sandy Armstrong RssUrl=http://automorphic.blogspot.com/feeds/posts/default?alt=rss; IrcNick=sandy Head=sandy.png/
- Blogger Name=Andres G. Aragoneses RssUrl=http://knocte.blogspot.com/feeds/posts/default?alt=rss; IrcNick=knocte /
+ Blogger Name= Andres G. Aragoneses
+ RssUrl = http://www.blogger.com/feeds/13199395/posts/summary/-/Mono?alt=rss;
+ IrcNick = knocte
+ Head= http://www.mono-project.com/files/5/54/Knocte.png;
+ /
/BloggerCollection
Index: worker/RSS.NET.dll
===
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: worker/Makefile
===
--- worker/Makefile (revision 99902)
+++ worker/Makefile (working copy)
@@ -1,4
Re: [Mono-dev] HttpListener and basic auth
Maciej Paszta wrote: Hello Guys, I'm developing standalone service provider that uses HttpListener to serve appropriate requests. I'm having difficulty using Basic Authentication (not to say that it doesn't work at all). I'm using Mono 1.2.6 and the following testcase was performed on Windows, MacOS and Linux: The expected result is that browser shows login window when one can enter username and password. Unfortunately it doesn't. Method AuthenticationSelector is not called at all and the program throws NullReference exception in line 52. The following code was tested on .NET 2.0 and there it works as supposed. Report the bug and attach the testcase: http://www.mono-project.com/Bugs Thanks, Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] AvoidBadAsCast Gendarme rule? (was: Re: [PATCH] The big as cast cleanup)
Miguel de Icaza escribió: I don't like to change working code unnecessarily just for your preference. I'd wait for another patch that removes any extra changes. I agree with Atsushi's statement, and also: Personally I like as operator which sometimes makes the sources more readable and kind enough for code completion depending on the editor/IDE. miguel. Hey Miguel, I don't agree :) Readability is a good thing, but not when it makes your code incorrect. Nobody should use as if afterwards there is not a check to see if the result is null or not. BTW, maybe this is a good candidate for a Gendarme rule? Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Program Option Parsing Library
Jay Logue escribió: Jonathan Pryor wrote: As for what Getopt::Long does... --foo --bar sets --bar as the value of the --foo argument. --bar --foo (i.e. no argument for --foo) generates the output: Option foo requires an argument I'm conflicted as to which is the better behavior. Yeah, that's a tough one. I probably lean towards the Getopt behavior as its easier to explain, e.g. if --foo takes a value, then whatever comes after it will be treated as a value, regardless of what it looks like. What about giving a warning (or a Y/N confirmation) if --foo receives as an argument a string that starts with - or --? Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Program Option Parsing Library
Jonathan Pryor escribió: Now how should localization be handled? Should it? If you head for l10n, please include a default option for every program (like --disable-l10n or something like that) in order to disable it completely (think of debugging cases or bugzilla reports :) ). Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Interprocess communication
I would rather use Remoting with IPC channels, in the managed side using Mono/.NET API's, and in the unmanaged side using Mono/.NET API's via [1]. Regards, Andrés [ knocte ] [1] http://www.mono-project.com/Embedding_Mono Justin Cherniak escribió: Unfortunately as far as I know there is no easy one off way to do this. That said, if you are communicating to an unmanaged process, I would assume it is a safe assumption to assume you are targeting a particular operating system. I can't help you much with *nix, but on windows, you have a number of options including: * COM * Shared memory * Window messages What exactly are you trying to do, I (or someone else) might be able to narrow it down to a clearer solution. Thanks, Justin On Dec 26, 2007 10:21 PM, FirstName LastName [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I'm currently trying to find a way to make 2 processes on the same machine talk. One process is managed while the other is unmanaged. How can I do this? Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono version numbering
Thomas Wiest escribió: Ernesto wrote: Euan MacInnes wrote: I would suggest that, rather than one version, Mono should split up it's packages differently. I have to agree. If we are talking about a on size fits all Mono distribution, no version number can be too descriptive. Exactly, so maybe we eliminate the confusion entirely and use a version number that has nothing to do with .Net. It seems to me that the whole problem that we are having is that we keep trying to imply our status with our version number, and people keep inferring wrong (as with Miguel's example of the guy asking when asp.net 2.0 would be done). Why don't we stop trying to imply our status through our version number? If we had a completely different numbering scheme, this wouldn't happen. For instance, we could do something like Ubuntu where we take the Year.Month.0 of the release. So, 1.2.6 would most likely be 7.11.0. 7.11.0 doesn't make any sense to a .Net person. Therefore they will have to go read the release notes and other documentation to find out exactly what is in this version. Bug fix only releases could be 7.11.1, .2, etc. The other nice thing about this is since Miguel started working on Mono in 2000, it would be a close approximation of how many years have been put into the release (and how mature the project is). If the version is going to imply anything, it should imply the maturity. :) Even if we decided to have individual version for each component, we should still have a version number that encompasses the whole. Hey! I think that solution rocks! Mono global version number could have something like 7.11.2, and each specific component could have a version number that matches the progress of it to target .NET features. For example: Mono 7.11.2 released! It contains: - WinForms 1.8 - ADO.NET 1.9 - Olive 0.8 (which includes .NET 3.0 specific stuff): * WCF (80% complete) * WCS (40% complete) - LINQ 0.7 (.NET 3.5 stuff) Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoSummit: Planning the Sessions
Mads Bondo Dydensborg escribió: fredag 26 Oktober 2007 skrev Miguel de Icaza: Hey folks, Am looking for ideas for topics that developers would be interested in hearing about at the Mono Summit. I would be happy to hear about debugging applications with mono, the state of the debugger, etc. Also, in relation to this, debugging mono itself: when you _really_ think what you observe is not a bug in your program, how to go about checking mono against the C# standard, MS implementation, whatever. I would love that BoF! Also I am thinking about another one that could explain how to run the unit tests successfully across many operating systems. I'm interested in contributing some patches but first I have to understand how to launch these tests in MS.NET using Cygwin, in order to see if my unit tests are correct or not. I don't have enough time to dive into the loop of test-error-test-error to find it out (maybe this could be a good section in the already existing planned activity by Marcos Cobeña.. I don't know). Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] New language discussion?
Can someone tell the latest state-of-affairs from the recent(?) languages discussion to be used in Bugzilla in the future? I proposed a big section about Mono on the discussion page, but I think there has been no more news about this (neither anyone has updated the official part page to include the Mono section). Regards, Andrés [ knocte ] -- P.S.: In case anyone asks, I am talking about this: http://wiki.mozilla.org/Bugzilla_Talk:Languages ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] New language discussion?
Andrés G. Aragoneses [ knocte ] escribió: Can someone tell the latest state-of-affairs from the recent(?) languages discussion to be used in Bugzilla in the future? (...) Sorry guys, wrong list. Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Silverlight/Moonlight questions
Miguel de Icaza escribió: Is MS Silverlight also a native library like Moonlight? Doesn't it have a managed API to be consumed by managed programs in order to use it outside of a browser? It is a COM component, and Microsoft has stated that they do not plan on supporting that API and reserve the right to break it as needed. Ok! All is clear now. I confess that I couldn't have thought of using COM nowadays... Then, if one wants to make a cross-platform gadget, the only way is depending on the browser component, right? Or creating a compatibility layer library which would call to COM in Windows and deal with Moonlight API library in Linux.. But that seems too complex for me. Would it be feasible to create it? But now I am thinking of another solution: Silverlight is a subset of WPF right? Then, in order to make moonlight work, this small subset of libraries must be already developed on olive, right? Then, I suppose that if one creates a .NET application that uses WPF3.0 libraries without accessing non-Silverlight parts, this application should be crossplatform I guess? If yes, which would be the best way to do this? If current mono WPF libraries just include Silverlight parts (and do not include non-Silverlight even as NIEs), best way would be to compile against them, even from VS.NET, right? I am just wondering which is the better way to create a cross-platform Silverlight desktop application. Thanks for all comments. Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Silverlight/Moonlight questions
Thanks again Rolf, and Miguel. Now my ideas are much clearer. Just some more: :) Rolf Bjarne Kvinge escribió: Hi, - As you guys have managed to make widgets for the desktop using Moonlight, could this be done also with Silverlight? I think so yes. There are Vista gadgets done with Silverlight somewhere. If yes, how one could do that from a normal .NET application that could call a Silverlight widget? I have no idea how the Vista gadgets are made, but one idea is to use the System.Windows.Forms.WebBrowser to embed a browser inside a desktop app. Hugh, but why launching whole browser core just to show a Silverlight widget? Maybe because there's no other way? Well, the other way is calling it as a native library as you just said LunarEclipse is doing, right? [...] Lunareclipse uses pinvokes to call into moonlight, and that part isn't portable. A pity then. If Moonlight had the same native API as Silverlight, I guess this would be portable (I mean, in Windows LunarEclipse could use Silverlight instead of Moonlight), right? Or from a .NET application? I ask this because, as I understand, Silverlight CLR runs in a Sandbox and thus it should not allow to write/read from disk, so then how can anyone save the contents made by lunareclipse in the home directory or whenever on the local computer? It is a .NET application already. Then, how this .NET application launches a Silverlight widget? Lunareclipse uses moonlight (which is just a native library) to draw the xaml in a window. That's all there is to it actually. Is MS Silverlight also a native library like Moonlight? Doesn't it have a managed API to be consumed by managed programs in order to use it outside of a browser? Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Silverlight/Moonlight questions
2 more questions and we finish! :) Rolf Bjarne Kvinge escribió: Thanks again Rolf, and Miguel. Now my ideas are much clearer. Just some more: :) Rolf Bjarne Kvinge escribió: Hi, - As you guys have managed to make widgets for the desktop using Moonlight, could this be done also with Silverlight? I think so yes. There are Vista gadgets done with Silverlight somewhere. If yes, how one could do that from a normal .NET application that could call a Silverlight widget? I have no idea how the Vista gadgets are made, but one idea is to use the System.Windows.Forms.WebBrowser to embed a browser inside a desktop app. Hugh, but why launching whole browser core just to show a Silverlight widget? Maybe because there's no other way? Well, the other way is calling it as a native library as you just said LunarEclipse is doing, right? Just that the native Silverlight API is not public nor documented. Jikes! Is this likely going to change in the future? Maybe by a new managed API that moonlight could mimic? (1.2 version? am I dreaming?) [...] Lunareclipse uses pinvokes to call into moonlight, and that part isn't portable. A pity then. If Moonlight had the same native API as Silverlight, I guess this would be portable (I mean, in Windows LunarEclipse could use Silverlight instead of Moonlight), right? As I just mentioned, the native Silverlight API is not public nor documented, so this would be difficult. Or from a .NET application? I ask this because, as I understand, Silverlight CLR runs in a Sandbox and thus it should not allow to write/read from disk, so then how can anyone save the contents made by lunareclipse in the home directory or whenever on the local computer? It is a .NET application already. Then, how this .NET application launches a Silverlight widget? Lunareclipse uses moonlight (which is just a native library) to draw the xaml in a window. That's all there is to it actually. Is MS Silverlight also a native library like Moonlight? Yes, it is. Doesn't it have a managed API to be consumed by managed programs in order to use it outside of a browser? No. Then, how are Vista Silverlight gadgets developed? Looking at some links (for example [1], found by [2]) it seems like they use kind of a silverlight control. Probably I'm missing something (I should hack a bit before asking dumb questions sorry...). [1] http://blogs.msdn.com/knom/archive/2007/08/08/silverlight-1-1-updates-on-vista-gadgets.aspx [2] http://www.google.com/search?q=vista+gadget+silverlightie=utf-8oe=utf-8aq=trls=org.mozilla:es-ES:officialclient=firefox-a Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Silverlight/Moonlight questions
Hello. Maybe this is not the correct list (mono-list, instead of mono-devel-list?) for this: - As you guys have managed to make widgets for the desktop using Moonlight, could this be done also with Silverlight? If yes, how one could do that from a normal .NET application that could call a Silverlight widget? Would this be cross-platform if you used only managed code? I ask this because here[1] you can see that Silverlight is only understood as a browser plugin, which I think it's incorrect, given the first assumption. [1] http://en.wikipedia.org/wiki/Microsoft_Silverlight - Is the moonlight designer already usable (it's called lunareclipse right?). If yes, is there some page to download tarballs with it? BTW, in a similar way as previous bullet: can lunareclipse be run from the desktop without a browser? If yes, can it be launched from Windows? Or from a .NET application? I ask this because, as I understand, Silverlight CLR runs in a Sandbox and thus it should not allow to write/read from disk, so then how can anyone save the contents made by lunareclipse in the home directory or whenever on the local computer? Many thanks in advance, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Silverlight/Moonlight questions
Hey Rolf thanks for replying! Rolf Bjarne Kvinge escribió: Hi, - As you guys have managed to make widgets for the desktop using Moonlight, could this be done also with Silverlight? I think so yes. There are Vista gadgets done with Silverlight somewhere. If yes, how one could do that from a normal .NET application that could call a Silverlight widget? I have no idea how the Vista gadgets are made, but one idea is to use the System.Windows.Forms.WebBrowser to embed a browser inside a desktop app. Hugh, but why launching whole browser core just to show a Silverlight widget? I would bet current moonlight gadgets don't launch gecko at all. Would this be cross-platform if you used on managed code? I ask this because here[1] you can see that Silverlight is only understood as a browser plugin, which I think it's incorrect, given the first assumption. In theory yes, but it's still a long way to go. [1] http://en.wikipedia.org/wiki/Microsoft_Silverlight - Is the moonlight designer already usable (it's called lunareclipse right?). I haven't tried it yet, so I don't know :) If yes, is there some page to download tarballs with it? No, you have to use SVN to get it. BTW, in a similar way as previous bullet: can lunareclipse be run from the desktop without a browser? Yes (it is a desktop application) Then, is it a Silverlight application that can save XAML files locally or is it a .NET application that launches the Silverlight lunareclupse widget and does the job of dealing with the OS also? If yes, can it be launched from Windows? No. It requires Moonlight, and Moonlight doesn't run on Windows. But, shouldn't it be done in a way that in Windows could be launched using Silverlight instead of Moonlight? Or from a .NET application? I ask this because, as I understand, Silverlight CLR runs in a Sandbox and thus it should not allow to write/read from disk, so then how can anyone save the contents made by lunareclipse in the home directory or whenever on the local computer? It is a .NET application already. Then, how this .NET application launches a Silverlight widget? Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .net library shared source
Jae Stutzman escribió: On 10/3/07, Jonathan Chambers [EMAIL PROTECTED] wrote: See Miguel's blog post: http://tirania.org/blog/archive/2007/Oct-03.html Also, the rules for contributing are still in effect: http://www.mono-project.com/Contributing If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono. - Jonathan (...)There is enough bad press from the folks that think mono is MS pandering(...) Yes. I suppose you're referring to things like this: http://www.eweek.com/article2/0,1895,2191754,00.asp Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Replicating System.Web.Script.Serialization bugs
R. Tyler Ballance escribió: [...] Without providing compatibility for MS.NET, the only alternatives seem to be some application specific hacks, either with crazy properties as mentioned above, or using Nullable types (which we don't yet support in Mono right?) Hey, I think Mono has support for Nullables since much time ago. Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)
Andreas Färber escribió: Am 21.09.2007 um 16:27 schrieb Andrés G. Aragoneses [ knocte ]: What factual arguments would you arise for this decision? (Remember, we want stability, maintainability[3], and portability[1], and we don't want a Gnome VS KDE flamewar. Thanks) Licensing can also influence the decision - Gtk# LGPL vs. Qyoto GPL (not even dual-licensed). Hugh, yes, unfortunately right now we depend on license issues :-/ Thanks for your answer. Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)
Mirco Bauer escribió: On Fri, 2007-09-21 at 16:49 +0200, Andrés G. Aragoneses [ knocte ] wrote: Brandon Perry escribió: I much prefer the Qyoto/Kimono bindings for cross-platform because of it's elegance and it looks much better IMHO on Windows than Gtk#. I haven't run into /too many/ bugs (just a couple, they might have even been resolved by now) with the Qyoto/Kimono bindings. Those are really the only reasons why I prefer Qyoto/Kimono over Gtk#. Thanks for your answer. Those bugs you found, have to be fixed upstream (Qt) or on the binding itself? BTW, what do you use for creating interfaces with Kimono? Do you use a general QT designer that generates XML that can be consumed by any binding? (If not, we have here an advantage for Gtk#: Stetic in MD.) And don't forget glade, since glade3 it's fun to make GUIs :) Our company develops business applications using C# / Gtk# / Glade# / gettext. GTK+/GTK# gives us a permissable license (LGPL), a _very_ stable ABI/API (didn't break since GTK+ 2.0, and today we are at 2.12) and workable release cycles. Gettext integrates very well on windows using Mono.Posix.dll, glade also supports I18N through gettext out of the box. We've also researched about the best portable I18N method, and we have discarded Mono.Posix until bug https://bugzilla.novell.com/show_bug.cgi?id=MONO82850 is closed (actually not a bug, but a RFE). Theming is indeed a bit strange/ugly in GTK+, not well documented, but is very flexible. Gtk# builds on windows lack behind Gtk# on linux, like there is no Gtk# 2.10 installer for windows yet. This is not really a GTK+ nor GTK# issue, but a porting/community issue. GTK# is an official GTK+ binding but there are no official windows ports/builds. Paco is doing them as good and often as he can (and they are _very_ good), but there is sometimes lag. Perhaps it's a porting/community issue, but it's an issue that affects companies and thus it comprises the stability of the whole choice. In total I am very happy what GTK# gives us (the company) and it works very well. I have no experience with QT neither Kimono. Thanks for your answer. Regards, [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
