ds,
Jeroen
> -Original Message-
> From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com]
> Sent: Tuesday, February 17, 2015 13:03
> To: Jeroen Frijters; Daniel Kahn Gillmor; mono development list;
> marek.safar marek.sa...@gmail.com
> Cc: Henrik Feldt; Jo Shields; Debian Repro
uary 16, 2015 23:20
> To: mono development list
> Cc: Jeroen Frijters; Jo Shields; Debian Reproducible Builds; Henrik
> Feldt
> Subject: making mono builds reproducible (xamarin bz #26842)
>
> Hi Mono folks--
>
> some good discussion has come up on the xamarin bugtracker
If you know the module on the managed side, Module.ResolveMethod() can be used
to get a MethodInfo from a token.
Regards,
Jeroen
> -Original Message-
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Greg Young
> Sent: Satu
Michael Bayne wrote:
> which is what contains the failing assert:
>
> g_assert (method && method->klass->parent ==
> mono_defaults.multicastdelegate_class &&
> !strcmp (method->name, "BeginInvoke"));
This assert is wrong. The BeginInvoke and EndInvoke methods are optional in
Michael Bayne wrote:
> (or an issue of IKVM generating funky bytecodes)
Define funky. IKVM.OpenJDK.Core.dll definitely contains things out of the
ordinary, but I'm pretty sure they are legal (as in ECMA CLI specification) and
definitely sure that it passes peverify.
Regards,
Jeroen
___
Robert Jordan wrote:
> How about relying on System.Threading.SynchronizationContext.Current?
> This could work w/out exposing any internal calls/env vars.
This is actually a pretty good idea, but you'd need to capture the
SynchronizationContext in the __ComObject constructor, not use the one of t
'IKVM.Runtime, Version=0.45.4037.0, Culture=neutral,
PublicKeyToken=null'
Using an absolute path works:
C:\ikvm\tests\regression>mono c:\ikvm\bin\ikvm.exe
IKVM.NET Launcher version 0.45.4037.0
Copyright (C) 2002-2011 Jeroen Frijters
h
Hi Justin,
I'm currently working on adding a simple CIL peephole optimization phase to
ikvmc. The primary reason is to reduce file size, because as Rodrigo pointed
out the JIT will also do most of these optimizations, but I believe that file
size is important too.
Some of the optimizations I'm
Hi Kornél,
> I'm just trying to implement /nostdlib:
> http://msdn.microsoft.com/en-us/library/fa13yay7.aspx
>
> And I belive that having API for setting assembly aliases would be a
> good solution.
I think I understand better where you're coming from now. I did some more work
on it in the mean
> LoadMscorlib was designed to meet your very specific needs of being able
> to load mscorlib.dll from a specified file.
Any API designed without a very specific use case is doomed, so I consider this
a feature not a bug.
I don't understand what problem you are trying to solve, so maybe we shoul
> Please see the attached patch.
>
> I belive that this is actually an easier and cleaner solution than the
> current one.
I disagree. You have to look at it from an API development point of view. This
creates a huge window for undefined behavior and dependencies on implementation
specifics, be
> I would recommend SetMscorlib over LoadMscorlib because that would not
> restrict how you can create or load mscorlib.dll.
That feels like painting yourself into a corner to me. Using SetMscorlib would
require modifying DefineDynamicAssembly in a way that would make it hard to
remain compatibl
> I've just realized that DefineDynamicAssemblyImpl should not hardcode
> the name "mscorlib" since C# compiler is able to us any name when
> compiling with nostdlib.
The hardcoded name bother me too, but then I couldn't think of any realistic
scenario where you'd build an mscorlib with a differe
Hi Kornél,
Thanks. Fixed all three issues.
Regards,
Jeroen
> -Original Message-
> From: Kornél Pál [mailto:kornel...@gmail.com]
> Sent: Friday, May 07, 2010 6:08 PM
> To: Jeroen Frijters
> Cc: mono-devel
> Subject: Re: Porting mcs to IKVM.Reflection
>
> Hi Je
Hi Kornél,
This has now been fixed.
Thanks,
Jeroen
> -Original Message-
> From: Kornél Pál [mailto:kornel...@gmail.com]
> Sent: Friday, May 07, 2010 10:33 AM
> To: Jeroen Frijters
> Cc: Marek Safar; mono-devel; Miguel de Icaza
> Subject: Re: Porting mcs to IKVM.
> This code will work on both of Mono and MS.NET, but will fail without
> the WriteGenericSignature patch:
[...]
> Although using a generic type definition directly makes little sense,
> neither makes using tb.MakeGenericType(tb.GetGenericArguments()) much
> more sense, since you still can use the
Hi Kornél,
I've fixed most of the things that your patch addressed. I also removed support
for the TypeForwardedToAttribute and DefaultParameterValueAttribute pseudo
custom attributes (because I realized that supporting them is incompatible with
my goal to be a drop in replacement for System.Re
> My understanding is that basically we only have two compilers:
> - static: mcs.exe, gmcs.exe, smcs.exe, dmcs.exe (for each profile)
> - dynamic: Mono.CSharp.dll, that is used by Microsoft.CSharp.dll and
> csharp.exe
>
> As I see (based on your explanation) only the dynamic (as in th
Kornél Pál wrote:
> mcs creates an assembly, then creates types, and only after that is
> processing the custom attributes. This is how attributes and even
> assembly name (not the name part) can change after definition. Although
> there are some other self referencing cases, this order of
> creati
com]
> Sent: Tuesday, May 04, 2010 2:03 PM
> To: mono-devel
> Cc: Miguel de Icaza; Marek Safar; Jeroen Frijters
> Subject: Porting mcs to IKVM.Reflection
>
> Hi,
>
> Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a
> try to port mcs to IKVM.Reflection.
; To: marek.safar; Rolf Bjarne Kvinge; Jeroen Frijters
> Cc: mono-devel-list@lists.ximian.com
> Subject: Getting rid of SRE CompilerContext
>
> Hey folks,
>
> Now that Marek has landed support for CompilerContext free mcs[1], I do
> want to start killing all CompilerContex
Hi Rodrigo,
Is it possible to back port 506757 to 2.4.2? This bug prevents the building of
(what will become) IKVM 0.42.
Thanks,
Jeroen
> -Original Message-
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Thomas Wiest
>
Hi Rodrigo,
I've updated http://www.frijters.net/ikvm-cecil.zip with the latest changes I
did. The ikvmc patch is against a somewhat older version of ikvm cvs than
current so it probably won't apply cleanly, but the changes are trivial.
Note that I only changed System.Reflection.Emit to use Cec
Luis F. Ortiz wrote:
> On Sep 4, 2007, at 6:51 AM, Marek Safar wrote:
> > Hi Luis,
> >> 1) MCS assumed that the arguments to NEWARR were always U4 or I4,
> >> which does not seem
> >> to be the case as far as ECMA-335v4.
> >> ...
> >> A) Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I ins
Onur Gumus wrote:
> Jonathan , I am not sure if IKVM would do . Since I want to compile my
> project on linux once and for all and be able to deploy to Windows
> machines by only XCOPY.
The IKVM binaries are cross platform, so you can xcopy deploy them to Windows
without any problems.
Only if yo
Daniel Morgan wrote:
> IKVM.NET and JDBC.
>
> Has anyone tried connecting to a database using JDBC on top of IKVM.NET
> yet? I'm interested in using Oracle's JDBC Thin driver to connect to
> an Oracle database using IKVM.NET on top of Mono? Is this possible?
> It would be neat if someone wrote a
Hi Paul,
That's expected. It's deleting the *.class files.
Regards,
Jeroen
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul
> Sent: Saturday, September 23, 2006 20:57
> To: mono-devel
> Subject: [Mono-dev] Compiling ikvm-0.30.0.0
>
> Hi,
>
Miguel de Icaza wrote:
> Mono 1.1.17 has been released.
[...]
>The following bugs were fixed on this release:
I made a list of the bugs fixed that contains a little more info than
only the number:
http://www.frijters.net/mono-bugs-fixed-1.1.17.html
Regards,
Jeroen
__
Hi Marek,
I spent quite a bit of time crafting a small repro, which I don't mind
doing, but I'm not about to waste my time wrestling with bugzilla.
Regards,
Jeroen
> -Original Message-
> From: Marek Safar [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 06, 2006
Hi,
I ran into a bug in mcs. The program below obviously should print 42,
but it prints 0, because mcs reuses loc.0 for two different things
within the same expression.
Regards,
Jeroen
using System;
class Repro
{
private int[] stack = new int[1];
private int cc;
public i
Miguel de Icaza wrote:
> And typeof(_CustomAttributeBuilder) fails to build.
Did you import the right namespace? It lives in
System.Runtime.InteropServices.
BTW, AFAIK this interface exists purely for COM interop, so its value is
limited in Mono.
Regards,
Jeroen
_
Miguel de Icaza wrote:
> Type t = typeof (CustomAttributeBuilder);
> Console.WriteLine (t.BaseType);
>
> And it does not display anything. When compiled with csc 8, it does
> display _CustomAttributeBuilder.
Huh? _CustomAttributeBuilder is an interface, so it obvious
32 matches
Mail list logo
