Re: [Mono-dev] XML validation : xsi:nil attribute ignored
Hello,
Sorry for the late reply. I haven't read this message until now.
It's already fixed in svn at some stage.
Atsushi Eno
yproust wrote:
> Hi
>
> I am trying to validate XML with an XSD schema, but it seems that the
> xsi:nil attributes are ignored. As the element must be a dateTime,
> validation fails on an empty element :
>
> XmlSchema error: Invalidly typed data was specified. XML Line 3, Position
> 31.
>
> I am using Mono 2.2 under CentOS 5.2.
> The validation fails through Monodevelop 2.0 Alpha 2 (1.9.1) with the same
> error.
>
> On the other hand, the XML is validated with Microsoft Visual Studio under
> Windows XP.
>
> Are there specific options to use in the code ? A specific namespace to use
> in the XSD and/or XML ?
>
> Thanks for your help
>
>
> Here are the files I used to perform my tests :
>
> XSD
>
>
> http://www.test.com"; elementFormDefault="qualified"
> targetNamespace="http://www.test.com";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
> Validated XML
>
>
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://www.test.com"; xsi:schemaLocation="http://www.test.com
> test.xsd">
> 2009-01-23T12:00:00Z
>
>
>
> Not validated XML
>
>
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://www.test.com"; xsi:schemaLocation="http://www.test.com
> test.xsd">
>
>
>
>
> Code used to validate XML :
>
> StreamReader reader = new StreamReader("test.xml");
> string xml = reader.ReadToEnd();
> string xsd = "/home/yproust/dev/test/test.xsd";
>
> XmlReaderSettings settings = new XmlReaderSettings();
> settings.ValidationEventHandler += delegate(object sender,
> ValidationEventArgs e)
> {
> throw new Exception("Error while validating message with xsd: " +
> e.Message);
> };
>
>
> settings.ValidationType = ValidationType.Schema;
> // Load the xsd
> if( xsd != null )
> settings.Schemas.Add(null, new XmlTextReader(xsd));
>
> StringReader stringReader = new StringReader(message);
> try
> {
> myXmlValidatingReader = XmlReader.Create(stringReader, settings);
> while (myXmlValidatingReader.Read()) { }
> myXmlValidatingReader.Close();
> }
> finally
> {
> stringReader.Close();
> }
>
>
>
> Error when validation fails :
>
> XmlSchema error: Invalidly typed data was specified. XML Line 3, Position
> 31.
>
>
>
>
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono is losing session when cookieless="true"
On Thu, 2009-02-12 at 12:13 -0800, MonoMichal wrote: > Hi, > > I have a problem, I need to use cookieless session. > It works very good on my windows machine (Windows XP 5.1 Build 2600, IIS > 5.1), I experience no issues. > > However when I migrate my project to mono server, mono is losing session. > I have trouble reading data from Session object. My application goes down :( > When I set cookieless to "false" everything is ok. > However I can't use session with cookies because of environment which I work > in. > Requirement for my application is to not use cookies. > > I'm fighting with this some time and can't solve :( I can't solve a problem that I can't reproduce ;-). Would you mind entering a bug in bugzilla.novell.com and attaching a self-contained test case that reproduces the problem? Contrary to common knowledge, in the case of tests, the smaller the better. TIA -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] I can not use beagle which is based on mono
I use mono 2.2-r3. I can not use beagle which is based on mono in gentoo. when I run beagle --fg --debug, it will halt and exit after a while. it displays: Debug: Delaying add of file:///media/bak/oo/FILE/??n?¤ì???·.chm until FSQ comes across it ** ERROR:strenc.c:193:mono_unicode_to_external: assertion failed: (utf8!=NULL) Aborted how to fix it ? thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SVN upgraded to subversion 1.5.x
The Mono SVN server at mono-cvs.ximian.com has been upgraded to Subversion 1.5.x. That means that if you have a 1.5.x client you will finally be able to enjoy merge tracking, sparse checkouts, changelists... See http://subversion.tigris.org/svn_1.5_releasenotes.html for the complete list of new features. If you have an older client, this should not affect you in any way. Enjoy! -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] misc: C# request info
- Original Message - From: "Marek Safar" To: "BGB" Cc: Sent: Monday, February 23, 2009 7:56 PM Subject: Re: [Mono-dev] misc: C# request info > Hi, >> well, I was looking into C# some, and admittedly I have much less >> fammiliarity with the language than with others... >> >> (I have started looking at ECMA-334 some, but it is long and a little >> awkward to answer specific questions from absent some digging...). >> >> >> so, firstly, it is my guess that in order to compile C# properly, it is >> required to load a whole group of files at once (I am uncertain whether >> the term 'assembly' also applies to the collection of input source files, >> or only to a produced DLL or EXE). >> > You can load C# source code files as well as assemblies or modules. > yes, ok. >> my guess is that it works like this: >> the group of files is loaded; >> each file is preprocessed and parsed (it is looking like C# uses a >> context-independent syntax?...); >> > Incorrect, C# uses context dependent keywords. I meant, context independent as in, the parser can parse things without knowing about previous declarations. in C, it is necessary to know about declarations (typedefs, structs, ...) in order to be able to parse (otherwise... the syntax is ambiguous...). sadly, I am not all that familiar in detail with C#'s syntax. in C#, this would mean having to know about all of the classes in all of the visible namespaces before being able to parse, which would not seem to be the case. actually, it is looking to me (just my guess from looking at ECMA-334), that rather than processing code a few-tokens at a time and using a syntax where the current parsing depends on prior declarations, C# is using a syntax where it is possible to parse everything without knowing the types at parse-time (I will presume this is assumed/required from the way the language is structured), but that the syntax is not disambiguated be the next 1-or-2 tokens, but may require trying to parse everything that could work and using the first syntactic form that does work. this leads to a difference in parsing strategy, namely that rather than parsing along token-by-token and reporting a parse error the first time an unexpected token is seen, one descends into parsing branches, tries to parse, and if there would be a parse error then returning gracefully, allowing the next higher level to try the next possible interpretation. for example: '(Foo)' is ambiguous, and may be assumed to be a reference in parenthesis; '(Foo)bar' is recognized as a cast, on the grounds that otherwise it would not parse correctly. well, I am not strictly following the syntax structure given in the spec, mostly because to do so would require completely rewriting my existing parser, rather I am figuring out how to make it work (AFAICT, the descriptions in ECMA-334 are LR or LALR, but my parsers are typically hand-written recursive descent, and infact I am using a C parser as the basis for a C# parser, but am having to deal with many subtle but fundamental differences between the languages...). basically, one of the earlier forms of my C compiler is being used as a template (I am using an earlier form which uses S-Exps as the basis, rather than a later form which used DOM instead, as S-Exps are faster and less memory-consuming than DOM nodes). not all is free though, as I had to redirect (via search-and-replace) the old typesystem API to the new typesystem API. decided to leave out big chunk about my uncertainty over the convention of usage of letter-case in said APIs naming convention (which differs some from my newer naming rules, AKA: from 'alllower' to 'camelCase'). note: technically, I am doing all this for a few specific reasons: a new compiler frontend will be less effort for the time being than getting either my JBC or CIL frontend working (JBC and CIL still require some work...); the prior effort have already lead to me adding much of the needed machinery into the compiler core (I am still deciding on the details of how I will do exception handling, and am generally leaning against SEH, but there seems to be little standardization here, so I may do my own thing and possibly hook it into the others using VEH, ...); it would be much less effort (and ugliness) to modify a C frontend into a C# frontend, than to hack OO and namespaces onto C while still preserving its "C-ness" (I beat around some ideas, they were ugly...). as noted, this C# compiler would take the same basic compilation route as my existing C compiler (no intermediate CIL), and will use the same shared backend as my other compilers (since the backend and basic machinery are shared, it doesn't matter too much which frontend uses it, so no real lost effort here...). I have opted against adding CPS to my backend for now (creates too many issues, and would be too much effort, and for now generalized tail-calls and continuations are not worth a pote
Re: [Mono-dev] Patch: Ternary ops in mini and general ATOMIC_CAS
Hi, My problems with this patch, and with adding support for ternary ops in general: - it increases the size of MonoInst by 4/8 bytes. - it slows down every phase of the JIT by changing linear code into loops, ie. instead of it is now a loop with an unknown upper bound. All this to add support for exactly one rarely used instruction, CAS. Zoltan On Mon, Feb 23, 2009 at 8:26 PM, Mark Probst wrote: > Hey, > > These patches implement ternary ops in mini and a general ATOMIC_CAS > (for x86, AMD64 and PPC(64)). > > Please review, especially my register allocator changes. The global > register allocator is not adapted, yet. > > Mark > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Developing using Mono/Gtk# Vs Mono.WinForms (Windows & Linux)
On Fri, 2009-02-13 at 16:57 +0100, Chris Hills wrote: > Tom Opgenorth wrote: > >> What could be better to use Gtk# or Winforms? > > The rule of thumb would use: if the majority of users are Windows, > > use WinForms. If Linux, use GTK#. Of course, this is assuming that > > you're equally skilled in both. > > Bear in mind that if one chooses Gtk# one will have to include it with > one's Windows packages, as the vast majority of Windows users do not > have it installed already. Winforms is available in both .Net and Mono > as standard. The desktop integration of WinForms in Mono could be > improved if someone does the work to allow use of native widgets. I suspect that this isn't possible, because native GTK+ widgets would require a GLib event loop, etc., and wouldn't be able to raise the SWF events that would be needed (which is why implementing SWF atop Gtk# was never a workable solution). The best that is likely possible is theming, which Mono has support for, but theming is a far cry from actual "support" (see also Word 6.0/Mac, one of the most hated Word releases of all time, which wasn't even "themed" but was hated by ~everyone because it didn't behave properly). > On a related note, I would like to see a Qt backend for WinForms > available as well. I believe the KDE project is still working on Qyoto. Mono's System.Windows.Forms doesn't have a "backend" that is handled by other toolkits (such as GTK+ or Qt), so this doesn't make sense. The entire SWF implementation is custom drawn with System.Drawing (itself built upon Cairo on Linux). In summary, Mono's SWF hasn't used native widgets in years, nor will it do so any time soon (afaik), and SWF looks like ass on Linux. Even if it didn't look like ass (and good theme engines will help), it will still behave differently from other Linux apps -- just see all the years of problems with the "feel" part of "look and feel" that Java Swing has dealt with (and oftentimes still suffers from). GTK+ on Windows has similar problems, from what I've heard (looking "alien," not "feeling" correct, etc.). So there is no perfect, one framework fits all solution. (Just see all the people who claim to be able to tell a Qt app at a glance on OS X.) The best solution, from the user perspective, is to provide a UI for each platform, not provide one UI for all platforms. Unfortunately this increases costs, but users tend to prefer this solution, by far... - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Help about how to start?
On Wed, 2009-02-11 at 08:28 -0800, shweta123 wrote: > I wish to contribute the project as a developer. But I don't know > how can I help. So please let me know how can I understand the project? This should be a good start: http://www.mono-project.com/Contributing The larger question is: what areas do you find interesting? There are large swaths of the .NET framework that could use additional help (e.g. see the Roadmap [0]) such as System.Data.Linq (done with the assistance of DbLinq [1]), MSBuild support, ASP.NET MVC, WCF, C#4 support, and more. Or you may want to use the Class Status pages [2] to find a section of the class library which hasn't been implemented yet. Have fun! - Jon [0] http://www.mono-project.com/Roadmap [1] http://linq.to/db [2] http://go-mono.com/status/ ___ 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 call methods on managed objects while running Mono on the iPhone
Hi,
got it to work! I forgot that I had to undefine the "HAVE_MMAP". Seems
like that call doesn't work (but doesn't complain either) on the
iPhone. After doing that I was able to call the ToString on the
Exception class and retrieve the string back just fine!
On Feb 23, 2009, at 5:12 AM, Zoltan Varga wrote:
> Hi,
>
> You have to compile your AOT code using --aot=full, and run the
> runtime using
> the --full-aot option. When embedding, the later can be achieved by
> setting the
> mono_aot_only variable to TRUE _before_ calling mono_jit_init ().
>
>Zoltan
>
> On Mon, Feb 23, 2009 at 6:07 AM, mobbe wrote:
>>
>> An update on this one...I found a setting in XCode that said
>> "Compile for
>> Thumb" and that one was set to true. I unchecked it and recompiled
>> everything and now the code doesn't stop at the same position
>> anymore...now
>> I get an EXC_BAD_ACCESS on the get_hazardous_pointer...so I am
>> still not
>> there but at least I cleared the hurdle I first posted about. Since
>> thumb
>> instructions are 16 bits and ARM mode are 32 bits things must have
>> not been
>> aligned properly and hence the BAD_INSTRUCTION exceptions. This is
>> the call
>> stack right now...
>>
>> #0 0x0007e0cc in get_hazardous_pointer at domain.c:276
>> #1 0x0007e4e8 in mono_jit_info_table_find at domain.c:370
>> #2 0x0020f17c in mono_get_generic_context_from_code at
>> mini-generic-sharing.c:26
>> #3 0x0020f5a8 in mono_convert_imt_slot_to_vtable_slot at
>> mini-trampolines.c:47
>> #4 0x0021044c in mono_magic_trampoline at mini-trampolines.c:348
>> #5 0x03904524 in method_order_end
>>
>> I guess my next step is to research my hazardous_pointers
>>
>>
>>
>> mobbe wrote:
>>>
>>> Over the past couple of weeks I have been working with getting the
>>> Mono
>>> framework up and running on the iPhone and I am darn close to have
>>> it all
>>> working.. .I have been able to get the AOT compilation to work and
>>> was
>>> able this morning to startup Mono in full aot mode on the device.
>>> Big
>>> thanks to Zoltan Varga for helping me through all the roadblocks I
>>> ran
>>> into. I have been working with a SVN HEAD version that I updated
>>> last
>>> week sometime.
>>>
>>> Next step I took was to try to invoke some methods on classes in the
>>> msorlib assembly to see if I could execute managed code and this
>>> is where
>>> I ran into a new road block..
>>>
>>> It looks like I am only able to execute .ctor methods!? During the
>>> startup
>>> of Mono it creates a few exceptions (OutOfMemoryException etc..)
>>> and it
>>> invokes its constructor method and passes in parameters. This
>>> works just
>>> fine...and here it is executing managed code.
>>>
>>> However, I tried to execute the ToString() method on an instance
>>> of the
>>> Exception class and then the program is interrupted and stopped in
>>> the
>>> prolog for the function mono_get_lmf_addr.. if I continue to run the
>>> program
>>> I get a BAD_INSTRUCTION message and the whole thing shuts down...
>>>
>>> Here is the code I am trying to execute...
>>>
>>> MonoDomain * domain = mono_jit_init("");
>>> MonoAssembly* msCorlib = mono_domain_assembly_open
>>> (domain,"mscorlib");
>>> MonoImage* image = mono_assembly_get_image(msCorlib);
>>>
>>> MonoClass *klass = mono_class_from_name (image, "System",
>>> "Exception");
>>> MonoObject* o = mono_object_new (domain, klass);
>>>
>>> MonoMethodDesc* methodDesc =
>>> mono_method_desc_new("System.Object:ToString", TRUE);
>>> MonoMethod* toStringMethod =
>>> mono_method_desc_search_in_class(methodDesc,
>>> klass);
>>> MonoObject* result = mono_runtime_invoke(toStringMethod, o, NULL,
>>> NULL);
>>>
>>>
>>> I don't know if it would help you but here is the assembly where
>>> it all
>>> stops...
>>> mono_get_lmf_addr
>>> 0x001d5bdc <+> push {r4, r5, r7, lr}
>>> 0x001d5bde <+0002> add r7, sp, #8
>>> 0x001d5be0 <+0004> sub sp, #12 <-- stops here
>>> 0x001d5be2 <+0006> ldr r3, [pc, #76] (0x1d5c30
>>> )
>>> 0x001d5be4 <+0008> add r3, pc
>>> 0x001d5be6 <+0010> ldr r3, [r3, #0]
>>> 0x001d5be8 <+0012> adds r0, r3, #0
>>> 0x001d5bea <+0014> bl 0x3e640
>>>
>>> I get the same problem if I try to run other methods on other
>>> objects or
>>> static methods as well...Only constructor methods seems to work.
>>>
>>> It looks to me that the stack isn't setup properly since it always
>>> throws
>>> the EXC_BAD_INSTRUCTION when trying to access the stack pointer.
>>>
>>> I have been banging my head against this problem for two days and
>>> right
>>> now I am not able to figure out how to troubleshoot this. If there
>>> is
>>> anyone out there that have any suggestion on how I should go about
>>> troubleshooting this I would really appreciate it. It stings a bit
>>> to come
>>> this close and not be able to cross the finish line...
>>>
>>>
>>> Thanks,
>>>
>>>
>>
>> --
>> View this message in context:
>> http://w
Re: [Mono-dev] Mono.SIMD
Hey,
The C++ code seems very similar to the C# SIMD code, so I don't know what
would make the C# version any faster. This question would be best directed
at jit guys, who may know what causes the difference.
If you want to try speeding up the mono version, you should just use trial
and error to see if you can rewrite things so that you can get better
performance. For example, unrolling the loop may improve performance
noticably.
Alan.
On Mon, Feb 23, 2009 at 1:16 PM, Johann Nadalutti wrote:
> Hey,
> thanks a lot for your modifications.
> I have now SIMD x3 faster than 4DFloat version !
> I make the same code in C++ and It's x3 more faster than Mono.SIMD.
> I just want to know why and how to optimize my Mono code.
> What do you use as IDE to develop and debug Mono ?
>
>
> My Visual C++ code for test:
>
> class VectorSIMD
> {
> public:
>
> VectorSIMD();
> VectorSIMD(float x, float y, float z, float w);
>
> VectorSIMD operator*(const VectorSIMD& other)
> {
> VectorSIMD r;
> r.vec = _mm_mul_ps(vec, other.vec);
> return r;
> }
>
> VectorSIMD operator*(float f)
> {
> VectorSIMD r;
> __m128 b = _mm_load1_ps(&f);
> r.vec = _mm_mul_ps(vec, b);
> return r;
> }
>
>
> VectorSIMD operator+(const VectorSIMD& other)
> {
> VectorSIMD r;
> r.vec = _mm_add_ps(vec, other.vec);
> return r;
> }
>
> //Datas
> union
> {
> __m128 vec;
> struct { float x, y, z, w; };
> };
>
> };
>
> VectorSIMD::VectorSIMD()
> {
> }
>
> VectorSIMD::VectorSIMD(float _x, float _y, float _z, float _w)
> {
> x=_x;y=_y; z=_z; w=_w;
> }
>
>
> VectorSIMD GradientSIMD()
> {
> VectorSIMD finv_WH(1.0f / (_W*_H), 1.0f / (_W*_H), 1.0f / (_W*_H), 1.0f /
> (_W*_H));
> VectorSIMD ret(0.0, 0.0, 0.0, 0.0);
>
> VectorSIMD a(0.0f, 0.0f, 1.0f, 1.0f);
> a =a + VectorSIMD(0.0f, 1.0f, 0.0f, 1.0f);
> a =a + VectorSIMD(1.0f, 0.0f, 0.0f, 1.0f);
> a =a + VectorSIMD(0.5f, 0.5f, 1.0f, 1.0f);
>
>
> //Process operator
> VectorSIMD yVec(_H, _H, 0, 0);
> VectorSIMD yDiff(-1.0f, -1.0f, 1.0f, 1.0f);
> for (int y=0; y<_H; y++)
> {
> VectorSIMD factor = yVec * finv_WH;
> yVec = yVec + yDiff;
>
> VectorSIMD xVec(_W, 0, _W, 0);
> VectorSIMD xDiff(-1.0f, 1.0f, -1.0f, 1.0f);
> for (int x=0; x<_W; x++)
> {
> ret=ret+(a*xVec*factor);
> xVec=xVec+xDiff;
> }
> }
>
> return ret;
> }
>
>
> Johann.
>
>
>
>
> 2009/2/23 Alan McGovern
>
> Hey,
>>
>> The big issue you're having is that you haven't implemented a SIMD
>> algorithm ;) I spent 15 mins 'optimising' your code and came up with this.
>> Notice that I made everything a SIMD operation. There is no scalar code in
>> the method anymore. This tripled performance as compared to the non-SIMD
>> version. On my machine:
>>
>> -FLOAT 00:00:00.3888930 Color
>> -SIMD 00:00:00.1266820 Mono.Simd.Vector4f
>>
>> You'd want to double check the result just in case I made a mistake with
>> my alterations.
>>
>> Alan.
>>
>> public static Vector4f GradientSIMD()
>> {
>> Vector4f finv_WH = new Vector4f (1.0f / (w*h), 1.0f / (w*h),
>> 1.0f / (w*h), 1.0f / (w*h));
>> Vector4f ret = new Vector4f();
>>
>> Vector4f a = new Vector4f(0.0f, 0.0f, 1.0f, 1.0f);
>> a += new Vector4f(0.0f, 1.0f, 0.0f, 1.0f);
>> a += new Vector4f(1.0f, 0.0f, 0.0f, 1.0f);
>> a += new Vector4f(0.5f, 0.5f, 1.0f, 1.0f);
>>
>> //Process operator
>> Vector4f yVec = new Vector4f (h, h, 0, 0);
>> Vector4f yDiff = new Vector4f (-1, -1, 1, 1);
>> for (int y=0; y> {
>> Vector4f factor = yVec * finv_WH;
>> yVec += yDiff;
>>
>> Vector4f xVec = new Vector4f (w, 0, w, 0);
>> Vector4f xDiff = new Vector4f (-1, 1, -1, 1);
>> for (int x=0; x> {
>> ret += (a * xVec * factor);
>> xVec += xDiff;
>> }
>> }
>> return ret;
>> }
>>
>> On Fri, Feb 20, 2009 at 8:12 AM, Johann_fxgen wrote:
>>
>>>
>>> I have done some performance tests of SIMD under windows.
>>>
>>> Results tests in ms:
>>> In MS C 235 (Visual Studio Release Mode With SIMD)
>>> In MS C 360 (Visual Studio Release Mode With 4D Float)
>>> In Mono C#453 (With Mono SIMD)
>>> In Mono C#562 (With Mono 4D Float)
>>> In MS C# 609 (Visual Studio With 4D Float)
>>> In MS C 672 (Visual Studio Debug Mode)
>>>
>>> I'm just surprise by difference between C SIMD and mono SIMD version.
>>>
>>> Is Mono.SIMD under linux speeder than under windows ?
>>>
>>> Johann.
>>>
>>> My mono code for test:
>>>
>>>using Mono.Simd;
>>>using System;
>>>using Mono;
>>>
>>>public struct
Re: [Mono-dev] Making your own programming language for mono
Hey, There are already several existing tools you may use like Irony (grammar and parser framework) and the DLR (turning AST into running programs). Both are on CodePlex if you want the code. That's the two I used to get a minimal implementation of Scheme running on Mono. -- Jérémie Laval jeremie.la...@gmail.com http://garuma.wordpress.com On Sun, Feb 22, 2009 at 3:52 PM, xiul wrote: > > Hi everyone, I just want to know if it's possible to create your own > language > (a very simple one and probably not object oriented) for mono (for academy > purpose of a course at university), and if this task is possible, I want to > know just what steps probably I should follow to do this task, like: create > lexer in this way, create parser that generate this kind of AST, then pass > the AST to this function to generate code or something like that. > > Thanks for any help. > -- > View this message in context: > http://www.nabble.com/Making-your-own-programming-language-for-mono-tp22147566p22147566.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unable to call methods on managed objects while running Mono on the iPhone
Hi,
You have to compile your AOT code using --aot=full, and run the runtime using
the --full-aot option. When embedding, the later can be achieved by setting the
mono_aot_only variable to TRUE _before_ calling mono_jit_init ().
Zoltan
On Mon, Feb 23, 2009 at 6:07 AM, mobbe wrote:
>
> An update on this one...I found a setting in XCode that said "Compile for
> Thumb" and that one was set to true. I unchecked it and recompiled
> everything and now the code doesn't stop at the same position anymore...now
> I get an EXC_BAD_ACCESS on the get_hazardous_pointer...so I am still not
> there but at least I cleared the hurdle I first posted about. Since thumb
> instructions are 16 bits and ARM mode are 32 bits things must have not been
> aligned properly and hence the BAD_INSTRUCTION exceptions. This is the call
> stack right now...
>
> #0 0x0007e0cc in get_hazardous_pointer at domain.c:276
> #1 0x0007e4e8 in mono_jit_info_table_find at domain.c:370
> #2 0x0020f17c in mono_get_generic_context_from_code at
> mini-generic-sharing.c:26
> #3 0x0020f5a8 in mono_convert_imt_slot_to_vtable_slot at
> mini-trampolines.c:47
> #4 0x0021044c in mono_magic_trampoline at mini-trampolines.c:348
> #5 0x03904524 in method_order_end
>
> I guess my next step is to research my hazardous_pointers
>
>
>
> mobbe wrote:
>>
>> Over the past couple of weeks I have been working with getting the Mono
>> framework up and running on the iPhone and I am darn close to have it all
>> working.. .I have been able to get the AOT compilation to work and was
>> able this morning to startup Mono in full aot mode on the device. Big
>> thanks to Zoltan Varga for helping me through all the roadblocks I ran
>> into. I have been working with a SVN HEAD version that I updated last
>> week sometime.
>>
>> Next step I took was to try to invoke some methods on classes in the
>> msorlib assembly to see if I could execute managed code and this is where
>> I ran into a new road block..
>>
>> It looks like I am only able to execute .ctor methods!? During the startup
>> of Mono it creates a few exceptions (OutOfMemoryException etc..) and it
>> invokes its constructor method and passes in parameters. This works just
>> fine...and here it is executing managed code.
>>
>> However, I tried to execute the ToString() method on an instance of the
>> Exception class and then the program is interrupted and stopped in the
>> prolog for the function mono_get_lmf_addr.. if I continue to run the
>> program
>> I get a BAD_INSTRUCTION message and the whole thing shuts down...
>>
>> Here is the code I am trying to execute...
>>
>> MonoDomain * domain = mono_jit_init("");
>> MonoAssembly* msCorlib = mono_domain_assembly_open (domain,"mscorlib");
>> MonoImage* image = mono_assembly_get_image(msCorlib);
>>
>> MonoClass *klass = mono_class_from_name (image, "System", "Exception");
>> MonoObject* o = mono_object_new (domain, klass);
>>
>> MonoMethodDesc* methodDesc =
>> mono_method_desc_new("System.Object:ToString", TRUE);
>> MonoMethod* toStringMethod = mono_method_desc_search_in_class(methodDesc,
>> klass);
>> MonoObject* result = mono_runtime_invoke(toStringMethod, o, NULL, NULL);
>>
>>
>> I don't know if it would help you but here is the assembly where it all
>> stops...
>> mono_get_lmf_addr
>> 0x001d5bdc <+> push {r4, r5, r7, lr}
>> 0x001d5bde <+0002> add r7, sp, #8
>> 0x001d5be0 <+0004> sub sp, #12 <-- stops here
>> 0x001d5be2 <+0006> ldr r3, [pc, #76] (0x1d5c30
>> )
>> 0x001d5be4 <+0008> add r3, pc
>> 0x001d5be6 <+0010> ldr r3, [r3, #0]
>> 0x001d5be8 <+0012> adds r0, r3, #0
>> 0x001d5bea <+0014> bl 0x3e640
>>
>> I get the same problem if I try to run other methods on other objects or
>> static methods as well...Only constructor methods seems to work.
>>
>> It looks to me that the stack isn't setup properly since it always throws
>> the EXC_BAD_INSTRUCTION when trying to access the stack pointer.
>>
>> I have been banging my head against this problem for two days and right
>> now I am not able to figure out how to troubleshoot this. If there is
>> anyone out there that have any suggestion on how I should go about
>> troubleshooting this I would really appreciate it. It stings a bit to come
>> this close and not be able to cross the finish line...
>>
>>
>> Thanks,
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Unable-to-call-methods-on-managed-objects-while-running-Mono-on-the-iPhone-tp22155202p2216.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.SIMD
Hey,
The big issue you're having is that you haven't implemented a SIMD algorithm
;) I spent 15 mins 'optimising' your code and came up with this. Notice that
I made everything a SIMD operation. There is no scalar code in the method
anymore. This tripled performance as compared to the non-SIMD version. On my
machine:
-FLOAT 00:00:00.3888930 Color
-SIMD 00:00:00.1266820 Mono.Simd.Vector4f
You'd want to double check the result just in case I made a mistake with my
alterations.
Alan.
public static Vector4f GradientSIMD()
{
Vector4f finv_WH = new Vector4f (1.0f / (w*h), 1.0f / (w*h),
1.0f / (w*h), 1.0f / (w*h));
Vector4f ret = new Vector4f();
Vector4f a = new Vector4f(0.0f, 0.0f, 1.0f, 1.0f);
a += new Vector4f(0.0f, 1.0f, 0.0f, 1.0f);
a += new Vector4f(1.0f, 0.0f, 0.0f, 1.0f);
a += new Vector4f(0.5f, 0.5f, 1.0f, 1.0f);
//Process operator
Vector4f yVec = new Vector4f (h, h, 0, 0);
Vector4f yDiff = new Vector4f (-1, -1, 1, 1);
for (int y=0; y wrote:
>
> I have done some performance tests of SIMD under windows.
>
> Results tests in ms:
> In MS C 235 (Visual Studio Release Mode With SIMD)
> In MS C 360 (Visual Studio Release Mode With 4D Float)
> In Mono C#453 (With Mono SIMD)
> In Mono C#562 (With Mono 4D Float)
> In MS C# 609 (Visual Studio With 4D Float)
> In MS C 672 (Visual Studio Debug Mode)
>
> I'm just surprise by difference between C SIMD and mono SIMD version.
>
> Is Mono.SIMD under linux speeder than under windows ?
>
> Johann.
>
> My mono code for test:
>
>using Mono.Simd;
>using System;
>using Mono;
>
>public struct Color
>{
>public float r,g,b,a;
>};
>
>public class TestMonoSIMD
>{
>public Color m_pixels;
>const int w = 4096;
>const int h = 4096;
>
>public static void Main ()
>{
>//Debug
>Console.WriteLine("AccelMode: {0}",
> Mono.Simd.SimdRuntime.AccelMode );
>
>//Without SIMD
>DateTime start1 = DateTime.Now;
>Color ret1 = Gradient();
>TimeSpan ts1 = DateTime.Now - start1;
>Console.WriteLine("-FLOAT {0} {1}", ts1, ret1);
>
>//With SIMD
>DateTime start2 = DateTime.Now;
>Vector4f ret2 = GradientSIMD();
>TimeSpan ts2 = DateTime.Now - start2;
>Console.WriteLine("-SIMD {0} {1}", ts2, ret2);
>}
>
>public static Color Gradient()
>{
>float finv_WH = 1.0f / (float)(w*h);
>Color ret = new Color();
>ret.r=ret.g=ret.b=ret.a=0.0f;
>
>Color a = new Color();
>Color b = new Color();
>Color c = new Color();
>Color d = new Color();
>a.r=0.0f; a.g=0.0f; a.b=1.0f; a.a=1.0f;
>b.r=0.0f; b.g=1.0f; b.b=0.0f; b.a=1.0f;
>c.r=1.0f; c.g=0.0f; c.b=0.0f; c.a=1.0f;
>d.r=0.5f; d.g=0.5f; d.b=1.0f; d.a=1.0f;
>
>//Process operator
>for (int y=0; y{
>for (int x=0; x{
>//Calc percent A,B,C,D
>float pa = (float)((w-x)*
> (h-y)) * finv_WH;
>float pb = (float)((x) *
> (h-y)) * finv_WH;
>float pc = (float)((w-x)*
> (y)) * finv_WH;
>float pd = (float)((x) *
> (y)) * finv_WH;
>
>float cr= ((a.r*pa) + (b.r*pb) +
> (c.r*pc) + (d.r*pd));
>float cg= ((a.g*pa) + (b.g*pb) +
> (c.g*pc) + (d.g*pd));
>float cb= ((a.b*pa) + (b.b*pb) +
> (c.b*pc) + (d.b*pd));
>float ca= ((a.a*pa) + (b.a*pb) +
> (c.a*pc) + (d.a*pd));
>ret.r+=cr; ret.g+=cg;
> ret.b+=cb; ret.a+=ca;
>}
>}
>return ret;
>}
>
>public static Vector4f GradientSIMD()
>{
>float finv_WH = 1.0f / (float)(w*h);
>Vector4f ret = new Vector4f(0.0f, 0.0f, 0.0f, 0.0f);
>
>
Re: [Mono-dev] misc: C# request info
Hi, > well, I was looking into C# some, and admittedly I have much less > fammiliarity with the language than with others... > > (I have started looking at ECMA-334 some, but it is long and a little > awkward to answer specific questions from absent some digging...). > > > so, firstly, it is my guess that in order to compile C# properly, it is > required to load a whole group of files at once (I am uncertain whether the > term 'assembly' also applies to the collection of input source files, or > only to a produced DLL or EXE). > You can load C# source code files as well as assemblies or modules. > my guess is that it works like this: > the group of files is loaded; > each file is preprocessed and parsed (it is looking like C# uses a > context-independent syntax?...); > Incorrect, C# uses context dependent keywords. > all of the namespaces and declarations are "lifted out" of the parse trees; > each file's parse tree can then be compiled. > > from what I can tell, types are like this: > type = * > > so, I can type: > static Foo bar; > > > and the parser will know that 'Foo' is the type, even if the type for Foo is > not visible at the time of parsing (in C, this can't be done since there is > no clear distinction or ordering between types and qualifiers, and so one > would not know if 'Foo' is the type, or an intended variable name with the > type being assumed to be 'int'). > No, parser does not yet know the type of 'Foo'. > so, in C we can have: > unsigned int i; > int unsigned i; > int volatile i; > _Complex float f; > double _Complex g; > > unsigned i; > short int j; > int long k; > .. > > so, my guess then is that C# code is "just parsed", with no need to lookup, > for example, is Foo a "struct or class or other typedef'ed type?" ... > > as far as the parser is concerned 'int' or 'byte' is syntactically not > different from 'Foo' or 'Bar'?... > Correct. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in DataGridView.ScrollBars
2009/2/23 Ivan N. Zlatev : > 2009/2/20 Marcelo Marques Inacio : >> Dear friends developers. >> >> The property ScrollBars.Vertical or ScrollBars.Horizontal in the >> DataGridView control is not working properly. >> The horizontal and vertical bar is always visible. >> Attached the following changes to correct operation. >> > > I have fixed this in r127716, thanks. Please next time directly file > bugs for the WinForms component next time - > http://mono-project.com/Bugs . Nothing to see with this ? : https://bugzilla.novell.com/show_bug.cgi?id=477748 > > -- > Kind Regards, > Ivan N. Zlatev > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Cordially. Small Eric Quotations of the days: --- If one day one reproaches you that your work is not a work of professional, say you that: Amateurs built the arch of Noah, and professionals the Titanic. --- Few people are done for independence, it is the privilege of the powerful ones. --- No key was wounded during the drafting of this message. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in DataGridView.ScrollBars
2009/2/20 Marcelo Marques Inacio : > Dear friends developers. > > The property ScrollBars.Vertical or ScrollBars.Horizontal in the > DataGridView control is not working properly. > The horizontal and vertical bar is always visible. > Attached the following changes to correct operation. > I have fixed this in r127716, thanks. Please next time directly file bugs for the WinForms component next time - http://mono-project.com/Bugs . -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
