Re: [Mono-dev] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9)
I've also been trying to compile mono v2.4 on Solaris 10 SPARC and have run into the trouble exactly as you describe. By running the make process with 'MONO_LOG_LEVEL=debug' I've concluded that the build process hangs as soon as the local 2.4 mono is invoked to compile runtime .cs source files (build root/mono/mini/mono --config build root/runtime/etc/mono/config .//class/lib/monolite/mcs.exe etc.). By adding Mono v2.0.1 bin directory to the path we just postpone this hanging from the first attempt to use the local mono applied to 'build/deps/basic-profile-check.exe' to a later attempt applied to System.Xml. I poked arround at internal Makefiles, and by getting gmake to use v2.0.1 mono instead of local 2.4 mono, I was able to get passed System.Xml compilation, however I got stuck at mcs directory compilation, where no makefile manipulation I did could get gmake to use the preinstalled mono. As soon as gmake invokes [build root/mono/mini/mono --config build root/runtime/etc/mono/config .//class/lib/monolite/mcs.exe] we're stuck. By running truss on the hanging process it would seem that it is really caught up in a never-ending loop, but I have no idea why. No more ideas at this point, but I'll post if I make any progress. -- View this message in context: http://www.nabble.com/Compiling-Mono-v2.4-RC2-%28Solaris-10-SPARCv9%29-tp22587130p22863920.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 v2.4 RC2 (Solaris 10 SPARCv9)
did you try the following magic ? ulimit -Hs 10240 Jonathan Soft escribió: I've also been trying to compile mono v2.4 on Solaris 10 SPARC and have run into the trouble exactly as you describe. By running the make process with 'MONO_LOG_LEVEL=debug' I've concluded that the build process hangs as soon as the local 2.4 mono is invoked to compile runtime .cs source files (build root/mono/mini/mono --config build root/runtime/etc/mono/config .//class/lib/monolite/mcs.exe etc.). By adding Mono v2.0.1 bin directory to the path we just postpone this hanging from the first attempt to use the local mono applied to 'build/deps/basic-profile-check.exe' to a later attempt applied to System.Xml. I poked arround at internal Makefiles, and by getting gmake to use v2.0.1 mono instead of local 2.4 mono, I was able to get passed System.Xml compilation, however I got stuck at mcs directory compilation, where no makefile manipulation I did could get gmake to use the preinstalled mono. As soon as gmake invokes [build root/mono/mini/mono --config build root/runtime/etc/mono/config .//class/lib/monolite/mcs.exe] we're stuck. By running truss on the hanging process it would seem that it is really caught up in a never-ending loop, but I have no idea why. No more ideas at this point, but I'll post if I make any progress. ___ 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 v2.4 RC2 (Solaris 10 SPARCv9)
pablosantosl...@terra.es wrote: did you try the following magic ? ulimit -Hs 10240 I did along the way most of the time, but I'm not 100% sure that I reached my conclusions with the heap enlarged. I'll take another look. Another idea I had was to try running ./configure with '--with-jit=no'. If I'm not mistaken that forces make to use 'mono/interpreter/mint' instead of 'mono/mini/mono' for the build process. I won't go there before I try a regular build with ulimit -Hs 10240. -- View this message in context: http://www.nabble.com/Compiling-Mono-v2.4-RC2-%28Solaris-10-SPARCv9%29-tp22587130p22864466.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] Patches for Mono Debugger on Windows
On Thu, 2009-04-02 at 22:52 -0400, Jonathan Chambers wrote: Hello, Here are a few small patches for review. Hi Jonathan, your patches all look good, feel free to commit :-) Martin debugger_windows_braces.patch: A quick fix to allow code to compile on csc. Bug 478101 is filed for gmcs. debugger_windows_generated.patch: Adds generated file CSharpExpressionParser.cs for Windows build. debugger_windows_configuration.patch: Use Environment.SpecialFolder.Personal instead of $HOME and verify configuration file exists before trying to load it. debugger_windows_disassembler_inferior.patch: Adds Windows platform check to Inferior. Marshal strings in Inferior manually since Windows does not free strings using g_free. Martin, exactly what tests/test sets should I be running when I make my changes? Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Martin Baulig - mar...@novell.com Novell GmbH, Nördlicher Zubringer 9-11, 40470 Düsseldorf GF: Dr. Jürgen Müller, Sylvia Geil, Felix Imendörffer; HRB 21108 (AG Düsseldorf) ___ 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 v2.4 RC2 (Solaris 10 SPARCv9)
Am 03.04.2009 um 10:51 schrieb Jonathan Soft: Another idea I had was to try running ./configure with '--with- jit=no'. If I'm not mistaken that forces make to use 'mono/interpreter/mint' instead of 'mono/mini/mono' for the build process. Don't bother. The interpreter has been unsupported and unmaintained for years now, it doesn't even build. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
I think a better approach instead of using dynamic assemblies is to use dynamic methods on 1.0 as well. They can be exposed as internal stuff from mscorlib to System and most of the work will replacing the generic stuff. 2009/4/2 Kornél Pál kornel...@gmail.com Hi, Because of the restrictions of 1.x I modified visibility so I also would like to set skipVisibility = false in DynamicMethod constructor (not included in the patch) to avoid 1.x only bugs because of this. Kornél Kornél Pál wrote: Hi, I've implement support for compiled regular expressions in profile 1.x using dynamic assemblies. I also have cleaned up the code by removing GetEvalMethod and CreateEvalMethod methods and moving their functionality to GetMachineFactory. I also modified the signature of EmitEvalMethodBody and replaced generic dictionaries with hashtables in profile 1.x that results in a larger patch but I haven't modify the actual code generator. I also had to modify some visibility levels to pass runtime type checks. Please review the attached patch. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
Hi,
The runtime has support for generic types in profile 1.0 as well,
OnDeserializedAttribute could also be used, just like new case
insensitive and culture invariant string operations/comparison, static
classes could be supported by profile 1.0 C# compiler because no runtime
support is needed, and this is just some examples of possible 2.0 suff
for internal use in 1.0 class library.
As far as I know none of them or any other 2.0 features are used outside
of mscorlib.dll.
Also note that this is a complete patch including replacing the generic
Dictionaries with non-generic Hashtables.
Attached a more recent version of the patch with some minor updates.
Kornél
Rodrigo Kumpera wrote:
I think a better approach instead of using dynamic assemblies is to use
dynamic methods on 1.0 as well.
They can be exposed as internal stuff from mscorlib to System and most
of the work will replacing the generic
stuff.
2009/4/2 Kornél Pál kornel...@gmail.com mailto:kornel...@gmail.com
Hi,
Because of the restrictions of 1.x I modified visibility so I also would
like to set skipVisibility = false in DynamicMethod constructor (not
included in the patch) to avoid 1.x only bugs because of this.
Kornél
Kornél Pál wrote:
Hi,
I've implement support for compiled regular expressions in
profile 1.x
using dynamic assemblies.
I also have cleaned up the code by removing GetEvalMethod and
CreateEvalMethod methods and moving their functionality to
GetMachineFactory.
I also modified the signature of EmitEvalMethodBody and replaced
generic
dictionaries with hashtables in profile 1.x that results in a larger
patch but I haven't modify the actual code generator.
I also had to modify some visibility levels to pass runtime type
checks.
Please review the attached patch.
Kornél
___
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
Index: RxCompiler.cs
===
--- RxCompiler.cs (revision 130801)
+++ RxCompiler.cs (working copy)
@@ -727,15 +727,33 @@
}
class RxInterpreterFactory : IMachineFactory {
+#if NET_2_0
+ private EvalDelegate eval_del;
+
public RxInterpreterFactory (byte[] program, EvalDelegate
eval_del) {
this.program = program;
this.eval_del = eval_del;
}
-
+
public IMachine NewInstance () {
return new RxInterpreter (program, eval_del);
}
+#else
+ private Type type;
+ public RxInterpreterFactory (byte[] program, Type type) {
+ this.program = program;
+ this.type = type;
+ }
+
+ public IMachine NewInstance () {
+ if (type == null)
+ return new RxInterpreter (program);
+
+ return (RxInterpreter) Activator.CreateInstance (type,
BindingFlags.CreateInstance | BindingFlags.Public | BindingFlags.NonPublic |
BindingFlags.Instance, null, new object[] { program }, null, null);
+ }
+#endif
+
public int GroupCount {
get {
return (int)program [1] | ((int)program [2]
8);
@@ -754,7 +772,6 @@
private IDictionary mapping;
private byte[] program;
- private EvalDelegate eval_del;
private string[] namesMapping;
}
Index: RxInterpreter.cs
===
--- RxInterpreter.cs(revision 130801)
+++ RxInterpreter.cs(working copy)
@@ -8,26 +8,30 @@
namespace System.Text.RegularExpressions {
+#if NET_2_0
internal delegate bool EvalDelegate (RxInterpreter interp, int strpos,
ref int strpos_result);
+#endif
- sealed class RxInterpreter: BaseMachine {
- byte[] program;
- string str;
- int string_start;
- int string_end;
+ class RxInterpreter: BaseMachine {
+ public byte[] program;
+ public string str;
+ public int string_start;
+ public int string_end;
int group_count;
// int match_start;
- int[] groups;
+ public int[] groups;
+#if NET_2_0
EvalDelegate eval_del; // optimized EvalByteCode method created
by the CILCompiler
+#endif
- Mark[] marks = null; // mark stack
+ public Mark[] marks = null; // mark stack
int mark_start; //
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
I think that using public fields instead of private ones costs no work. Parts of this patch related to dynamic assemblies are just a few lines that is complete and needs no maintenace. I didn't have to change a single character in the code generator so the part that really needs maintenance is not affected by this solution. On the other hand maintaining implementations using generic and non-generic hashtables needs maintenance. Most of the things is about introducing non-generic Hashtables and getting rid of GetEvalMethod and CreateEvalMethod methods and making EmitEvalMethodBody return boolean instead of the single DynamicMethod instance ever created in the flow or null. These latter things help maintaining code but most likely won't be accepted either because are not required if we don't want support without DynamicMethods. Anyway I'm not going to push this patch, I just implemented this because this was very straightforward to implement and this solution (at least to me) seems to be very straightforward. Kornél Rodrigo Kumpera wrote: Kornél, Using dynamic assemblies will increase the maintenance burden for no good advantage. It should be done with dynamic methods, if at all. 2009/4/3 Kornél Pál kornel...@gmail.com mailto:kornel...@gmail.com Hi, The runtime has support for generic types in profile 1.0 as well, OnDeserializedAttribute could also be used, just like new case insensitive and culture invariant string operations/comparison, static classes could be supported by profile 1.0 C# compiler because no runtime support is needed, and this is just some examples of possible 2.0 suff for internal use in 1.0 class library. As far as I know none of them or any other 2.0 features are used outside of mscorlib.dll. Also note that this is a complete patch including replacing the generic Dictionaries with non-generic Hashtables. Attached a more recent version of the patch with some minor updates. Kornél Rodrigo Kumpera wrote: I think a better approach instead of using dynamic assemblies is to use dynamic methods on 1.0 as well. They can be exposed as internal stuff from mscorlib to System and most of the work will replacing the generic stuff. 2009/4/2 Kornél Pál kornel...@gmail.com mailto:kornel...@gmail.com mailto:kornel...@gmail.com mailto:kornel...@gmail.com Hi, Because of the restrictions of 1.x I modified visibility so I also would like to set skipVisibility = false in DynamicMethod constructor (not included in the patch) to avoid 1.x only bugs because of this. Kornél Kornél Pál wrote: Hi, I've implement support for compiled regular expressions in profile 1.x using dynamic assemblies. I also have cleaned up the code by removing GetEvalMethod and CreateEvalMethod methods and moving their functionality to GetMachineFactory. I also modified the signature of EmitEvalMethodBody and replaced generic dictionaries with hashtables in profile 1.x that results in a larger patch but I haven't modify the actual code generator. I also had to modify some visibility levels to pass runtime type checks. Please review the attached patch. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
