[Mono-dev] Developer needed for contract position
Send to MonoDev mailing list: Not sure if sending this to the mailing list is taboo or not, but I at least hope it is of some value to those who would reply: Welch Allyn, a medical device manufacturer (www.welchallyn.com), is looking for a contract position that will involve working with the Mono code on an embedded device with a team of other software engineers. It is likely to cover debugging both C and C# code, and possibly some of the more difficult ends of the JIT and MMU. Experience with the internal workings of the Mono runtime and/or libraries is a must. Send resumes to michael.mu...@welchallyn.com and please pass this message on to anyone who may be interested. Thanks, - Michael Mudge Software Lead Engineer Welch Allyn Skaneateles, NY ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cross-Appdomain remoting
Ah! The idea of changing the lifetime was enough info for me to find the cause. Hm, I could swear I saw a difference in behavior between .NET and Mono, but my simplified test case revealed an identical error (with slightly different text) in .NET - that led me to InitializeLifetimeService. I overrode InitializeLifetimeService on the MarshalByRef objects and returned null - this prevents the objects from expiring. Thanks for the reply! - Kipp On Thu, May 5, 2011 at 4:49 PM, Robert Jordan robe...@gmx.net wrote: Hi, On 05.05.2011 22:11, Michael Mudge wrote: I'm seeing strange behavior on our device - AppDomain A has launched AppDomain B, and wired the DomainUnloaded event. I'm seeing that RemotingServices.DisposeIdentity is being called after 5 minutes, and then when AppDomain B unloads itself and the unload event is fired, I get this error: Unhandled Exception: System.Runtime.Remoting.RemotingException: Server for uri '6c9364e7_bf92_4f6d_950d_9cfc5c9a372d/b4c91032_2.rem' not found Server stack trace: at System.Runtime.Remoting.Proxies.RealProxy.GetAppDomainTarget () [0x0] infilename unknown:0 at (wrapper xdomain-dispatch) Manager.Shells.WAppServer:HandleDomainUnload (object,byte[],byte[],string) I *think* that the problem is that the domain unload can't find A. I *think* that the object that can't be found is supposed to be automatically recreated - am I right? If that's true, I'm guessing The proxy won't be recreated. If you want to prevent it from being disposed, you should either change its lifetime (via app.config's system.runtime.remoting element) or call/poll a method periodically. that this can't be done when an AppDomain is being unload... Is that true? Where should I start looking to solve this? Can someone provide a clearer explanation of how this all works? Please explain first (preferably with code) what you're trying to achieve. 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] Cross-Appdomain remoting
I'm seeing strange behavior on our device - AppDomain A has launched AppDomain B, and wired the DomainUnloaded event. I'm seeing that RemotingServices.DisposeIdentity is being called after 5 minutes, and then when AppDomain B unloads itself and the unload event is fired, I get this error: Unhandled Exception: System.Runtime.Remoting.RemotingException: Server for uri '6c9364e7_bf92_4f6d_950d_9cfc5c9a372d/b4c91032_2.rem' not found Server stack trace: at System.Runtime.Remoting.Proxies.RealProxy.GetAppDomainTarget () [0x0] in filename unknown:0 at (wrapper xdomain-dispatch) Manager.Shells.WAppServer:HandleDomainUnload (object,byte[],byte[],string) I *think* that the problem is that the domain unload can't find A. I *think* that the object that can't be found is supposed to be automatically recreated - am I right? If that's true, I'm guessing that this can't be done when an AppDomain is being unload... Is that true? Where should I start looking to solve this? Can someone provide a clearer explanation of how this all works? - Kipp ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Issue with inlining in the JIT
I'm running into an access violation in Mono... I've traced the cause as far back as I can (mono_method_to_ir), but that function is so full of macros and switches that it's hard to figure out how it came to make the decision it did. Here is the story of how the access violation occurs: ins-sreg1 is being set to 0xA365734 in method-to-ir.c, line 5928 (call to EMIT_NEW_ARGLOAD call in the CEE_LDARG_3 case of mono_method_to_ir). The call stack at this point is: mono_method_to_ir (working on Size::.ctor) .. called by inline_method() (working on Size::.ctor) .. called by mono_method_to_ir() (working on Rectangle::get_Size) .. called by inline_method() (working on Rectangle::get_Size) .. called by mono_method_to_ir() (working on TextRenderer::MeasureTextInternal) .. called by mini_method_compile() (working on TextRenderer::MeasureTextInternal) .. Later, in local-propagation.c, line 77 (at the call to mono_inst_get_src_registers in mono_local_cprop), the ins-sreg1 value is moved to sregs[0]: num_sregs = mono_inst_get_src_registers (ins, sregs); Two lines later, the value is moved to sreg: int sreg = sregs [i]; Two lines later, that value (0xA365734) is used to index into an array: defs [sreg] = NULL; And boom, access violation. I can follow values around all day, but I have no idea what this code is supposed to do or how it should work. Anyone have any insight the cause of this? The next steps in terms of debugging? I'm using Mono 2.8.2. - Kipp ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-winforms-list] Porting Mono winforms to a new OS/Window Manager
We are working on getting Mono WinForms up and running on our device, and I'd like to make sure that we're on the right track and have a good understanding of what is ahead of us. Through the project, most of our issues have been unknown unknowns - so if you can anticipate any obstacles, it would be very helpful. We use a GUI manager called PegX - it is fairly primitive. As I understand it, there is some dependency between LibGDIPlus and the GUI, and XPlatUIDriver is also meant to map to the GUI. What is the description of these relationships? PegX does make use of some hardware acceleration, so we would like to leverage that as much as possible. Also, the current implementation of LibGDIPlus has dependencies on many things - FontConfig, FreeType, LibPNG, XLib, GLib, Cairo. We only have FreeType and Cairo completely ported. Are there parts of LibGDIPlus that we can cut out and replace with calls straight to PegX, and minimize all of the remaining dependencies? Is there someone who can help guide us? The system is touchscreen-only. How much do we need to be concerned with the UI message pump? The only touchscreen events are down, move and up. How might we detect that the cursor has clicked on a textbox so that we can pop up our onscreen keyboard? And most importantly, what questions have I failed to ask? Thanks, - Michael Kipp Mudge Welch Allyn ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-dev] Porting Mono to a new platform
I have a device (ARM9 Freescale MX27) running a rather large application written in C++ on the ThreadX operating system. A bit late in the game now, I'd like to add an enabling technology - while the current C++ app must continue to run as normal, I would like to add the option for third-party developers to write software that will run on the device, perhaps in the background or on a different GUI page. Completely porting the C++ app is not an option, although I would incrementally port portions of the program to run under this new enabling technology, making it possible to move to entirely new hardware in the future. Java, Flash and even a simple web browser are possibilities, but I ran into the Microsoft .NET Micro Framework, which looks to be a very good candidate... although it obviously has its pitfalls: it's slow (interpreted), has very minimal libraries (300K) and it can only run an odd file format of half-digested CLR images. So if I'm going to consider that, it would be prudent to check up on Mono: 1. What kind of manpower would be required to perform the port? 2. Are there any existing ports (maybe even to ThreadX) from which I could springboard? 3. What are the minimum Mono RAM/ROM requirements? 4. Are there remote-debugging options for debugging CLR images on the device from a Linux PC? Windows PC? What is the development effort to get those working? - Kipp ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
