Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x

2009-04-03 Thread Kornél Pál 
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 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    >>
> 
> 
>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

Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x

2009-04-03 Thread Kornél Pál 

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 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

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

2009-04-03 Thread Rodrigo Kumpera 
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 

> 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] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9)

2009-04-03 Thread Andreas Färber 

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] Patches for Mono Debugger on Windows

2009-04-03 Thread Martin Baulig 
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)

2009-04-03 Thread Jonathan Soft 

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] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9)

2009-04-03 Thread pablosantosl...@terra.es 
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 ( root>/mono/mini/mono --config /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  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)

2009-04-03 Thread Jonathan Soft 

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 (/mono/mini/mono --config /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 /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