From iulian.fecioru at napa.fi Thu Sep 1 03:00:24 2011 From: iulian.fecioru at napa.fi (Iulian Fecioru) Date: Thu, 1 Sep 2011 10:00:24 +0300 Subject: [Ironruby-core] ObjectSpace module Message-ID: Hello, Sorry for the late reply. Implementing directly in the libraries will involve adding some logic somewhere in something like RubyInstanceData (where ObjectID is implemented, I didn't investigate in detail yet). We use this feature: object -> object_id -> object. Thank you! PS: When a new version of IronRuby will be released? Regards, Iulian Fecioru From: Tomas Matousek [mailto:Tomas.Matousek at microsoft.com] Sent: Tuesday, August 16, 2011 9:41 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] ObjectSpace module This is actually pretty good solution - it's not harming perf of apps that don't need the feature. Is there any real-world scenario that this doesn't address? [Iulian Fecioru] I don't understand the question Some app translating random integers to objects? [Iulian Fecioru] I don't understand the question Until there is I'm not sure if it makes sense to go any further. What about implementing your approach directly in the libraries? Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Iulian Fecioru Sent: Monday, August 15, 2011 10:35 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] ObjectSpace module Hello, Thank you for your response. My implementation was a trick to make something working. I think I can do this more correctly and complete in the IronRuby core. I'll try to implement this in IronRuby core, if nobody is against this. (Something like JRuby has implemented). Regards, Iulian Fecioru From: Tomas Matousek [mailto:Tomas.Matousek at microsoft.com] Sent: Wednesday, August 10, 2011 7:20 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] ObjectSpace module Your implementation of _id2ref might be a good enough approximation. (It isn't 100% equivalent to MRI though since in MRI I can enumerate integers and ask if there is an object with that id. So I can get to objects for which object_id wasn't called before.) You "become" a developer by submitting a patch on github. No need to talk to anybody J. Of course, it is better to let folks in this list know what you're working on so that we don't dup efforts. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Iulian Fecioru Sent: Tuesday, August 09, 2011 10:51 PM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] ObjectSpace module Hello, I've wrote on http://ironruby.codeplex.com/workitem/6028 that the ObjectSpace module is not complete Comments from the issues above: " wrote Thu at 11:57 PM File.realpath is a Ruby 1.9 method we haven't gotten to. We're unable to implement those methods of ObjectSpace as we can't track them ourselves as we don't know when the CLR will garbage collect a specific object, and we don't have access to a list of reachable objects. Renaming this issue to track File.realpath iulianfecioru wrote Fri at 8:27 AM >From the previous comment I understand that methods from ObjectSpace (_id2ref, count_objects.) will not be supported. Is this true?! PS: I've added _id2ref method to the ObjectSpace, so I think it is posible but is just my opinion ;) jimmysch wrote Fri at 4:50 PM How did you implement _id2ref in IronRuby? I'm 100% sure we can't implement it without slowing down the entire runtime. ObjectSpace is a thin wrapper around MRI's memory manager, while on the CLR we don't have access to it. Therefore, it's more MRI's implementation detail than a general Ruby feature. And Ruby library writers already know not to use it if they want to run on all Ruby implementations. That being said, we could implement it poorly and require the user to turn it on if they want to use it (like JRuby does: http://kenai.com/projects/jruby/pages/PerformanceTuning#Disabling_Object Space), but I don't see that as a priority feature. That being said, patches are welcome. If you want to discuss this further, let's move this discussion to the mailing list (ironruby-core at rubyforge.org) or open a new feature request (http://ironruby.codeplex.com/WorkItem/Create). " I think jimmysch is right about the performance issues, but in my case I need to have the ObjectSpace.id2ref because we need to send the object IDs to native languages and retrieve the objects using this object IDs in IronRuby. I think that the JRuby solution (http://kenai.com/projects/jruby/pages/PerformanceTuning#Disabling_Objec tSpace) should be in IronRuby. I've attached my own trick (I think it is a big performance issue). Maybe this could be done in a more better way and directly in IronRuby source code. Thank you! PS: I would like to become a developer in this project. With who should I talk?! Regards, ________________________________ Iulian Fecioru NAPA Romania SRL Lead Software Developer Brailei, 165b, 1 800310, Galati, Romania Mobile: +40-722-664027 Phone: +40-336-802182 Fax: +40-336-802185 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Orion.Edwards at gallagher.co Thu Sep 1 23:54:19 2011 From: Orion.Edwards at gallagher.co (Orion Edwards) Date: Fri, 2 Sep 2011 15:54:19 +1200 Subject: [Ironruby-core] Deadlock in IronRuby Message-ID: I'm encountering what looks like a fairly textbook deadlock in the core IronRuby code when creating Classes: Thread 0: -> calls RubyContext.GetOrCreateClass(Type) - acquires RubyContext.ModuleCacheLock -> function body invokes RubyContext.GetOrCreateClassNoLock(Type) -> The class does not exist, and there are Clr Mixins present, so calls if(clrMixins != null) } using(ClassHierarchyLocker())... - deadlocks trying to acquire RubyContext._classHierarchyLock My Ruby code on this thread is calling .to_module on a CLR type Thread 6: -> Calls RubyContext.GetQualifiedConstant(RubyScope, ConstantSiteCache, string[], bool) -> function body invokes using (context.ClassHierarchyLocker()) - acquires RubyContext._classHierarchyLock -> ... other intermediate calls ... -> calls RubyContext.GetOrCreateModule(NamespaceTracker) - deadlocks trying to acquire RubyContext.ModuleCacheLock This thread is a background thread (pretty sure it's just a regular CLR threadpool thread) which is responding to an event fired by an external application. Basically I have a .NET library which fires events, and I'm subscribing to those events from ruby. The events are normal and boring. It doesn't look like any ruby code on this thread has run yet as it is not mentioned in the callstack. It appears to be trying to get a ruby module or class, perhaps so it can begin running some ruby code. Basically, GetOrCreateClassNoLock is lying to us, and is acquiring a lock in spite of being called "NoLock". The code is complicated enough however that I'm not sure of the best way to resolve it, but the standard deadlock-resolving steps suggest one of these 1. Move the "expandMixins" code outside the "NoLock" method This is the most sensible option, but I've no idea where it could be moved to. 2. Collapse to a single lock (eg: Remove the separate moduleCacheLock and just use _classHierarchyLock for everything) note however there is also a seperate NamespaceCacheLock, ReferenceTypeInstanceDataLock, ValueTypeInstanceDataLock, and perhaps others which would also likely need collapsing. 3. Enforce a lock order such that you must always acquire _classHierarchyLock before acquiring the other locks (if we do this we may as well just collapse the locks as it would be simpler) Is there any performance benefit to be gained from having 5 locks, or would it make more sense to just have a single "TypeSystem" lock ? Hopefully someone with more knowledge of the IronRuby internals can give a better perspective on this. Thanks a lot, Orion Appendix: Here's the output from SOS which illustrates it: I took a memory dump of IR running with -D command line parameter. I built the IronRuby executable off the github master code about 2 months ago, there are no modifications to the code 0:000> !syncblk Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner 112 08ab0780 3 1 08a55e38 148c 6 02608cc8 IronRuby.Runtime.CheckedMonitor 153 08ab0fd4 3 1 004d9d38 1970 0 0260a240 System.Collections.Generic.Dictionary`2[[System.Type, mscorlib],[IronRuby.Builtins.RubyModule, IronRuby]] Callstack for thread 0: 0:000> !clrstack OS Thread Id: 0x1970 (0) Child SP IP Call Site 001fbd4c 77e200ed [GCFrame: 001fbd4c] 001fbed8 77e200ed [GCFrame: 001fbed8] 001fbef4 77e200ed [HelperMethodFrame: 001fbef4] System.Threading.Monitor.ReliableEnter(System.Object, Boolean ByRef) 001fbf44 6fcde0c4 System.Threading.Monitor.Enter(System.Object, Boolean ByRef) 001fbf54 5ea0b8ff IronRuby.Runtime.CheckedMonitor.Enter(Boolean ByRef) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\CheckedMonitor.cs @ 32] 001fbf84 5e9f242b IronRuby.Runtime.RubyContext.GetOrCreateClassNoLock(System.Type) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyContext.cs @ 876] 001fbfd4 5e9f2c40 IronRuby.Runtime.RubyContext.GetOrCreateClass(System.Type) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyContext.cs @ 815] 001fc008 5e9f0dea IronRuby.Runtime.RubyContext.GetModule(System.Type) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyContext.cs @ 1355] 001fc018 0a3ad40d DynamicClass.CallSite.Target(System.Runtime.CompilerServices.Closure, System.Runtime.CompilerServices.CallSite, IronRuby.Runtime.RubyScope, System.Object) 001fc038 099266c7 DynamicClass.??:wrap_method:133:1688:D:/Dev/TestFramework/lib/com_method_gen.rb(System.Runtime.CompilerServices.Closure, IronRuby.Runtime.BlockParam, System.Object, System.Object) 001fc078 5d5dd25f Microsoft.Scripting.Interpreter.LightLambda.Run3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.__Canon, System.__Canon, System.__Canon) 001fc0b4 5eaa1886 IronRuby.Runtime.Calls.BlockDispatcher1.Invoke(IronRuby.Runtime.BlockParam, System.Object, IronRuby.Builtins.Proc, System.Object) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\Calls\BlockDispatchers.cs @ 133] 001fc0c8 5ea2067d IronRuby.Runtime.RubyOps.Yield1(System.Object, IronRuby.Builtins.Proc, System.Object, IronRuby.Runtime.BlockParam) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyOps.cs @ 336] 001fc100 5ea601e6 IronRuby.Runtime.BlockParam.Yield(System.Object, System.Object ByRef) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\BlockParam.cs @ 205] 001fc110 5ecfe2a1 IronRuby.Builtins.Enumerable+<>c__DisplayClassa.b__6(IronRuby.Runtime.BlockParam, System.Object, System.Object) [c:\Dev\ironlanguages-main\Languages\Ruby\Libraries\Builtins\Enumerable.cs @ 117] 001fc12c 5eaa1886 IronRuby.Runtime.Calls.BlockDispatcher1.Invoke(IronRuby.Runtime.BlockParam, System.Object, IronRuby.Builtins.Proc, System.Object) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\Calls\BlockDispatchers.cs @ 133] 001fc140 5ea2067d IronRuby.Runtime.RubyOps.Yield1(System.Object, IronRuby.Builtins.Proc, System.Object, IronRuby.Runtime.BlockParam) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyOps.cs @ 336] 001fc178 5ecea6eb IronRuby.Builtins.IListOps.Each(IronRuby.Runtime.BlockParam, System.Collections.IList) [c:\Dev\ironlanguages-main\Languages\Ruby\Libraries\Extensions\IListOps.cs @ 885] 001fc190 05afe35f DynamicClass.CallSite.Target(System.Runtime.CompilerServices.Closure, System.Runtime.CompilerServices.CallSite, System.Object, IronRuby.Builtins.Proc) 001fc1c8 5ecf2750 IronRuby.Builtins.Enumerable.Each(IronRuby.Runtime.CallSiteStorage`1>, System.Object, IronRuby.Builtins.Proc) [c:\Dev\ironlanguages-main\Languages\Ruby\Libraries\Builtins\Enumerable.cs @ 37] .... elided .... 001fef74 5d61bb5c Microsoft.Scripting.Hosting.Shell.CommandLine.RunFile(Microsoft.Scripting.Hosting.ScriptSource) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Hosting\Shell\CommandLine.cs @ 182] 001fefa4 5eaa641d IronRuby.Hosting.RubyCommandLine.RunFile(System.String) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Hosting\RubyCommandLine.cs @ 69] 001fefb8 5d61bc9c Microsoft.Scripting.Hosting.Shell.CommandLine.Run() [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Hosting\Shell\CommandLine.cs @ 144] 001fefc4 5d61bd4a Microsoft.Scripting.Hosting.Shell.CommandLine.Run(Microsoft.Scripting.Hosting.ScriptEngine, Microsoft.Scripting.Hosting.Shell.IConsole, Microsoft.Scripting.Hosting.Shell.ConsoleOptions) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Hosting\Shell\CommandLine.cs @ 112] 001ff004 5d61d1da Microsoft.Scripting.Hosting.Shell.ConsoleHost.RunCommandLine() [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Hosting\Shell\ConsoleHost.cs @ 402] 001ff040 5d61d577 Microsoft.Scripting.Hosting.Shell.ConsoleHost.ExecuteInternal() [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Hosting\Shell\ConsoleHost.cs @ 337] 001ff04c 5d61d987 Microsoft.Scripting.Hosting.Shell.ConsoleHost.Execute() [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Hosting\Shell\ConsoleHost.cs @ 316] 001ff05c 5d61c9da Microsoft.Scripting.Hosting.Shell.ConsoleHost.Run(System.String[]) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Hosting\Shell\ConsoleHost.cs @ 213] 001ff09c 6eb253e5 Host.Main(System.String[])*** WARNING: Unable to verify checksum for ir.ni.exe [c:\Dev\ironlanguages-main\Languages\Ruby\Console\Program.cs @ 80] Callstack for thread 6: 0:006> !clrstack OS Thread Id: 0x148c (6) Child SP IP Call Site 0955e490 77e200ed [GCFrame: 0955e490] 0955e5a8 77e200ed [GCFrame: 0955e5a8] 0955e5c4 77e200ed [HelperMethodFrame_1OBJ: 0955e5c4] System.Threading.Monitor.ReliableEnter(System.Object, Boolean ByRef) 0955e61c 6fcde0c4 System.Threading.Monitor.Enter(System.Object, Boolean ByRef)*** WARNING: Unable to verify checksum for mscorlib.ni.dll 0955e62c 5e9f2f47 IronRuby.Runtime.RubyContext.GetOrCreateModule(Microsoft.Scripting.Actions.NamespaceTracker)*** WARNING: Unable to verify checksum for IronRuby.ni.dll 0955e660 5e9f011d IronRuby.Runtime.RubyContext.TrackerToModule(System.Object) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyContext.cs @ 1661] 0955e670 5ea15b5e IronRuby.Builtins.RubyModule.TryGetConstantNoAutoloadCheck(System.String, IronRuby.Runtime.ConstantStorage ByRef) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Builtins\RubyModule.cs @ 1132] 0955e698 5ea563a0 IronRuby.Builtins.RubyModule+<>c__DisplayClass6.b__5(IronRuby.Builtins.RubyModule) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Builtins\RubyModule.cs @ 1102] 0955e6a4 5ea15096 IronRuby.Builtins.RubyModule.ForEachDeclaredAncestor(System.Func`2) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Builtins\RubyModule.cs @ 876] 0955e6b8 5ea18026 IronRuby.Builtins.RubyClass.ForEachAncestor(System.Func`2) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Builtins\RubyClass.cs @ 622] 0955e6c8 5ea15a6d IronRuby.Builtins.RubyModule.TryResolveConstantNoAutoloadCheck(Boolean, System.String, IronRuby.Runtime.ConstantStorage ByRef) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Builtins\RubyModule.cs @ 1102] 0955e6e8 5ea15967 IronRuby.Builtins.RubyModule.TryLookupConstantNoLock(Boolean, Boolean, IronRuby.Runtime.RubyGlobalScope, System.String, IronRuby.Runtime.ConstantStorage ByRef) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Builtins\RubyModule.cs @ 1063] 0955e71c 5ea49915 IronRuby.Runtime.RubyScope.TryResolveConstantNoLock(IronRuby.Runtime.RubyGlobalScope, System.String, IronRuby.Runtime.ConstantStorage ByRef) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyScope.cs @ 530] 0955e740 5ea1edd1 IronRuby.Runtime.RubyOps.ResolveQualifiedConstant(IronRuby.Runtime.RubyScope, System.String[], IronRuby.Builtins.RubyModule, Boolean, IronRuby.Runtime.ConstantStorage ByRef, Boolean ByRef) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyOps.cs @ 997] 0955e7b0 5ea1f711 IronRuby.Runtime.RubyOps.GetQualifiedConstant(IronRuby.Runtime.RubyScope, IronRuby.Runtime.ConstantSiteCache, System.String[], Boolean) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyOps.cs @ 811] 0955e808 5eaccd74 Microsoft.Scripting.Interpreter.FuncCallInstruction`5[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.Boolean, mscorlib],[System.__Canon, mscorlib]].Run(Microsoft.Scripting.Interpreter.InterpretedFrame)*** WARNING: Unable to verify checksum for Microsoft.Dynamic.ni.dll [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\Instructions\CallInstruction.Generated.cs @ 764] 0955e840 5d5ae299 Microsoft.Scripting.Interpreter.Interpreter.Run(Microsoft.Scripting.Interpreter.InterpretedFrame) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\Interpreter.cs @ 126] 0955e870 5d5dd2c6 Microsoft.Scripting.Interpreter.LightLambda.Run3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.__Canon, System.__Canon, System.__Canon) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\LightLambda.Generated.cs @ 130] 0955e8ac 5eaa1886 IronRuby.Runtime.Calls.BlockDispatcher1.Invoke(IronRuby.Runtime.BlockParam, System.Object, IronRuby.Builtins.Proc, System.Object) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\Calls\BlockDispatchers.cs @ 133] 0955e8c0 5ea2067d IronRuby.Runtime.RubyOps.Yield1(System.Object, IronRuby.Builtins.Proc, System.Object, IronRuby.Runtime.BlockParam) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyOps.cs @ 336] 0955e8f8 5ecea6eb IronRuby.Builtins.IListOps.Each(IronRuby.Runtime.BlockParam, System.Collections.IList)*** WARNING: Unable to verify checksum for IronRuby.Libraries.ni.dll [c:\Dev\ironlanguages-main\Languages\Ruby\Libraries\Extensions\IListOps.cs @ 885] 0955e910 5d624a86 Microsoft.Scripting.Interpreter.FuncCallInstruction`3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]].Run(Microsoft.Scripting.Interpreter.InterpretedFrame) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\Instructions\CallInstruction.Generated.cs @ 716] 0955e93c 5d5ae299 Microsoft.Scripting.Interpreter.Interpreter.Run(Microsoft.Scripting.Interpreter.InterpretedFrame) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\Interpreter.cs @ 126] 0955e96c 5d5dd649 Microsoft.Scripting.Interpreter.LightLambda.Run4[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.__Canon, System.__Canon, System.__Canon, System.__Canon) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\LightLambda.Generated.cs @ 165] 0955e9ac 6f6ebfc2 System.Dynamic.UpdateDelegates.UpdateAndExecute3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.Runtime.CompilerServices.CallSite, System.__Canon, System.__Canon, System.__Canon)*** WARNING: Unable to verify checksum for System.Core.ni.dll 0955ea08 5d62d2dd Microsoft.Scripting.Interpreter.DynamicInstruction`4[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]].Run(Microsoft.Scripting.Interpreter.InterpretedFrame) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\Instructions\DynamicInstructions.Generated.cs @ 193] 0955ea38 5d5ae299 Microsoft.Scripting.Interpreter.Interpreter.Run(Microsoft.Scripting.Interpreter.InterpretedFrame) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\Interpreter.cs @ 126] 0955ea68 5d5dd649 Microsoft.Scripting.Interpreter.LightLambda.Run4[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.__Canon, System.__Canon, System.__Canon, System.__Canon) [c:\Dev\ironlanguages-main\Runtime\Microsoft.Dynamic\Interpreter\LightLambda.Generated.cs @ 165] 0955eaa8 5eaa1aea IronRuby.Runtime.Calls.BlockDispatcher2.Invoke(IronRuby.Runtime.BlockParam, System.Object, IronRuby.Builtins.Proc, System.Object, System.Object) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\Calls\BlockDispatchers.cs @ 229] 0955eac0 5ea20590 IronRuby.Runtime.RubyOps.Yield2(System.Object, System.Object, IronRuby.Builtins.Proc, System.Object, IronRuby.Runtime.BlockParam) [c:\Dev\ironlanguages-main\Languages\Ruby\Ruby\Runtime\RubyOps.cs @ 362] 0955eafc 0a092f4a DynamicClass.CallSite.Target(System.Runtime.CompilerServices.Closure, System.Runtime.CompilerServices.CallSite, System.Object, System.Object, MyApplication.SomeEventArgs) 0955eb20 6f6ebfc2 System.Dynamic.UpdateDelegates.UpdateAndExecute3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.Runtime.CompilerServices.CallSite, System.__Canon, System.__Canon, System.__Canon) 0955eb7c 05afe257 DynamicClass._Scripting_(System.Object[], System.Object, MyApplication.SomeEventArgs) 0955eb90 098df5fd MyApplication.SomeClass.RaiseEvents(Boolean, System.Collections.Generic.IEnumerable`1) 0955ebd8 098df45f MyApplication.SomeClass.OnEvent(UInt32, Boolean, Boolean, UInt32, MyApplication.DataStruct[]) 0955ec28 098df3c9 DomainBoundILStubClass.IL_STUB_COMtoCLR(Int32, Int32, Int32, Int32, IntPtr) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Orion.Edwards at gallagher.co Mon Sep 5 23:55:59 2011 From: Orion.Edwards at gallagher.co (Orion Edwards) Date: Tue, 6 Sep 2011 15:55:59 +1200 Subject: [Ironruby-core] Deadlock issue Message-ID: I logged an issue on Codeplex (#6449) about the previous deadlock bug I encountered, and I have come up with a patch which should fix the issue, which I've submitted as a pull request: https://github.com/gglresearchanddevelopment/ironlanguages-main/commit/e8be67232d71eb879a1b9487e6fc5e8a93f99266 To explain the patch: I did some more research, and it appears as though there was already a lock order implicitly specified when locking both ClassHierarchyLock and ModuleCacheLock - the hierarchy lock must come first: (refer RubyContext.cs line 1051) I then traced through all the Locks in RubyContext - The majority are simple operations and don't require any modification, so I added comments accordingly I followed the usage of ModuleCacheLock, and made sure the hierarchy lock was acquired first if it might need to be acquired in a nested call. - This amounts to a couple of calls to GetOrCreateClassNoLock, which requires both the module cache lock and the hierarchy lock Also added a comment above ModuleCacheLock explaining the lock order, and a RequiresClassHierarchyLock to GetOrCreateClassNoLock to clarify these things. I've run some heavily multithreaded test code I have and the changes seem to make no appreciable difference to the performance or multi threading capability of IronRuby -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschementi at gmail.com Tue Sep 6 11:25:36 2011 From: jschementi at gmail.com (Jimmy Schementi) Date: Tue, 6 Sep 2011 11:25:36 -0400 Subject: [Ironruby-core] CompiledCode execution + using scope + local variables in a loop => NullReferenceException In-Reply-To: References: Message-ID: <6EE9884B-E30E-4446-B6C8-94892B4C7965@gmail.com> Anton, would prefer a patch, but we can make sure to look into it for the next release. On Aug 2, 2011, at 11:53 AM, Anton Firsov wrote: > Hi, > > I have reported a bug on codeplex: http://ironruby.codeplex.com/workitem/6353 > Will it be fixed in next release? > > Thank you, > Anton > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschementi at gmail.com Tue Sep 6 11:25:36 2011 From: jschementi at gmail.com (Jimmy Schementi) Date: Tue, 6 Sep 2011 11:25:36 -0400 Subject: [Ironruby-core] CompiledCode execution + using scope + local variables in a loop => NullReferenceException In-Reply-To: References: Message-ID: <6EE9884B-E30E-4446-B6C8-94892B4C7965@gmail.com> Anton, would prefer a patch, but we can make sure to look into it for the next release. On Aug 2, 2011, at 11:53 AM, Anton Firsov wrote: > Hi, > > I have reported a bug on codeplex: http://ironruby.codeplex.com/workitem/6353 > Will it be fixed in next release? > > Thank you, > Anton > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ruby-forum.com Tue Sep 6 22:59:14 2011 From: lists at ruby-forum.com (jony bravo) Date: Wed, 07 Sep 2011 04:59:14 +0200 Subject: [Ironruby-core] Win .Net form Message-ID: I am in need of a grid that has a very high performance for my .Net winform application. I already have a solution but it is just too slow and the API doesn?t meet my requirements. Any kind of help will be welcomed. -- Posted via http://www.ruby-forum.com/. From reuben.doetsch at gmail.com Wed Sep 7 00:01:55 2011 From: reuben.doetsch at gmail.com (reuben doetsch) Date: Wed, 7 Sep 2011 00:01:55 -0400 Subject: [Ironruby-core] Win .Net form In-Reply-To: References: Message-ID: Don't use ironruby and use a statically typed .Net language or C++. Reuben Doetsch CTO Sportaneous.com On Tue, Sep 6, 2011 at 10:59 PM, jony bravo wrote: > I am in need of a grid that has a very high performance for my .Net > winform application. I already have a solution but it is just too slow > and the API doesn?t meet my requirements. Any kind of help will be > welcomed. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > From lists at ruby-forum.com Fri Sep 9 02:45:02 2011 From: lists at ruby-forum.com (Benjamin Joldersma) Date: Fri, 09 Sep 2011 08:45:02 +0200 Subject: [Ironruby-core] IronRuby & DynamicObject.TryGetMember returning null Message-ID: I am working with IronRuby and a DynamicObject derived class to create a proxy layer for a game scripting engine that allows me to intercept gets and sets and do things like mark objects for saving, potentially security checks, etc. But I'm finding that if my TryGetMember returns true, but sets the out result param to null, then IronRuby seems to hang indefinitely. I've created a pretty concise repro case here: https://gist.github.com/1205629 can anyone shed some insight into this problem? So far, I'm loving IronRuby. best, --ben joldersma -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Fri Sep 9 03:03:22 2011 From: lists at ruby-forum.com (Benjamin Joldersma) Date: Fri, 09 Sep 2011 09:03:22 +0200 Subject: [Ironruby-core] IronRuby & DynamicObject.TryGetMember returning null In-Reply-To: References: Message-ID: <2db2481ae03fed853eb601215789d24b@ruby-forum.com> Heads up, looks like this applies to the Expando object as well, here's an even simpler gist: https://gist.github.com/1205646 -- Posted via http://www.ruby-forum.com/. From jschementi at gmail.com Fri Sep 9 04:05:46 2011 From: jschementi at gmail.com (Jimmy Schementi) Date: Fri, 9 Sep 2011 04:05:46 -0400 Subject: [Ironruby-core] IronRuby & DynamicObject.TryGetMember returning null In-Reply-To: References: Message-ID: Try implementing TryInvokeMember. In IronRuby "d.foo" actually gets and invokes "foo", so it will use DynamicObject's TryInvokeMember. This is different from IronPython and C# where method calls are two operations: TryGetMember (d.Foo) and TryInvoke (d.Foo()). The rough IronRuby equivalent to this is d.method(:foo).call(). ~js On Sep 9, 2011, at 2:45 AM, Benjamin Joldersma wrote: > I am working with IronRuby and a DynamicObject derived class to create a > proxy layer for a game scripting engine that allows me to intercept gets > and sets and do things like mark objects for saving, potentially > security checks, etc. > > But I'm finding that if my TryGetMember returns true, but sets the out > result param to null, then IronRuby seems to hang indefinitely. > > I've created a pretty concise repro case here: > > https://gist.github.com/1205629 > > can anyone shed some insight into this problem? So far, I'm loving > IronRuby. > > best, > > --ben joldersma > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core From lists at ruby-forum.com Fri Sep 9 20:44:27 2011 From: lists at ruby-forum.com (Benjamin Joldersma) Date: Sat, 10 Sep 2011 02:44:27 +0200 Subject: [Ironruby-core] IronRuby & DynamicObject.TryGetMember returning null In-Reply-To: References: Message-ID: <62ca62b1ffaa00537d519cb18fa4f4df@ruby-forum.com> Okay, very interesting stuff. I had seen you and others suggest that in other places, but I thought I was insulated from it, because I *was* implementing TryInvokeMember! After further examination, I seem to have stumbled to a solution. In my actual code, I was trying to return a function delegate in the TryGetMember, when the member in question is a method. I think that this, coupled with the TryInvokeMember implementation was causing some badness. So I removed the delegate creation code in TryGetMember, and just handle properties, and then in TryInvokeMember, I handle both methods and properties (this seems to work!) Thanks a million for your help! Next problem: I'm hesitant to bring it up again, maybe I should be able to figure this out on my own, but it's stumped me for quite a spell now. I'm getting a System.InvalidOperationException that says "No coercion operator is defined between types 'System.String' and 'IronRuby.Builtins.MutableString'" when I try and call a method on one of my dynamic objects with a literal Ruby string. I've created another gist that reproduces the problem here: https://gist.github.com/1207726 If I write 'test'.to_clr_string, this works, but that seems like kind of a pain to have to do in my scripts... Any ideas about this? The difficult part about it is that it doesn't even seem the runtime even gets to the point where any of my overrides are executed - no breakpoints are hit in MonoDevelop, no console output, so I don't think I can fix it from that vantage point... Any help is much appreciated. best, --ben -- Posted via http://www.ruby-forum.com/.