From jflam at microsoft.com Tue Apr 1 09:59:37 2008 From: jflam at microsoft.com (John Lam (DLR)) Date: Tue, 1 Apr 2008 06:59:37 -0700 Subject: [Ironruby-core] Patch submitted - [#19230] Time implementation In-Reply-To: References: Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91C4F838@NA-EXMSG-C115.redmond.corp.microsoft.com> Thanks for submitting this, Eric! This reminds me that I need to add a simple implementation for ENV as well ... Thanks, -John > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Eric Nicholson > Sent: Monday, March 31, 2008 8:07 PM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] Patch submitted - [#19230] Time > implementation > > Hey Guys, > > Josh Charles put a bug in my ear (thanks Josh!), so I got off my duff > and submitted a patch for the Time class that's been sitting on my > laptop for months. It should have implementations for most of the > basic Time functionality save for the strftime method. It'll pass 22 > of the > 55 time specs. It would pass almost all of them, but the specs depend > on ENV["TZ"] to set the system time zone, which I'm not sure is really > possible on Windows, and seems a little sketchy anyway (who wants > specs monkeying with their system time?). I had more luck with the > JRuby tests when I ran them. > > I hope it's useful for somebody... Cheers! > Eric Nicholson > From angrygreg at gmail.com Tue Apr 1 20:51:42 2008 From: angrygreg at gmail.com (Greg Akins) Date: Tue, 1 Apr 2008 20:51:42 -0400 Subject: [Ironruby-core] General Question on DLR languages In-Reply-To: <50B69702CA6E6D4E849D30CD4989AB8ED80A89C2A6@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <8526685f0803200814v60b03490l573fc909b15dcb71@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D91AA3AB7@NA-EXMSG-C115.redmond.corp.microsoft.com> <8526685f0803200827w56080e51ra3452a6bdc533ed2@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D91AA3AD7@NA-EXMSG-C115.redmond.corp.microsoft.com> <50B69702CA6E6D4E849D30CD4989AB8ED80A89C2A6@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <8526685f0804011751x30e7fdb8w6ec141980626fb8@mail.gmail.com> On Thu, Mar 20, 2008 at 6:36 PM, Shri Borde wrote: > http://blogs.msdn.com/ironpython/archive/2008/03/16/dlr-resources.aspx has a list of resources that would be of use to you. > I've been busy reading these articles, and reading code. While comparing IronRuby and IronPython, I realized that the Microsoft.Scripting is different. My assumption was that part was "the DLR" from Microsoft, so it would be the same across all DLR based languages. Are the differences just version differences? For example, Microsoft.Scripting.Ast.LambdaCompiler is in IronRuby, but not IronPython. -- Greg Akins Software Development Manager SSI Services http://kc.vanadium.com http://www.pghcodingdojo.org http://www.insomnia-consulting.org/monologue From Tomas.Matousek at microsoft.com Tue Apr 1 20:57:38 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Tue, 1 Apr 2008 17:57:38 -0700 Subject: [Ironruby-core] General Question on DLR languages In-Reply-To: <8526685f0804011751x30e7fdb8w6ec141980626fb8@mail.gmail.com> References: <8526685f0803200814v60b03490l573fc909b15dcb71@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D91AA3AB7@NA-EXMSG-C115.redmond.corp.microsoft.com> <8526685f0803200827w56080e51ra3452a6bdc533ed2@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D91AA3AD7@NA-EXMSG-C115.redmond.corp.microsoft.com> <50B69702CA6E6D4E849D30CD4989AB8ED80A89C2A6@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <8526685f0804011751x30e7fdb8w6ec141980626fb8@mail.gmail.com> Message-ID: Yes, they are just different snapshots of the same code base. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Greg Akins Sent: Tuesday, April 01, 2008 5:52 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] General Question on DLR languages On Thu, Mar 20, 2008 at 6:36 PM, Shri Borde wrote: > http://blogs.msdn.com/ironpython/archive/2008/03/16/dlr-resources.aspx has a list of resources that would be of use to you. > I've been busy reading these articles, and reading code. While comparing IronRuby and IronPython, I realized that the Microsoft.Scripting is different. My assumption was that part was "the DLR" from Microsoft, so it would be the same across all DLR based languages. Are the differences just version differences? For example, Microsoft.Scripting.Ast.LambdaCompiler is in IronRuby, but not IronPython. -- Greg Akins Software Development Manager SSI Services http://kc.vanadium.com http://www.pghcodingdojo.org http://www.insomnia-consulting.org/monologue _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From chris at tradeweapon.com Tue Apr 1 21:18:47 2008 From: chris at tradeweapon.com (chris donnan) Date: Tue, 1 Apr 2008 21:18:47 -0400 Subject: [Ironruby-core] I just posted these questions to the forum, then saw Jon lams redirect here... Message-ID: <55964907-60A9-4EAB-94B4-0398A0E7D2C5@tradeweapon.com> Here are my 3 posts: ------------------ How do i unsub from a .net event? if I attach to an event like: grid.new_row do |row| puts row end - how do i unsub from it?? ------------------ If i am accessing a .net api, how do i pass generic args from ruby? ------------------ What is the equivelent of typeof() for getting a type from a .net type. I am trying to script a testing framework for a windows app. I would like to get a hold of its service locator and call its: service = locator.GetService(typeof(Foo)) If i have a handle to the locator in ruby, how do i pass it a .net type like that? From robert.brotherus at napa.fi Wed Apr 2 06:02:04 2008 From: robert.brotherus at napa.fi (Robert Brotherus) Date: Wed, 2 Apr 2008 13:02:04 +0300 Subject: [Ironruby-core] debugging IR References: Message-ID: <53194650933664488F3F0C3A0AB568322286DF@nw60.napa.fi> This is working fine, thanks! Weird spans and conditionals are a minor issue compared to the pain of no debugging at all :-) John: > But it does hit breakpoints and show locals and the call stack correctly Regarding the local variables I did not see any directly in the "Locals" table of Visual Studio, but I was able to dig them up from $frame -> Scope -> Dict -> SymbolAttributes Robert Brotherus Software architect Napa Ltd Email: Robert.Brotherus at napa.fi www.napa.fi _____ From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi Sent: 31. maaliskuuta 2008 13:31 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] debugging IR You have to explicitly tell the DLR to generate "debuggable" code. ScriptRuntime env = ScriptRuntime.Create(setup); env.GlobalOptions.DebugMode = true; ScriptEngine MyEngine = env.GetEngineByFileExtension("rb"); // ... MyEngine.CreateScriptSourceFromFile("MyRuby.rb").Execute(MyScope); Disclaimer: compiled by brain =P ~js On 3/31/08 12:44 AM, "Robert Brotherus" wrote: I have been embedding IronRuby to our WPF C# application, so I am not starting rbx but rather doing calls like: MyEngine.CreateScriptSourceFromFile("MyRuby.rb").Execute(MyScope); Any hope for me to get to use the nice new debugging goodies? :-) I did install the silverlight VS extension, included MyRuby.rb to my C# project and placed breakpoint there, but that did not seem to be enough to have execution stopping there :-( Robert Brotherus -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (DLR) Sent: Thursday, March 27, 2008 6:47 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] debugging IR Debugging support works today in Silverlight as long as you have the Silverlight tools for VS installed. It should just work on desktop CLR as well. Now 'just work' means that our source spans aren't defined precisely which means that stepping over individual statements and in conditionals is, um, weird. But it does hit breakpoints and show locals and the call stack correctly, but I wouldn't really use it for real until we fix how we generate sequence points. Thanks, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080402/2e2bb71e/attachment.html From jflam at microsoft.com Wed Apr 2 09:19:59 2008 From: jflam at microsoft.com (John Lam (DLR)) Date: Wed, 2 Apr 2008 06:19:59 -0700 Subject: [Ironruby-core] I just posted these questions to the forum, then saw Jon lams redirect here... In-Reply-To: <55964907-60A9-4EAB-94B4-0398A0E7D2C5@tradeweapon.com> References: <55964907-60A9-4EAB-94B4-0398A0E7D2C5@tradeweapon.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91CD676E@NA-EXMSG-C115.redmond.corp.microsoft.com> chris donnan: > How do i unsub from a .net event? This is not supported today. > If i am accessing a .net api, how do i pass generic args from ruby? This is also not supported today. > What is the equivelent of typeof() for getting a type from a .net type. > I am trying to script a testing framework for a windows app. I would > like to get a hold of its service locator and call its: > > service = locator.GetService(typeof(Foo)) Foo.to_clr_type Our .NET interop is fairly weak today. Because of our current push to get the language running in time for RailsConf, all .NET interop work is being pushed back into June on our schedule. Thanks, -John From jflam at microsoft.com Wed Apr 2 09:35:50 2008 From: jflam at microsoft.com (John Lam (DLR)) Date: Wed, 2 Apr 2008 06:35:50 -0700 Subject: [Ironruby-core] debugging IR In-Reply-To: <53194650933664488F3F0C3A0AB568322286DF@nw60.napa.fi> References: <53194650933664488F3F0C3A0AB568322286DF@nw60.napa.fi> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91CD677A@NA-EXMSG-C115.redmond.corp.microsoft.com> > Regarding the local variables I did not see any directly in the > "Locals" > table of Visual Studio, but I was able to dig them up from $frame -> > Scope -> Dict -> SymbolAttributes Ah yes- I think this is Tomas' fault due to his latest change in local scopes that are part of the work required to get eval and friends working. I'll let him defend himself here :) Thanks, -John From Tomas.Matousek at microsoft.com Wed Apr 2 12:53:50 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Wed, 2 Apr 2008 09:53:50 -0700 Subject: [Ironruby-core] debugging IR In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D91CD677A@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <53194650933664488F3F0C3A0AB568322286DF@nw60.napa.fi> <372109E149E8084D8E6C7D9CFD82E0632D91CD677A@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: No defense available :) More changes coming soon. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (DLR) Sent: Wednesday, April 02, 2008 6:36 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] debugging IR > Regarding the local variables I did not see any directly in the > "Locals" > table of Visual Studio, but I was able to dig them up from $frame -> > Scope -> Dict -> SymbolAttributes Ah yes- I think this is Tomas' fault due to his latest change in local scopes that are part of the work required to get eval and friends working. I'll let him defend himself here :) Thanks, -John _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From sanxiyn at gmail.com Thu Apr 3 13:35:53 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 4 Apr 2008 02:35:53 +0900 Subject: [Ironruby-core] Using FileUtils Message-ID: <5b0248170804031035s6fd8d414o9ed129e1127e2d01@mail.gmail.com> Let's use FileUtils (instead of rd /s /q, etc.) as Tor erik Linnerud pointed out. http://rubyforge.org/pipermail/ironruby-core/2008-March/001317.html http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/patch-use-fileutils -- Seo Sanghyeon From jflam at microsoft.com Thu Apr 3 13:43:52 2008 From: jflam at microsoft.com (John Lam (DLR)) Date: Thu, 3 Apr 2008 10:43:52 -0700 Subject: [Ironruby-core] Using FileUtils In-Reply-To: <5b0248170804031035s6fd8d414o9ed129e1127e2d01@mail.gmail.com> References: <5b0248170804031035s6fd8d414o9ed129e1127e2d01@mail.gmail.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91CD6EF4@NA-EXMSG-C115.redmond.corp.microsoft.com> Looks good - will apply for next update. Thanks, -John > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Sanghyeon Seo > Sent: Thursday, April 03, 2008 10:36 AM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] Using FileUtils > > Let's use FileUtils (instead of rd /s /q, etc.) as Tor erik Linnerud > pointed out. > http://rubyforge.org/pipermail/ironruby-core/2008-March/001317.html > > http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/patch-use- > fileutils > > -- > Seo Sanghyeon > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core From lists at ruby-forum.com Fri Apr 4 10:43:22 2008 From: lists at ruby-forum.com (Ch Ze) Date: Fri, 4 Apr 2008 16:43:22 +0200 Subject: [Ironruby-core] Problems Compiling IronRuby w/ Mono Message-ID: I've got the following build errors trying to compile IronRuby trunk w/ Mono 1.9 on OSX. Build output: (in /opt/src/mono/ironruby/trunk) Read in 49 resources from '/opt/src/mono/ironruby/trunk/src/microsoft.scripting.core/Resources.resx' Writing resource file... Done. Read in 17 resources from '/opt/src/mono/ironruby/trunk/src/microsoft.scripting.core/math/MathResources.resx' Writing resource file... Done. ./Tuple.cs(212,21): warning CS0219: The variable `argCnt' is assigned but its value is never used ./actions/DynamicSite.Generated.cs(54,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(128,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(202,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(276,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(350,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(424,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(498,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(572,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(646,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(720,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(794,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(868,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(942,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.BigDynamicSite' to `Microsoft.Scripting.Actions.BigDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(1016,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.BigFastDynamicSite' to `Microsoft.Scripting.Actions.BigFastDynamicSiteTarget' Compilation failed: 14 error(s), 1 warnings rake aborted! Command failed with status (1): [gmcs /out:"/opt/src/mono/ironruby/trunk/bu...] /opt/src/mono/ironruby/trunk/rakefile:123 (See full trace by running task with --trace) Mono: Mono JIT compiler version 1.9 (tarball) Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com TLS: normal GC: Included Boehm (with typed GC) SIGSEGV: normal Notification: Thread + polling Architecture: x86 Disabled: none MONO_PATH = /opt/local/ MONO_DISABLE_SHM = 1 Anyone have any ideas what's up? -- Posted via http://www.ruby-forum.com/. From m.david at xmlhacker.com Fri Apr 4 12:56:16 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Fri, 04 Apr 2008 10:56:16 -0600 Subject: [Ironruby-core] Problems Compiling IronRuby w/ Mono In-Reply-To: References: Message-ID: On Fri, 04 Apr 2008 08:43:22 -0600, Ch Ze wrote: > Anyone have any ideas what's up? I run into similar problems last week, though it was related to an ambigous reference to System.Action and Microsoft.Scripting.Utils.Action. The fix for this was going in and manually expanding each reference in the code base. This doesn't seem to be related, but it seems worth pointing out regardless. I haven't tested this on Linux/Mono in recent weeks. Let me try that now and see if the same problem is encountered. Will report back the results shortly. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at xmlhacker.com | m.david at amp.fm | Mobile: (206) 418-9027 Web: http://amp.fm/ | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Fri Apr 4 14:27:51 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Fri, 04 Apr 2008 12:27:51 -0600 Subject: [Ironruby-core] Problems Compiling IronRuby w/ Mono In-Reply-To: References: Message-ID: On Fri, 04 Apr 2008 10:56:16 -0600, M. David Peterson wrote: > Let me try that now and see if the same problem is encountered. Will report back the results shortly. Yep, same issue as your seeing, [mdavid at domU-12-31-39-00-44-51 ironruby]$ mono -V Mono JIT compiler version 1.9 (tarball) Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com TLS: __thread GC: none SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none [mdavid at domU-12-31-39-00-44-51 ironruby]$ rake compile mono=1 (in /mnt/home/mdavid/projects/ironruby) Read in 49 resources from '/mnt/home/mdavid/projects/ironruby/src/microsoft.scripting.core/Resources.resx' Writing resource file... Done. Read in 17 resources from '/mnt/home/mdavid/projects/ironruby/src/microsoft.scripting.core/math/MathResources.resx' Writing resource file... Done. ./Tuple.cs(212,21): warning CS0219: The variable `argCnt' is assigned but its value is never used ./actions/DynamicSite.Generated.cs(54,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(128,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(202,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(276,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(350,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(424,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(498,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(572,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(646,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(720,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(794,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.DynamicSite' to `Microsoft.Scripting.Actions.DynamicSiteTarget' ./actions/DynamicSite.Generated.cs(868,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.FastDynamicSite' to `Microsoft.Scripting.Actions.FastDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(942,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.BigDynamicSite' to `Microsoft.Scripting.Actions.BigDynamicSiteTarget' ./actions/DynamicSite.Generated.cs(1016,13): error CS0029: Cannot implicitly convert type `Microsoft.Scripting.Actions.BigFastDynamicSite' to `Microsoft.Scripting.Actions.BigFastDynamicSiteTarget' Compilation failed: 14 error(s), 1 warnings rake aborted! Command failed with status (1): [gmcs /out:"/mnt/home/mdavid/projects/ironr...] /mnt/home/mdavid/projects/ironruby/Rakefile:123 (See full trace by running task with --trace) -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at xmlhacker.com | m.david at amp.fm | Mobile: (206) 418-9027 Web: http://amp.fm/ | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Fri Apr 4 14:31:18 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Fri, 04 Apr 2008 12:31:18 -0600 Subject: [Ironruby-core] Problems Compiling IronRuby w/ Mono In-Reply-To: References: Message-ID: On Fri, 04 Apr 2008 12:27:51 -0600, M. David Peterson wrote: > Yep, same issue as your seeing, Forgot to include, [mdavid at domU-12-31-39-00-44-51 ironruby]$ uname -a Linux domU-12-31-39-00-44-51 2.6.16.33-xenU #2 SMP Wed Aug 15 17:27:36 SAST 2007 x86_64 GNU/Linux -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at xmlhacker.com | m.david at amp.fm | Mobile: (206) 418-9027 Web: http://amp.fm/ | http://www.oreillynet.com/pub/au/2354 From jflam at microsoft.com Fri Apr 4 14:36:27 2008 From: jflam at microsoft.com (John Lam (DLR)) Date: Fri, 4 Apr 2008 11:36:27 -0700 Subject: [Ironruby-core] Problems Compiling IronRuby w/ Mono In-Reply-To: References: Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91DA37CA@NA-EXMSG-C115.redmond.corp.microsoft.com> FYI - I've pinged Miguel about this. Hope to get an answer soon. Thanks, -John > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of M. David Peterson > Sent: Friday, April 04, 2008 11:31 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Problems Compiling IronRuby w/ Mono > > On Fri, 04 Apr 2008 12:27:51 -0600, M. David Peterson > wrote: > > > Yep, same issue as your seeing, > > Forgot to include, > > [mdavid at domU-12-31-39-00-44-51 ironruby]$ uname -a Linux domU-12-31-39- > 00-44-51 2.6.16.33-xenU #2 SMP Wed Aug 15 17:27:36 SAST 2007 x86_64 > GNU/Linux > > -- > /M:D > > M. David Peterson > Co-Founder & Chief Architect, 3rd&Urban, LLC > Email: m.david at xmlhacker.com | m.david at amp.fm | Mobile: (206) 418-9027 > Web: http://amp.fm/ | http://www.oreillynet.com/pub/au/2354 > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core From m.david at xmlhacker.com Fri Apr 4 14:53:35 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Fri, 04 Apr 2008 12:53:35 -0600 Subject: [Ironruby-core] Problems Compiling IronRuby w/ Mono In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D91DA37CA@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D91DA37CA@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Fri, 04 Apr 2008 12:36:27 -0600, John Lam (DLR) wrote: > FYI - I've pinged Miguel about this. Hope to get an answer soon. Thanks John! Let me know if he wants/needs me to enter a bug into bugzilla. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at xmlhacker.com | m.david at amp.fm | Mobile: (206) 418-9027 Web: http://amp.fm/ | http://www.oreillynet.com/pub/au/2354 From lewistm at gmail.com Fri Apr 4 19:20:48 2008 From: lewistm at gmail.com (Terence Lewis) Date: Sat, 5 Apr 2008 01:20:48 +0200 Subject: [Ironruby-core] BasicSocket.do_not_reverse_lookup patch Message-ID: <2f1decf20804041620u10f7af47w5262d414714abf1d@mail.gmail.com> Hello list, Please find attached a small patch for BasicSocket.do_not_reverse_lookup. Regards Terence -------------- next part -------------- A non-text attachment was scrubbed... Name: do_not_reverse_lookup.patch Type: application/octet-stream Size: 1790 bytes Desc: not available Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080405/cabac8b3/attachment-0001.obj From bacondarwin at googlemail.com Sat Apr 5 02:34:46 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Sat, 5 Apr 2008 07:34:46 +0100 Subject: [Ironruby-core] BasicSocket.do_not_reverse_lookup patch In-Reply-To: <2f1decf20804041620u10f7af47w5262d414714abf1d@mail.gmail.com> References: <2f1decf20804041620u10f7af47w5262d414714abf1d@mail.gmail.com> Message-ID: <000d01c896e7$264ecf50$72ec6df0$@com> Hi Terence, Nice patch. Are you planning to continue to work on the Socket library? I wasn't sure and so I have been doing some work on it. Perhaps we could work together? I started creating some RSpec tests running for the library and added to the functionality you have already produced. I should have a patch of my stuff available next week. Pete -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Terence Lewis Sent: Saturday,05 April 05, 2008 00:21 To: ironruby-core at rubyforge.org Subject: [Ironruby-core] BasicSocket.do_not_reverse_lookup patch Hello list, Please find attached a small patch for BasicSocket.do_not_reverse_lookup. Regards Terence From ivan at flanders.co.nz Sat Apr 5 19:00:25 2008 From: ivan at flanders.co.nz (Ivan Porto Carrero) Date: Sun, 6 Apr 2008 11:00:25 +1200 Subject: [Ironruby-core] Reading files in Dynamic Silverlight Message-ID: Hi I can't work out how I can read external xaml files from Silverlight with IronRuby. I've tried to use System::IO::File and StreamReader but both give me a MethodAccessException. How would I accomplish reading a xaml file in the xap with IronRuby and Silverlight. I would like to create a user control and load that into my main app. System.IO.Stream s = this.GetType().Assembly.GetManifestResourceStream( "story_details_view.xaml") _root = this.InitializeFromXaml(new System.IO.StreamReader(s).ReadToEnd()) as UserControl; I would also like to try to read an external xaml file for skinning purposes. Is that possible at this moment? Cheers Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080406/5b6d5e46/attachment.html From fuzzyman at voidspace.org.uk Sat Apr 5 19:09:26 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 06 Apr 2008 00:09:26 +0100 Subject: [Ironruby-core] Reading files in Dynamic Silverlight In-Reply-To: References: Message-ID: <47F806A6.70100@voidspace.org.uk> Ivan Porto Carrero wrote: > Hi > > I can't work out how I can read external xaml files from Silverlight > with IronRuby. > I've tried to use System::IO::File and StreamReader but both give me a > MethodAccessException. > > How would I accomplish reading a xaml file in the xap with IronRuby > and Silverlight. > > I would like to create a user control and load that into my main app. > > System.IO.Stream s = > this.GetType().Assembly.GetManifestResourceStream("story_details_view.xaml") > > > _root = this.InitializeFromXaml(new > System.IO.StreamReader(s).ReadToEnd()) as UserControl; > > > I would also like to try to read an external xaml file for skinning > purposes. > Is that possible at this moment? > In IronPython you just use the ordinary 'file' type to open a file that is in the 'xap' file as if it was a local resource. You may find that something similar is available in IronRuby. Michael Foord http://www.ironpythoninaction.com > Cheers > Ivan > ------------------------------------------------------------------------ > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > From jflam at microsoft.com Sat Apr 5 21:38:06 2008 From: jflam at microsoft.com (John Lam (DLR)) Date: Sat, 5 Apr 2008 18:38:06 -0700 Subject: [Ironruby-core] Reading files in Dynamic Silverlight In-Reply-To: <47F806A6.70100@voidspace.org.uk> References: <47F806A6.70100@voidspace.org.uk> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91DA3A45@NA-EXMSG-C115.redmond.corp.microsoft.com> Michael Foord: > In IronPython you just use the ordinary 'file' type to open a file that > is in the 'xap' file as if it was a local resource. You may find that > something similar is available in IronRuby. I added this feature to IronPython to support the Peter Norvig spell check demo that we used at MIX. I haven't gotten around to adding that functionality to IronRuby yet - it's on the list of things to do. Thanks, -John From Tomas.Matousek at microsoft.com Sat Apr 5 21:41:14 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Sat, 5 Apr 2008 18:41:14 -0700 Subject: [Ironruby-core] Reading files in Dynamic Silverlight In-Reply-To: <47F806A6.70100@voidspace.org.uk> References: <47F806A6.70100@voidspace.org.uk> Message-ID: It's not currently supported in IronRuby file IO, but here's a workaround (I haven't tried this code in real, so it may not work :). include Microsoft::Scripting::Silverlight runtime = DynamicApplication::Environment stream = runtime.host.platform_adaptation_layer.open_input_file_stream("story_details_view.xaml") stream is instance of the Stream class. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Foord Sent: Saturday, April 05, 2008 4:09 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Reading files in Dynamic Silverlight Ivan Porto Carrero wrote: > Hi > > I can't work out how I can read external xaml files from Silverlight > with IronRuby. > I've tried to use System::IO::File and StreamReader but both give me a > MethodAccessException. > > How would I accomplish reading a xaml file in the xap with IronRuby > and Silverlight. > > I would like to create a user control and load that into my main app. > > System.IO.Stream s = > this.GetType().Assembly.GetManifestResourceStream("story_details_view.xaml") > > > _root = this.InitializeFromXaml(new > System.IO.StreamReader(s).ReadToEnd()) as UserControl; > > > I would also like to try to read an external xaml file for skinning > purposes. > Is that possible at this moment? > In IronPython you just use the ordinary 'file' type to open a file that is in the 'xap' file as if it was a local resource. You may find that something similar is available in IronRuby. Michael Foord http://www.ironpythoninaction.com > Cheers > Ivan > ------------------------------------------------------------------------ > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From bacondarwin at googlemail.com Sun Apr 6 09:46:37 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Sun, 6 Apr 2008 14:46:37 +0100 Subject: [Ironruby-core] Safe Level checking Message-ID: <001101c897ec$a4978a90$edc69fb0$@com> The Sockets library does a lot of Security checking, i.e. Is the SafeLevel too high for this action. It may be helpful to be able to specify this kind of thing as an attribute on the method. Something like: [RubyMethod("getsockopt")] [RubySafeLevel(2)] public static MutableString GetSocketOption(CodeContext/*!*/ context, RubyBasicSocket/*!*/ self, object/*Numeric*/ level, object/*Numeric*/ optname) { Rather than: [RubyMethod("getsockopt")] public static MutableString GetSocketOption(CodeContext/*!*/ context, RubyBasicSocket/*!*/ self, object/*Numeric*/ level, object/*Numeric*/ optname) { Protocols.CheckSafeLevel(context, 2, "getsockopt"); ... } Or maybe even more cleverly integrate it into the .NET security permissions attributes. What do you think? Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080406/b2a80880/attachment.html From Tomas.Matousek at microsoft.com Sun Apr 6 12:24:53 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Sun, 6 Apr 2008 09:24:53 -0700 Subject: [Ironruby-core] Safe Level checking In-Reply-To: <001101c897ec$a4978a90$edc69fb0$@com> References: <001101c897ec$a4978a90$edc69fb0$@com> Message-ID: We don't care about safe level now, so you can just ignore it. I doubt it is necessary to implement this feature at all. IronRuby doesn't contain any unsafe code. Hence CLR checks are always present regardless of what we check, so your code cannot do anything that is disallowed by CLR security system. We can only disable Ruby calls to some methods. And that would be a real security restriction only in a mode that would disable all .NET calls, because otherwise you could always call your C# code that performs the call. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: Sunday, April 06, 2008 6:47 AM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Safe Level checking The Sockets library does a lot of Security checking, i.e. Is the SafeLevel too high for this action. It may be helpful to be able to specify this kind of thing as an attribute on the method. Something like: [RubyMethod("getsockopt")] [RubySafeLevel(2)] public static MutableString GetSocketOption(CodeContext/*!*/ context, RubyBasicSocket/*!*/ self, object/*Numeric*/ level, object/*Numeric*/ optname) { Rather than: [RubyMethod("getsockopt")] public static MutableString GetSocketOption(CodeContext/*!*/ context, RubyBasicSocket/*!*/ self, object/*Numeric*/ level, object/*Numeric*/ optname) { Protocols.CheckSafeLevel(context, 2, "getsockopt"); ... } Or maybe even more cleverly integrate it into the .NET security permissions attributes. What do you think? Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080406/07a9cec1/attachment-0001.html From bacondarwin at googlemail.com Sun Apr 6 14:13:03 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Sun, 6 Apr 2008 19:13:03 +0100 Subject: [Ironruby-core] Safe Level checking In-Reply-To: References: <001101c897ec$a4978a90$edc69fb0$@com> Message-ID: <000a01c89811$ddebe730$99c3b590$@com> OK that makes sense. Does it apply to tainting objects too? Pete From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek Sent: Sunday,06 April 06, 2008 17:25 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Safe Level checking We don't care about safe level now, so you can just ignore it. I doubt it is necessary to implement this feature at all. IronRuby doesn't contain any unsafe code. Hence CLR checks are always present regardless of what we check, so your code cannot do anything that is disallowed by CLR security system. We can only disable Ruby calls to some methods. And that would be a real security restriction only in a mode that would disable all .NET calls, because otherwise you could always call your C# code that performs the call. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: Sunday, April 06, 2008 6:47 AM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Safe Level checking The Sockets library does a lot of Security checking, i.e. Is the SafeLevel too high for this action. It may be helpful to be able to specify this kind of thing as an attribute on the method. Something like: [RubyMethod("getsockopt")] [RubySafeLevel(2)] public static MutableString GetSocketOption(CodeContext/*!*/ context, RubyBasicSocket/*!*/ self, object/*Numeric*/ level, object/*Numeric*/ optname) { Rather than: [RubyMethod("getsockopt")] public static MutableString GetSocketOption(CodeContext/*!*/ context, RubyBasicSocket/*!*/ self, object/*Numeric*/ level, object/*Numeric*/ optname) { Protocols.CheckSafeLevel(context, 2, "getsockopt"); ... } Or maybe even more cleverly integrate it into the .NET security permissions attributes. What do you think? Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080406/57964f5b/attachment.html From jflam at microsoft.com Sun Apr 6 14:26:15 2008 From: jflam at microsoft.com (John Lam (DLR)) Date: Sun, 6 Apr 2008 11:26:15 -0700 Subject: [Ironruby-core] Safe Level checking Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D9132409F@NA-EXMSG-C115.redmond.corp.microsoft.com> We need to respect tainting because tons of specs test for correct behavior. - John Sent from my phone ________________________________ From: Peter Bacon Darwin Sent: Sunday, April 06, 2008 11:13 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Safe Level checking OK that makes sense. Does it apply to tainting objects too? Pete From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek Sent: Sunday,06 April 06, 2008 17:25 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Safe Level checking We don?t care about safe level now, so you can just ignore it. I doubt it is necessary to implement this feature at all. IronRuby doesn?t contain any unsafe code. Hence CLR checks are always present regardless of what we check, so your code cannot do anything that is disallowed by CLR security system. We can only disable Ruby calls to some methods. And that would be a real security restriction only in a mode that would disable all .NET calls, because otherwise you could always call your C# code that performs the call. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: Sunday, April 06, 2008 6:47 AM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Safe Level checking The Sockets library does a lot of Security checking, i.e. Is the SafeLevel too high for this action. It may be helpful to be able to specify this kind of thing as an attribute on the method. Something like: [RubyMethod("getsockopt")] [RubySafeLevel(2)] public static MutableString GetSocketOption(CodeContext/*!*/ context, RubyBasicSocket/*!*/ self, object/*Numeric*/ level, object/*Numeric*/ optname) { Rather than: [RubyMethod("getsockopt")] public static MutableString GetSocketOption(CodeContext/*!*/ context, RubyBasicSocket/*!*/ self, object/*Numeric*/ level, object/*Numeric*/ optname) { Protocols.CheckSafeLevel(context, 2, "getsockopt"); ... } Or maybe even more cleverly integrate it into the .NET security permissions attributes. What do you think? Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080406/72a27389/attachment.html From jomes at microsoft.com Sun Apr 6 17:15:48 2008 From: jomes at microsoft.com (John Messerly) Date: Sun, 6 Apr 2008 14:15:48 -0700 Subject: [Ironruby-core] Reading files in Dynamic Silverlight In-Reply-To: References: Message-ID: <918705E903F4714CB713D89AB5F1857D73CF8D9AC5@NA-EXMSG-C116.redmond.corp.microsoft.com> Ivan Porto Carrero: > I can't work out how I can read external xaml files from Silverlight > with IronRuby. > I've tried to use System::IO::File and StreamReader but both give me a > MethodAccessException. > > How would I accomplish reading a xaml file in the xap with IronRuby > and Silverlight. > > I would like to create a user control and load that into my main app. > > System.IO.Stream s = this.GetType().Assembly.GetManifestResourceStream("story_details_view.xaml") > > _root = this.InitializeFromXaml(new > System.IO.StreamReader(s).ReadToEnd()) as UserControl; I'm not sure why the above C# code wouldn't "just work". Which method call throws MethodAccessException? The only thing that looks odd is the GetManifestResourceStream. The way I've done it is: s = System.Windows.Application.Current.GetResourceStream(new Uri("story_details_view.xaml", UriKind.Relative)); > I would also like to try to read an external xaml file for skinning > purposes. > Is that possible at this moment? Sure, just use the normal Silverlight downloading APIs. Check out the WebClient and HttpWebRequest classes. - John From lewistm at gmail.com Mon Apr 7 04:31:13 2008 From: lewistm at gmail.com (Terence Lewis) Date: Mon, 7 Apr 2008 10:31:13 +0200 Subject: [Ironruby-core] BasicSocket.do_not_reverse_lookup patch In-Reply-To: <000d01c896e7$264ecf50$72ec6df0$@com> References: <2f1decf20804041620u10f7af47w5262d414714abf1d@mail.gmail.com> <000d01c896e7$264ecf50$72ec6df0$@com> Message-ID: <2f1decf20804070131m25172fe7v36ac901e6dafcbf3@mail.gmail.com> Hi Peter, I am planning to continue working on it, as time permits. Unfortunately, the real world has interfered with my plans to work on it over the past couple of months, and it looks like I will continue to struggle to find enough time for it going forwards, so I'm happy to hold off for now - at least until you've released the stuff you've been working on. Thanks for the heads up. Terence On Sat, Apr 5, 2008 at 8:34 AM, Peter Bacon Darwin wrote: > Hi Terence, > Nice patch. > Are you planning to continue to work on the Socket library? I wasn't sure > and so I have been doing some work on it. Perhaps we could work together? > I started creating some RSpec tests running for the library and added to the > functionality you have already produced. > I should have a patch of my stuff available next week. > Pete > > > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Terence Lewis > Sent: Saturday,05 April 05, 2008 00:21 > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] BasicSocket.do_not_reverse_lookup patch > > Hello list, > > Please find attached a small patch for BasicSocket.do_not_reverse_lookup. > > > Regards > > > Terence > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > From thibaut.barrere at gmail.com Tue Apr 8 08:16:21 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Tue, 8 Apr 2008 14:16:21 +0200 Subject: [Ironruby-core] Manipulating Silverlight controls dynamically from IronRuby - is it currently possible ? Message-ID: <4a68b8cf0804080516n2a872d3fs88af9886bb4e1435@mail.gmail.com> Hi, Is it currently possible to add children to an existing Silverlight control from the ruby code side ? (like in the IronPython version seen on http://www.voidspace.org.uk/ironpython/webide/webide.html - great stuff btw Michael!) And an extra question: is the Button control available from the silverlight build on http://dynamicsilverlight.net ? cheers, -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080408/f3046871/attachment.html From ivan at flanders.co.nz Tue Apr 8 08:25:47 2008 From: ivan at flanders.co.nz (Ivan Porto Carrero) Date: Wed, 9 Apr 2008 00:25:47 +1200 Subject: [Ironruby-core] Manipulating Silverlight controls dynamically from IronRuby - is it currently possible ? In-Reply-To: <4a68b8cf0804080516n2a872d3fs88af9886bb4e1435@mail.gmail.com> References: <4a68b8cf0804080516n2a872d3fs88af9886bb4e1435@mail.gmail.com> Message-ID: Hi Yes the button control is available. The code that goes with that blog post uses a button. I want to improve that code still because you can do more with IronRuby than that. I just need some time to do it. http://flanders.co.nz/2008/04/06/an-ironruby-digg-client/ Basically you need to add the assemblies System.Windows.Controls and System.Windows.Controls.Extended to your app folder. You can find those assemblies in program files\microsoft sdks\Silverlight\v2.0 You also need to add a AppManifest.xaml file to your app folder and that should contain: from then on you can use the button control but you still need to add the namespace to your xaml file. I have this for a button. hth Ivan On Wed, Apr 9, 2008 at 12:16 AM, Thibaut Barr?re wrote: > Hi, > > Is it currently possible to add children to an existing Silverlight > control from the ruby code side ? (like in the IronPython version seen on > http://www.voidspace.org.uk/ironpython/webide/webide.html - great stuff > btw Michael!) > > And an extra question: is the Button control available from the > silverlight build on http://dynamicsilverlight.net ? > > cheers, > > -- Thibaut > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/11c3a475/attachment.html From thibaut.barrere at gmail.com Tue Apr 8 08:42:06 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Tue, 8 Apr 2008 14:42:06 +0200 Subject: [Ironruby-core] Manipulating Silverlight controls dynamically from IronRuby - is it currently possible ? In-Reply-To: References: <4a68b8cf0804080516n2a872d3fs88af9886bb4e1435@mail.gmail.com> Message-ID: <4a68b8cf0804080542l77e76679xf760b742747d62c9@mail.gmail.com> Hi Ivan, thanks a lot for all this, that will definitely be useful! > Is it currently possible to add children to an existing Silverlight control from the ruby code side ? Any hint most welcome on that point too ! cheers -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080408/aaf92754/attachment.html From thibaut.barrere at gmail.com Tue Apr 8 10:03:59 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Tue, 8 Apr 2008 16:03:59 +0200 Subject: [Ironruby-core] IronRuby with Silverlight question Message-ID: <4a68b8cf0804080703m680c7297yb77c252581c898b8@mail.gmail.com> Hi I'm not sure ironruby-core is the right place for such a question, although I don't know about any other forum. Is it adequate to post this here ? My question is : I'm wondering if the following code can be simplified: ======================= include System::Windows include System::Windows::Controls root = Application.Current.LoadRootVisual(UserControl.new(), "app.xaml") root.find_name('HelloLabel').mouse_left_button_down do |sender,args| sender.text = "#{sender.text} - Hello from IronRuby !" end ======================= Specifically the root loading seems a bit overly complicated at first (I could move this to a helper function though). As well I'm wondering if it's somehow possible to have a root.hello_label which would map to find_name("HelloLabel") - this could be implemented using method_missing; maybe there is already an existing helper to do that ? any advice will be most welcome! cheers Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080408/22257943/attachment.html From jflam at microsoft.com Tue Apr 8 10:12:45 2008 From: jflam at microsoft.com (John Lam (DLR)) Date: Tue, 8 Apr 2008 07:12:45 -0700 Subject: [Ironruby-core] IronRuby with Silverlight question In-Reply-To: <4a68b8cf0804080703m680c7297yb77c252581c898b8@mail.gmail.com> References: <4a68b8cf0804080703m680c7297yb77c252581c898b8@mail.gmail.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91DA4119@NA-EXMSG-C115.redmond.corp.microsoft.com> Have you looked at silverlight.rb from our http://dynamicsilverlight.net samples? If it's not there, look at the Part 3 sample from my intro to Ruby + Silverlight blog post: http://www.iunknown.com/2008/03/dynamic-silve-2.html Thanks, -John > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Thibaut Barr?re > Sent: Tuesday, April 08, 2008 7:04 AM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] IronRuby with Silverlight question > > Hi > > I'm not sure ironruby-core is the right place for such a question, > although I don't know about any other forum. Is it adequate to post > this here ? > > My question is : I'm wondering if the following code can be simplified: > > ======================= > include System::Windows > include System::Windows::Controls > > root = Application.Current.LoadRootVisual(UserControl.new(), > "app.xaml") > > root.find_name('HelloLabel').mouse_left_button_down do |sender,args| > sender.text = "#{sender.text} - Hello from IronRuby !" > end > ======================= > > Specifically the root loading seems a bit overly complicated at first > (I could move this to a helper function though). > > As well I'm wondering if it's somehow possible to have a > root.hello_label which would map to find_name("HelloLabel") - this > could be implemented using method_missing; maybe there is already an > existing helper to do that ? > > any advice will be most welcome! > > cheers > > Thibaut From thibaut.barrere at gmail.com Tue Apr 8 10:47:45 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Tue, 8 Apr 2008 16:47:45 +0200 Subject: [Ironruby-core] IronRuby with Silverlight question In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D91DA4119@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <4a68b8cf0804080703m680c7297yb77c252581c898b8@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D91DA4119@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <4a68b8cf0804080747r33f4d6bfv25041fd0067f377e@mail.gmail.com> > Have you looked at silverlight.rb from our http://dynamicsilverlight.netsamples? It's all there - thanks for the link! cheers Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080408/f6d7d987/attachment.html From jflam at microsoft.com Tue Apr 8 16:48:52 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 8 Apr 2008 13:48:52 -0700 Subject: [Ironruby-core] SVN r93 is up Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91DA448D@NA-EXMSG-C115.redmond.corp.microsoft.com> We now pass 1541/2468 specs (62%). A bunch of String specs were re-enabled since we no longer crash when parsing them. Work is still ongoing to start running the trunk rubinius specs, but we need some more features in the libs first (the rubinius spec rewrite uses some standard libraries that we don't fully support yet). ENV is now partially implemented - you can evaluate environment variables correctly now. A bunch of regex functionality (still using .NET regex) is enabled - =~, sub,gsub etc. are now implemented in this release. There was a split in the way the DLR is organized. Microsoft.Scripting.Core.dll is the DLR, and Microsoft.Scripting.dll are where libraries like the Math libraries for the DLR will live from now on. Thanks, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080408/f334c8eb/attachment-0001.html From w.kelly at qut.edu.au Wed Apr 9 03:51:20 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Wed, 9 Apr 2008 17:51:20 +1000 Subject: [Ironruby-core] running gems setup.rb with revision93 In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D91DA448D@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D91DA448D@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2CB7F2F7@QUTEXMBX02.qut.edu.au> With a new version out, I thought I'd try again to see how far I could get gems setup.rb to run ... 1) missing method Regex.quote - see implementation in attached patch 2) Exception thrown in ModuleOps.Evaluate - "We need ScriptCode.Run to be public" - uncommented the excluded code and made ScriptCode.Run public 3) Time.to_i not implemented - applied Eric Nicholson's patch 4) Time.gmt_offset not implemented - see implementation in attached patch (includes Eric's patch) 5) MutableString.intern not implemented - aliased MutableString.to_sym to intern 6) Exception thrown stating that ">= 0" is an illformed requirement - case statement failed because Regex.=== wasn't implemented, see implementation in attached patch 7) The regular expression still doesn't match due to a regular expression substitution problem - the following simple example illustrates the problem (it should match but doesn't): x = /a/ regex = /#{x}/ puts regex =~ 'a' Cheers, Wayne. -------------- next part -------------- A non-text attachment was scrubbed... Name: Time_gmt_offset.patch Type: application/octet-stream Size: 12261 bytes Desc: Time_gmt_offset.patch Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/25a63de0/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: MutableString_intern.patch Type: application/octet-stream Size: 509 bytes Desc: MutableString_intern.patch Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/25a63de0/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Regexp.patch Type: application/octet-stream Size: 2598 bytes Desc: Regexp.patch Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/25a63de0/attachment-0002.obj From angrygreg at gmail.com Wed Apr 9 08:51:08 2008 From: angrygreg at gmail.com (Greg Akins) Date: Wed, 9 Apr 2008 08:51:08 -0400 Subject: [Ironruby-core] r93 update Message-ID: <8526685f0804090551p3c1b5a72pf01b2148d648b22b@mail.gmail.com> I had written a small "hello world" app that read a ruby file, using IronRuby. It used this "puts \"Ruby and ${variable} together at last\"" where "variable" is a global assigned in the C# program. The program I'd written stopped compiling after the update so I looked on the Wiki for changes. The Wiki shows this example http://ironruby.rubyforge.org/wiki/wiki.pl?ExecutingIronRubyFromCSharp >From that example, this line ctx.GlobalVariables[SymbolTable.StringToId("variable")] = ".NET"; doesn't work because the index on GlobalVariables has changed to a KeyValuePair A, I'm confused about how to create a GlobalVariable object to put in that collection. B, I'm unsure if I'm headed down the right path, given the changes to the API. Is there a "New" way to assigned global variables? Any help is greatly appreciated. -- Greg Akins Software Development Manager SSI Services http://kc.vanadium.com http://www.pghcodingdojo.org http://www.insomnia-consulting.org/monologue From robert.brotherus at napa.fi Wed Apr 9 11:54:54 2008 From: robert.brotherus at napa.fi (Robert Brotherus) Date: Wed, 9 Apr 2008 18:54:54 +0300 Subject: [Ironruby-core] r93 update References: <8526685f0804090551p3c1b5a72pf01b2148d648b22b@mail.gmail.com> Message-ID: <53194650933664488F3F0C3A0AB568322C6B0B@nw60.napa.fi> I have had following working ok with the recent IR iterations: public object GetGlobalVar(string varName) { return ExecutionContext.GetGlobalVariable(varName); } public void SetGlobalVar(string varName, object value) { ExecutionContext.DefineGlobalVariable(varName, value); } It indeed changed few iterations ago and broke my earlier code as well. Robert Brotherus Software architect Napa Ltd Tammasaarenkatu 3, Helsinki FI-00180 P.O.Box 470, Helsinki FI-00181 Tel. +358 9 22 813 1 Direct. +358 9 22 813 611 GSM +358 45 11 456 02 Fax. +358 9 22 813 800 Email: Robert.Brotherus at napa.fi www.napa.fi -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Greg Akins Sent: 9. huhtikuuta 2008 15:51 To: ironruby-core at rubyforge.org Subject: [Ironruby-core] r93 update I had written a small "hello world" app that read a ruby file, using IronRuby. It used this "puts \"Ruby and ${variable} together at last\"" where "variable" is a global assigned in the C# program. The program I'd written stopped compiling after the update so I looked on the Wiki for changes. The Wiki shows this example http://ironruby.rubyforge.org/wiki/wiki.pl?ExecutingIronRubyFromCSharp >From that example, this line ctx.GlobalVariables[SymbolTable.StringToId("variable")] = ".NET"; doesn't work because the index on GlobalVariables has changed to a KeyValuePair A, I'm confused about how to create a GlobalVariable object to put in that collection. B, I'm unsure if I'm headed down the right path, given the changes to the API. Is there a "New" way to assigned global variables? Any help is greatly appreciated. -- Greg Akins Software Development Manager SSI Services http://kc.vanadium.com http://www.pghcodingdojo.org http://www.insomnia-consulting.org/monologue _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From sanxiyn at gmail.com Wed Apr 9 12:12:13 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 10 Apr 2008 01:12:13 +0900 Subject: [Ironruby-core] System.Action name collision Message-ID: <5b0248170804090912h2cdafaadvd6e258df07835232@mail.gmail.com> Cross-posting to mono-dev and ironruby-core. System.Action delegate types (and its generic versions) were newly introduced in .NET 3.5, and they live inside System.Core.dll. Dynamic Language Runtime wants to run on .NET 2.0, so it has its own version of these simple classes as Microsoft.Scripting.Utils.Action (and its generic versions). Now Mono 1.9's C# compiler defaults to C# 3.0 mode, and to quote, "the System.Core.dll assembly is now referenced and this might cause some type ambiguities, in particular with the "Action" type (System.Action from System.Core vs Gtk.Action for example). The fix is to either use fully qualified names for Gtk.Action, or to use namespace aliases." (See Mono release note.) Many IronRuby source files do both "using System" and "using Microsoft.Scripting.Utils", and name collision happens. Now Gtk.Action is annoying, but using fully qualified Microsoft.Scripting.Utils.Action is horrifying. Using "using alias directive" won't work with generics. C# Language Specification ECMA-334 25.5.7 specifically disallows this. This is logged as Microsoft Connect Feedback 93520 which is closed as "postponed" since 2004. http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93520 I can live with substituting all occurences of Action class, but I wonder if any of you have better idea. -- Seo Sanghyeon From jb at nurv.fr Wed Apr 9 13:03:31 2008 From: jb at nurv.fr (Jb Evain) Date: Wed, 9 Apr 2008 19:03:31 +0200 Subject: [Ironruby-core] [Mono-dev] System.Action name collision In-Reply-To: <5b0248170804090912h2cdafaadvd6e258df07835232@mail.gmail.com> References: <5b0248170804090912h2cdafaadvd6e258df07835232@mail.gmail.com> Message-ID: <69f7d8470804091003w5623494en4a3585722dbf3edd@mail.gmail.com> Hey, On 4/9/08, Sanghyeon Seo wrote: > Now Mono 1.9's C# compiler defaults to C# 3.0 mode, and to quote, "the > System.Core.dll assembly is now referenced and this might cause some > type ambiguities, in particular with the "Action" type (System.Action > from System.Core vs Gtk.Action for example). The fix is to either use > fully qualified names for Gtk.Action, or to use namespace aliases." > (See Mono release note.) It's worth noting that it's not just a Mono issue. You'll have the exact same issue as soon as you'll compile on csc 3.5, as discussed in a previous thread. -- Jb Evain From sanxiyn at gmail.com Wed Apr 9 14:10:22 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 10 Apr 2008 03:10:22 +0900 Subject: [Ironruby-core] IronRuby r93 on Mono Message-ID: <5b0248170804091110o5a696235wa6ab56933e899e2a@mail.gmail.com> I updated HOWTO and patches. http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/ To quote: "Previously, you had to build Mono from SVN. Instruction is still provided below in case it is needed again. But you can use Mono 1.9 release just fine." Hooray! patch-mono-r93 adds "noconfig" switch on Mono to resolve System.Action name collision, as recommended by Mono developers. -- Seo Sanghyeon From angrygreg at gmail.com Wed Apr 9 14:18:14 2008 From: angrygreg at gmail.com (Greg Akins) Date: Wed, 9 Apr 2008 14:18:14 -0400 Subject: [Ironruby-core] r93 update In-Reply-To: <53194650933664488F3F0C3A0AB568322C6B0B@nw60.napa.fi> References: <8526685f0804090551p3c1b5a72pf01b2148d648b22b@mail.gmail.com> <53194650933664488F3F0C3A0AB568322C6B0B@nw60.napa.fi> Message-ID: <8526685f0804091118g772b900cxb028920b1d6b9caa@mail.gmail.com> On Wed, Apr 9, 2008 at 11:54 AM, Robert Brotherus wrote: > I have had following working ok with the recent IR iterations: > > public object GetGlobalVar(string varName) > { > return ExecutionContext.GetGlobalVariable(varName); > } > > public void SetGlobalVar(string varName, object value) > { > ExecutionContext.DefineGlobalVariable(varName, value); > } > > It indeed changed few iterations ago and broke my earlier code as well. Thanks. That also helped me find some relevant tests that gave me a little more information about what's happening there. I appreciate your help. -- Greg Akins Software Development Manager SSI Services http://kc.vanadium.com http://www.pghcodingdojo.org http://www.insomnia-consulting.org/monologue From thibaut.barrere at gmail.com Wed Apr 9 14:27:08 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Wed, 9 Apr 2008 20:27:08 +0200 Subject: [Ironruby-core] IronRuby r93 on Mono In-Reply-To: <5b0248170804091110o5a696235wa6ab56933e899e2a@mail.gmail.com> References: <5b0248170804091110o5a696235wa6ab56933e899e2a@mail.gmail.com> Message-ID: <4a68b8cf0804091127p5d4ebb7bo35a64eb2adff6920@mail.gmail.com> > To quote: "Previously, you had to build Mono from SVN. Instruction is > still provided > below in case it is needed again. But you can use Mono 1.9 release just > fine." Hooray! That's great news! thanks -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/bce6e12c/attachment.html From jflam at microsoft.com Wed Apr 9 14:28:24 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Wed, 9 Apr 2008 11:28:24 -0700 Subject: [Ironruby-core] [Fwd: FW: Problems Compiling IronRuby w/ Mono] In-Reply-To: <47FCEAC1.9000704@novell.com> References: <1207755703.25770.0.camel@linux.site> <47FCEAC1.9000704@novell.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91E1FB13@NA-EXMSG-C115.redmond.corp.microsoft.com> Sorry - I don't have Mono installed here so I can't repro - I'm cc'ing our mailing list to see if you can't work it out with those folks. Thanks, -John -----Original Message----- From: Marc Christensen [mailto:mchristensen at novell.com] Sent: Wednesday, April 09, 2008 9:12 AM To: John Lam (IRONRUBY) Subject: Re: [Fwd: FW: [Ironruby-core] Problems Compiling IronRuby w/ Mono] Hey John, Miguel asked me to look into the IronRuby failure you are seeing on Mono. How are you compiling IronRuby on mono? Are you using mdtool, monodevelop, rake? I tried with mdtool: "mdtool build -f:IronRuby.sln" and got different failures that you did. I'm actually getting a failure that Silverlight is not installed. I was wondering if silverlight/moonlight is required or not. Thanks. -- Marc Miguel de Icaza wrote: > > ------------------------------------------------------------------------ > > Subject: > FW: [Ironruby-core] Problems Compiling IronRuby w/ Mono > From: > "John Lam (DLR)" > Date: > Fri, 4 Apr 2008 08:03:44 -0700 > To: > "miguel at gnome.org" > > To: > "miguel at gnome.org" > > > Hey Miguel, Any ideas here? This just showed up on my list. > > Thanks, > -John > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ch Ze > Sent: Friday, April 04, 2008 7:43 AM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] Problems Compiling IronRuby w/ Mono > > I've got the following build errors trying to compile IronRuby trunk w/ > Mono 1.9 on OSX. > > Build output: > > (in /opt/src/mono/ironruby/trunk) > Read in 49 resources from > '/opt/src/mono/ironruby/trunk/src/microsoft.scripting.core/Resources.resx' > Writing resource file... Done. > Read in 17 resources from > '/opt/src/mono/ironruby/trunk/src/microsoft.scripting.core/math/MathResources.resx' > Writing resource file... Done. > ./Tuple.cs(212,21): warning CS0219: The variable `argCnt' is assigned > but its value is never used > ./actions/DynamicSite.Generated.cs(54,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.DynamicSite' to > `Microsoft.Scripting.Actions.DynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(128,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.FastDynamicSite' to > `Microsoft.Scripting.Actions.FastDynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(202,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.DynamicSite' to > `Microsoft.Scripting.Actions.DynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(276,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.FastDynamicSite' to > `Microsoft.Scripting.Actions.FastDynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(350,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.DynamicSite' to > `Microsoft.Scripting.Actions.DynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(424,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.FastDynamicSite' to > `Microsoft.Scripting.Actions.FastDynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(498,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.DynamicSite' to > `Microsoft.Scripting.Actions.DynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(572,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.FastDynamicSite' to > `Microsoft.Scripting.Actions.FastDynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(646,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.DynamicSite' to > `Microsoft.Scripting.Actions.DynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(720,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.FastDynamicSite' to > `Microsoft.Scripting.Actions.FastDynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(794,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.DynamicSite' to > `Microsoft.Scripting.Actions.DynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(868,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.FastDynamicSite' to > `Microsoft.Scripting.Actions.FastDynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(942,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.BigDynamicSite' to > `Microsoft.Scripting.Actions.BigDynamicSiteTarget' > ./actions/DynamicSite.Generated.cs(1016,13): error CS0029: Cannot > implicitly convert type > `Microsoft.Scripting.Actions.BigFastDynamicSite' to > `Microsoft.Scripting.Actions.BigFastDynamicSiteTarget' > Compilation failed: 14 error(s), 1 warnings > rake aborted! > Command failed with status (1): [gmcs > /out:"/opt/src/mono/ironruby/trunk/bu...] > /opt/src/mono/ironruby/trunk/rakefile:123 > (See full trace by running task with --trace) > > > Mono: > Mono JIT compiler version 1.9 (tarball) > Copyright (C) 2002-2007 Novell, Inc and Contributors. > www.mono-project.com > TLS: normal > GC: Included Boehm (with typed GC) > SIGSEGV: normal > Notification: Thread + polling > Architecture: x86 > Disabled: none > > > MONO_PATH = /opt/local/ > MONO_DISABLE_SHM = 1 > > Anyone have any ideas what's up? > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core From sanxiyn at gmail.com Wed Apr 9 14:37:48 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 10 Apr 2008 03:37:48 +0900 Subject: [Ironruby-core] [Fwd: FW: Problems Compiling IronRuby w/ Mono] In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D91E1FB13@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <1207755703.25770.0.camel@linux.site> <47FCEAC1.9000704@novell.com> <372109E149E8084D8E6C7D9CFD82E0632D91E1FB13@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <5b0248170804091137p444ce85fmdef41224d858781a@mail.gmail.com> > Miguel asked me to look into the IronRuby failure you are seeing on > Mono. How are you compiling IronRuby on mono? Are you using mdtool, > monodevelop, rake? I tried with mdtool: "mdtool build -f:IronRuby.sln" > and got different failures that you did. I use "rake compile mono=1", and I believe it is the intended way to build IronRuby on Mono. But then, I believe I already resolved this problem with help of people on #mono IRC channel... -- Seo Sanghyeon From thibaut.barrere at gmail.com Wed Apr 9 17:58:13 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Wed, 9 Apr 2008 23:58:13 +0200 Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? Message-ID: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> Hi, I followed the debugging guidelines provided at the bottom of http://silverlight.net/Quickstarts/ProgramDlr.aspx but could not get them to work so far. My breakpoints in VisualStudio 2008 keep their label "This breakpoint will currently not be hit. No executable code is associated with this line". Should a specific project type or project settings be used to get this working ? thanks, -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/2d15d23e/attachment.html From thibaut.barrere at gmail.com Wed Apr 9 18:11:04 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Thu, 10 Apr 2008 00:11:04 +0200 Subject: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid Message-ID: <4a68b8cf0804091511k1f06f247u40f82236c0bf2198@mail.gmail.com> Hi again, I get a XamlException with error AG_E_PARSER_BAD_TYPE whenever I use a Grid control inside the Xaml (even with an Expression Blend generated Xaml file). Is the Grid control currently supported when working with IronRuby ? -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080410/1840c336/attachment.html From ivan at flanders.co.nz Wed Apr 9 18:17:57 2008 From: ivan at flanders.co.nz (Ivan Porto Carrero) Date: Thu, 10 Apr 2008 10:17:57 +1200 Subject: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid In-Reply-To: <4a68b8cf0804091511k1f06f247u40f82236c0bf2198@mail.gmail.com> References: <4a68b8cf0804091511k1f06f247u40f82236c0bf2198@mail.gmail.com> Message-ID: You need to change the namespace of the xaml file probably. Expression blend generates xaml for WPF not Silverlight. I used the grid control in my digg client.. so i guess it works fine :) On Thu, Apr 10, 2008 at 10:11 AM, Thibaut Barr?re wrote: > Hi again, > > I get a XamlException with error AG_E_PARSER_BAD_TYPE whenever I use a > Grid control inside the Xaml (even with an Expression Blend generated Xaml > file). > > Is the Grid control currently supported when working with IronRuby ? > > -- Thibaut > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080410/73f08453/attachment-0001.html From Jimmy.Schementi at microsoft.com Wed Apr 9 19:07:39 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Wed, 9 Apr 2008 16:07:39 -0700 Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? In-Reply-To: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> References: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC76D@NA-EXMSG-C116.redmond.corp.microsoft.com> You need to have debug=true in "initParams" in your HTML file. That should do it. ~js From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re Sent: Wednesday, April 09, 2008 2:58 PM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? Hi, I followed the debugging guidelines provided at the bottom of http://silverlight.net/Quickstarts/ProgramDlr.aspx but could not get them to work so far. My breakpoints in VisualStudio 2008 keep their label "This breakpoint will currently not be hit. No executable code is associated with this line". Should a specific project type or project settings be used to get this working ? thanks, -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/50cb280d/attachment.html From Jimmy.Schementi at microsoft.com Wed Apr 9 19:11:18 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Wed, 9 Apr 2008 16:11:18 -0700 Subject: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid In-Reply-To: References: <4a68b8cf0804091511k1f06f247u40f82236c0bf2198@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC778@NA-EXMSG-C116.redmond.corp.microsoft.com> Are you using the Blend 2 Preview for Silverlight? If not, grab it from Silverlight.net. If you are, then can you send me what your XAML looks like? I suspect that the root element of your XAML has x:Class set incorrectly for Ruby. If Grid is your root ... app.xaml app.rb System::Windows::Application.current.load_root_visual Grid.new, ?app.xaml? ~js From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero Sent: Wednesday, April 09, 2008 3:18 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid You need to change the namespace of the xaml file probably. Expression blend generates xaml for WPF not Silverlight. I used the grid control in my digg client.. so i guess it works fine :) On Thu, Apr 10, 2008 at 10:11 AM, Thibaut Barr?re > wrote: Hi again, I get a XamlException with error AG_E_PARSER_BAD_TYPE whenever I use a Grid control inside the Xaml (even with an Expression Blend generated Xaml file). Is the Grid control currently supported when working with IronRuby ? -- Thibaut _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/fb52ca83/attachment.html From thibaut.barrere at gmail.com Wed Apr 9 21:43:24 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Thu, 10 Apr 2008 03:43:24 +0200 Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC76D@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC76D@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: <4a68b8cf0804091843g65d49669h23d82be10f22c805@mail.gmail.com> Hi Jimmy, thanks for you answer. The application cannot seem to start when using a semicolon to separate values in initParams. I tried comma instead (the application manages to start this way - not sure if the param is passed properly though): either way, the breakpoints remain in the same state (inactivated). I guess it's a first step although something still must be missing. When refreshing the browser windows, should a new debugger pop up ? Could it be some option at the internet explorer level ? thanks, -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080410/cc1e8d03/attachment.html From thibaut.barrere at gmail.com Wed Apr 9 22:05:26 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Thu, 10 Apr 2008 04:05:26 +0200 Subject: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC778@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <4a68b8cf0804091511k1f06f247u40f82236c0bf2198@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC778@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: <4a68b8cf0804091905k32ffd014x30b57c370e3d42b7@mail.gmail.com> Hi, the root element had x:Class set incorrectly to x:Class="GridSample.Page". Chaning it to "System.Windows.Controls.Grid" solved the issue. thanks! -- Thibaut 2008/4/10, Jimmy Schementi : > > > > > Are you using the Blend 2 Preview for Silverlight? If not, grab it from Silverlight.net. > > > > If you are, then can you send me what your XAML looks like? I suspect that the root element of your XAML has x:Class set incorrectly for Ruby. If Grid is your root ... > > > > app.xaml > > > > > > > > app.rb > > System::Windows::Application.current.load_root_visual Grid.new, "app.xaml" > > > > ~js > > > > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero > Sent: Wednesday, April 09, 2008 3:18 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid > > > > > You need to change the namespace of the xaml file probably. > Expression blend generates xaml for WPF not Silverlight. > > > I used the grid control in my digg client.. so i guess it works fine :) > > > On Thu, Apr 10, 2008 at 10:11 AM, Thibaut Barr?re wrote: > > Hi again, > > I get a XamlException with error AG_E_PARSER_BAD_TYPE whenever I use a Grid control inside the Xaml (even with an Expression Blend generated Xaml file). > > Is the Grid control currently supported when working with IronRuby ? > > -- Thibaut > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > From Jimmy.Schementi at microsoft.com Wed Apr 9 22:16:32 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Wed, 9 Apr 2008 19:16:32 -0700 Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? In-Reply-To: <4a68b8cf0804091843g65d49669h23d82be10f22c805@mail.gmail.com> References: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC76D@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091843g65d49669h23d82be10f22c805@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC849@NA-EXMSG-C116.redmond.corp.microsoft.com> Woops, it's suppose to be a comma, my fault. I may be mistaken, but I believe only the IronRuby bits on http://dynamicsilverlight.net can be debugged in Silverlight. I just did a test and I cannot debug the ruby clock demo with the Silverlight SDK bits, but it works with the Dynamic Silverlight bits. So, first make sure you're using the latest and greatest stuff from the web. If you run the app, open the ruby file in VS, put a breakpoint in it, attach to your browser running the app, and refresh the browser, you should see the breakpoint flicker a bit and then break at the line. This shouldn't depend on any IE settings; you can debug Firefox as well. From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re Sent: Wednesday, April 09, 2008 6:43 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? Hi Jimmy, thanks for you answer. The application cannot seem to start when using a semicolon to separate values in initParams. I tried comma instead (the application manages to start this way - not sure if the param is passed properly though): either way, the breakpoints remain in the same state (inactivated). I guess it's a first step although something still must be missing. When refreshing the browser windows, should a new debugger pop up ? Could it be some option at the internet explorer level ? thanks, -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080409/919a103b/attachment.html From Jimmy.Schementi at microsoft.com Wed Apr 9 22:17:35 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Wed, 9 Apr 2008 19:17:35 -0700 Subject: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid In-Reply-To: <4a68b8cf0804091905k32ffd014x30b57c370e3d42b7@mail.gmail.com> References: <4a68b8cf0804091511k1f06f247u40f82236c0bf2198@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC778@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091905k32ffd014x30b57c370e3d42b7@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC84B@NA-EXMSG-C116.redmond.corp.microsoft.com> Great! In general, make sure that the x:Class of your XAML matches the type of the first argument you pass into load_root_visual. ~js > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Thibaut Barr?re > Sent: Wednesday, April 09, 2008 7:05 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid > > Hi, > > the root element had x:Class set incorrectly to > x:Class="GridSample.Page". > > Chaning it to "System.Windows.Controls.Grid" solved the issue. > > thanks! > > -- Thibaut > > 2008/4/10, Jimmy Schementi : > > > > > > > > > > Are you using the Blend 2 Preview for Silverlight? If not, grab it > from Silverlight.net. > > > > > > > > If you are, then can you send me what your XAML looks like? I suspect > that the root element of your XAML has x:Class set incorrectly for > Ruby. If Grid is your root ... > > > > > > > > app.xaml > > > > > > > > > > > > > > > > app.rb > > > > System::Windows::Application.current.load_root_visual Grid.new, > "app.xaml" > > > > > > > > ~js > > > > > > > > > > > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero > > Sent: Wednesday, April 09, 2008 3:18 PM > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] AG_E_PARSER_BAD_TYPE when using Grid > > > > > > > > > > You need to change the namespace of the xaml file probably. > > Expression blend generates xaml for WPF not Silverlight. > > > > > > I used the grid control in my digg client.. so i guess it works fine > :) > > > > > > On Thu, Apr 10, 2008 at 10:11 AM, Thibaut Barr?re > wrote: > > > > Hi again, > > > > I get a XamlException with error AG_E_PARSER_BAD_TYPE whenever I use > a Grid control inside the Xaml (even with an Expression Blend generated > Xaml file). > > > > Is the Grid control currently supported when working with IronRuby ? > > > > -- Thibaut > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core From w.kelly at qut.edu.au Wed Apr 9 22:25:29 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Thu, 10 Apr 2008 12:25:29 +1000 Subject: [Ironruby-core] running gems setup.rb with revision93 In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2CB7F2F7@QUTEXMBX02.qut.edu.au> References: <372109E149E8084D8E6C7D9CFD82E0632D91DA448D@NA-EXMSG-C115.redmond.corp.microsoft.com>, <6821FE23D98BAC41AC2A91E7970F31AF1E2CB7F2F7@QUTEXMBX02.qut.edu.au> Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2C7B104B@QUTEXMBX02.qut.edu.au> Attached is a fix to my hastily implemented Regexp.quote method ( I returned a string rather than a MutableString) It now passes the tests in Specs\core\regexp\quote_spec.rb Cheers, Wayne. ________________________________________ From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly [w.kelly at qut.edu.au] Sent: Wednesday, 9 April 2008 5:51 PM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] running gems setup.rb with revision93 With a new version out, I thought I'd try again to see how far I could get gems setup.rb to run ... 1) missing method Regex.quote - see implementation in attached patch -------------- next part -------------- A non-text attachment was scrubbed... Name: Regexp.patch Type: application/octet-stream Size: 2689 bytes Desc: Regexp.patch Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080410/0363052e/attachment.obj From thibaut.barrere at gmail.com Wed Apr 9 22:42:27 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Thu, 10 Apr 2008 04:42:27 +0200 Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC849@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC76D@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091843g65d49669h23d82be10f22c805@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC849@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: <4a68b8cf0804091942g35aa8ebet4b2f4ffe5b4ae5ed@mail.gmail.com> > Woops, it's suppose to be a comma, my fault. No worries :) > I may be mistaken, but I believe only the IronRuby bits on > http://dynamicsilverlight.net can be debugged in Silverlight. I just did a > test and I cannot debug the ruby clock demo with the Silverlight SDK bits, > but it works with the Dynamic Silverlight bits. So, first make sure you're > using the latest and greatest stuff from the web. Hooray. It works now! FWIW: the simplest way to do this for me was to copy the Dynamic SDK dlls from /bin to my application /app (it seems that Chiron will pick them instead if they are here). thanks! -- Thibaut From Jimmy.Schementi at microsoft.com Wed Apr 9 23:22:03 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Wed, 9 Apr 2008 20:22:03 -0700 Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? In-Reply-To: <4a68b8cf0804091942g35aa8ebet4b2f4ffe5b4ae5ed@mail.gmail.com> References: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC76D@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091843g65d49669h23d82be10f22c805@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC849@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091942g35aa8ebet4b2f4ffe5b4ae5ed@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC86F@NA-EXMSG-C116.redmond.corp.microsoft.com> > the simplest way to do this for me was to > copy the Dynamic SDK dlls from /bin to my application /app (it seems > that Chiron will pick them instead if they are here). Sure. =) You can also put them in the /bin directory that Chiron points to so all your apps can use them. ~js > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Thibaut Barr?re > Sent: Wednesday, April 09, 2008 7:42 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Cannot debug IronRuby + Silverlight - any > hint ? > > > Woops, it's suppose to be a comma, my fault. > > No worries :) > > > I may be mistaken, but I believe only the IronRuby bits on > > http://dynamicsilverlight.net can be debugged in Silverlight. I just > did a > > test and I cannot debug the ruby clock demo with the Silverlight SDK > bits, > > but it works with the Dynamic Silverlight bits. So, first make sure > you're > > using the latest and greatest stuff from the web. > > Hooray. It works now! FWIW: the simplest way to do this for me was to > copy the Dynamic SDK dlls from /bin to my application /app (it seems > that Chiron will pick them instead if they are here). > > thanks! > > -- Thibaut > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core From w.kelly at qut.edu.au Thu Apr 10 03:00:05 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Thu, 10 Apr 2008 17:00:05 +1000 Subject: [Ironruby-core] gems setup.rb continued ... Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2C7B104C@QUTEXMBX02.qut.edu.au> After a hack to work around the previous regular expression substitution problem, we continue ... 1) throw exception "Malformed version number" (due to $1 returning nil after a successful match) - fixed my previous Regexp.=== patch to set CurrentMatch in current scope, see attached patch 2) $1 still incorrectly returns nil - fixed trivial index range bug in RubyScope.GetCurrentMatchGroup, see attached patch 3) Wrong number or type of arguments for method "module_eval" - created module_eval aliases for each class_eval method in Builtins.ModuleOps - corrected signatures for overloads that take a code string with file name and line number - implemented these new methods by calling the version that takes code string (and ignoring the other parameters) (see attached patch) 4) Wrong number or type of arguments for method "private" - generalized ModuleOps.SetPrivateVisibility to take param array of obects rather than Symbols and cast them to symbols, see attached patch. - will need to do the same for protected, public and top-level versions of these methods 5) Wrong number or type of arguments for method "define_method" - created overloaded version of define_method that takes method name string and converts it to Symbol, see attached patch. 6) Undefined method "module_function" - not yet implemented in ModuleOps. - this one looks a little tricker, so I'll leave it to someone with greater knowledge of the IronRuby internals ... Cheers, Wayne. -------------- next part -------------- A non-text attachment was scrubbed... Name: ModuleOps.patch Type: application/octet-stream Size: 4075 bytes Desc: ModuleOps.patch Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080410/e02da8ca/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Reqexp.patch Type: application/octet-stream Size: 801 bytes Desc: Reqexp.patch Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080410/e02da8ca/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: RubyScope.patch Type: application/octet-stream Size: 546 bytes Desc: RubyScope.patch Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080410/e02da8ca/attachment-0005.obj From thibaut.barrere at gmail.com Thu Apr 10 04:53:40 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Thu, 10 Apr 2008 10:53:40 +0200 Subject: [Ironruby-core] Perspectives for unit and ui testing for Dynamic Silverlight Message-ID: <4a68b8cf0804100153v52bf746q456516590448a37c@mail.gmail.com> Hi, I just watched Jeff Wilcox videos about the Silverlight testing framework (http://www.jeff.wilcox.name/2008/03/20/vid-silverlight-control-ut/) and questions come to my mind. Is this framework planned to be the "standard" testing framework for Dynamic Silverlight as well ? Or will we build upon the spec framework already in the IronRuby distribution ? Writing this and after digging a bit inside the code, I believe we could do both ways: use the spec syntax and rely either on the UI testing framework or on mock objects, when relevant. Any insight from the MS team ? cheers! Thibaut -- [blog] http://evolvingworker.com - tools for a better day [blog] http://blog.logeek.fr - about writing software From ben2004uk at googlemail.com Thu Apr 10 05:25:45 2008 From: ben2004uk at googlemail.com (Ben Hall) Date: Thu, 10 Apr 2008 10:25:45 +0100 Subject: [Ironruby-core] Perspectives for unit and ui testing for Dynamic Silverlight In-Reply-To: <4a68b8cf0804100153v52bf746q456516590448a37c@mail.gmail.com> References: <4a68b8cf0804100153v52bf746q456516590448a37c@mail.gmail.com> Message-ID: I'm really interested in hear what the team have planned for testing and the DLR. I'm planning on spending some time grokking this and see where the areas of concern are and whats actually there. It would be good to hear thoughts from the team. Do you expect people writing Ruby to use RSpec\Test::Unit? Or would it be better for a existing C# unit testing framework (NUnit\MbUnit) to have some DLR support? Regards Ben Blog.BenHall.me.uk On Thu, Apr 10, 2008 at 9:53 AM, Thibaut Barr?re wrote: > Hi, > > I just watched Jeff Wilcox videos about the Silverlight testing > framework (http://www.jeff.wilcox.name/2008/03/20/vid-silverlight-control-ut/) > and questions come to my mind. > > Is this framework planned to be the "standard" testing framework for > Dynamic Silverlight as well ? Or will we build upon the spec framework > already in the IronRuby distribution ? > > Writing this and after digging a bit inside the code, I believe we > could do both ways: use the spec syntax and rely either on the UI > testing framework or on mock objects, when relevant. > > Any insight from the MS team ? > > cheers! > > Thibaut > -- > [blog] http://evolvingworker.com - tools for a better day > [blog] http://blog.logeek.fr - about writing software > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > From jflam at microsoft.com Fri Apr 11 10:20:43 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Fri, 11 Apr 2008 07:20:43 -0700 Subject: [Ironruby-core] Perspectives for unit and ui testing for Dynamic Silverlight In-Reply-To: References: <4a68b8cf0804100153v52bf746q456516590448a37c@mail.gmail.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91E2038C@NA-EXMSG-C115.redmond.corp.microsoft.com> Ben Hall: > Do you expect people writing Ruby to use RSpec\Test::Unit? Or would it > be better for a existing C# unit testing framework (NUnit\MbUnit) to > have some DLR support? There are folks today who are very interested in using IronRuby to test existing C# code. I know that Phil Haack would love to test ASP.NET MVC using Ruby tests - see his recent blog post here: http://haacked.com/archive/2008/04/09/my-first-ironruby-unit-test-spec-for-asp.net-mvc.aspx I need to do a better job at helping folks out with scenarios around IronRuby, but to be blunt my hands are kind of full just getting the language and libraries to work! Remember - we do have full time positions open for IronRuby devs on my team :) Thanks, -John From jflam at microsoft.com Fri Apr 11 10:41:15 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Fri, 11 Apr 2008 07:41:15 -0700 Subject: [Ironruby-core] gems setup.rb continued ... In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2C7B104C@QUTEXMBX02.qut.edu.au> References: <6821FE23D98BAC41AC2A91E7970F31AF1E2C7B104C@QUTEXMBX02.qut.edu.au> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91E203A0@NA-EXMSG-C115.redmond.corp.microsoft.com> Wayne Kelly: > After a hack to work around the previous regular expression > substitution problem, we continue ... > > 1) throw exception "Malformed version number" (due to $1 returning > nil after a successful match) > - fixed my previous Regexp.=== patch to set CurrentMatch in > current scope, see attached patch > > 2) $1 still incorrectly returns nil > - fixed trivial index range bug in RubyScope.GetCurrentMatchGroup, > see attached patch > > 3) Wrong number or type of arguments for method "module_eval" > - created module_eval aliases for each class_eval method in > Builtins.ModuleOps > - corrected signatures for overloads that take a code string with > file name and line number > - implemented these new methods by calling the version that takes > code string (and ignoring the other parameters) > (see attached patch) > > 4) Wrong number or type of arguments for method "private" > - generalized ModuleOps.SetPrivateVisibility to take param array > of obects rather than Symbols and cast them to symbols, see attached > patch. > - will need to do the same for protected, public and top-level > versions of these methods > > 5) Wrong number or type of arguments for method "define_method" > - created overloaded version of define_method that takes method > name string and converts it to Symbol, see attached patch. > > 6) Undefined method "module_function" > - not yet implemented in ModuleOps. > - this one looks a little tricker, so I'll leave it to someone > with greater knowledge of the IronRuby internals ... Thanks for making this stuff happen, Wayne! I'm working on a broad set of changes in the libraries right now. I'll review and integrate your changes ASAP. Thanks, -John From jflam at microsoft.com Fri Apr 11 10:43:09 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Fri, 11 Apr 2008 07:43:09 -0700 Subject: [Ironruby-core] running gems setup.rb with revision93 In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2C7B104B@QUTEXMBX02.qut.edu.au> References: <372109E149E8084D8E6C7D9CFD82E0632D91DA448D@NA-EXMSG-C115.redmond.corp.microsoft.com>, <6821FE23D98BAC41AC2A91E7970F31AF1E2CB7F2F7@QUTEXMBX02.qut.edu.au> <6821FE23D98BAC41AC2A91E7970F31AF1E2C7B104B@QUTEXMBX02.qut.edu.au> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91E203A3@NA-EXMSG-C115.redmond.corp.microsoft.com> Wayne Kelly: > Attached is a fix to my hastily implemented Regexp.quote method ( I > returned a string rather than a MutableString) Cool. Thanks! FYI I'm working on doing an integration of Peter Bacon Darwin's awesome port of JOni (called IrOni(!)) into our regex code, so I'm filling out the implementation of Regexp now. Thanks, -John From jflam at microsoft.com Sat Apr 12 02:16:57 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Fri, 11 Apr 2008 23:16:57 -0700 Subject: [Ironruby-core] Update on specs and String Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D91E207AB@NA-EXMSG-C115.redmond.corp.microsoft.com> I've spent the better part of this week working on String with the targeted goal of implementing the subset of String that's required to run Rails. Below is a list of the methods that we see Rails using, and the specs that are passing as of tonight. I haven't really done anything with %, delete, tr, and unpack which reflects their low pass rate. In many of the cases where we are almost at 100%, we aren't passing the specs that require us to return a subclass of String where the method (eg gsub) is invoked on the subclass of String. This is pretty strange behavior that Rails doesn't appear to use (they monkey patch String rather than deriving from it), so our pass rate is actually quite a lot higher than it might appear right now (70%). So getting subclass behavior correct is going to be a low priority thing for the foreseeable future. In any event, this shelveset isn't quite ready to ship yet, but I thought I'd update folks with progress so that you can see where we're at as of tonight. This should get checked in sometime next week. Thanks, -John name pass total % % 31 69 45% * 6 6 100% + 4 4 100% <=> == 9 11 82% [] 77 89 87% chop 9 10 90% concat 9 10 90% delete 0 11 0% downcase[!] 6 7 86% dump 3 4 75% each 7 10 70% empty? 1 1 100% gsub[!] 25 38 66% hash 1 1 100% inspect 2 3 67% length 1 1 100% match[=~] 11 11 100% replace 5 5 100% scan 11 15 73% size 1 1 100% split 24 27 89% strip[!] 4 5 80% sub[!] 25 39 64% to_i 10 12 83% to_s 2 3 67% to_str 2 3 67% to_sym 1 2 50% tr 0 11 0% unpack 0 1 0% upcase[!] 6 7 86% 293 417 70% From thibaut.barrere at gmail.com Sat Apr 12 04:49:10 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Sat, 12 Apr 2008 10:49:10 +0200 Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC86F@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC76D@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091843g65d49669h23d82be10f22c805@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC849@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091942g35aa8ebet4b2f4ffe5b4ae5ed@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC86F@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: <4a68b8cf0804120149k398b4e74w5d5c14953573b1c3@mail.gmail.com> In case it's useful to someone else - I gathered those tips here: http://www.dotnetguru2.org/tbarrere/index.php?title=step_by_step_debugging_with_silverlight_&more=1&c=1&tb=1&pb=1 I believe it's pretty much what's here : http://silverlight.net/Quickstarts/ProgramDlr.aspx except for: - debug=true - grab the latest IronRuby binaries - put those in your /app or chiron's /bin It may be worth updating ProgramDlr.aspx with those additional tips ? I have a related question: will it be (or is it currently ?) possible to do step-by-step debugging with any of the free products (Visual Studio C# express 2008, VS 2008 shell version, any other ?). cheers Thibaut Barr?re -- LoGeek [blog] http://evolvingworker.com - tools for a better day [blog] http://blog.logeek.fr - about writing software -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080412/eab73bbe/attachment.html From Jimmy.Schementi at microsoft.com Sat Apr 12 21:46:48 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Sat, 12 Apr 2008 18:46:48 -0700 Subject: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? In-Reply-To: <4a68b8cf0804120149k398b4e74w5d5c14953573b1c3@mail.gmail.com> References: <4a68b8cf0804091458h12a34a63m8de276c6e482832c@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC76D@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091843g65d49669h23d82be10f22c805@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC849@NA-EXMSG-C116.redmond.corp.microsoft.com> <4a68b8cf0804091942g35aa8ebet4b2f4ffe5b4ae5ed@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328457EAEC86F@NA-EXMSG-C116.redmond.corp.microsoft.com>, <4a68b8cf0804120149k398b4e74w5d5c14953573b1c3@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328457FE34DFF@NA-EXMSG-C116.redmond.corp.microsoft.com> Thanks Thibaut! Yes, I can poke the silverlight.net guys to update ProgramDlr.aspx, again. =P ~js ________________________________________ From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re [thibaut.barrere at gmail.com] Sent: Saturday, April 12, 2008 1:49 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Cannot debug IronRuby + Silverlight - any hint ? In case it's useful to someone else - I gathered those tips here: http://www.dotnetguru2.org/tbarrere/index.php?title=step_by_step_debugging_with_silverlight_&more=1&c=1&tb=1&pb=1 I believe it's pretty much what's here : http://silverlight.net/Quickstarts/ProgramDlr.aspx except for: - debug=true - grab the latest IronRuby binaries - put those in your /app or chiron's /bin It may be worth updating ProgramDlr.aspx with those additional tips ? I have a related question: will it be (or is it currently ?) possible to do step-by-step debugging with any of the free products (Visual Studio C# express 2008, VS 2008 shell version, any other ?). cheers Thibaut Barr?re -- LoGeek [blog] http://evolvingworker.com - tools for a better day [blog] http://blog.logeek.fr - about writing software From bacondarwin at googlemail.com Sun Apr 13 16:22:12 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Sun, 13 Apr 2008 21:22:12 +0100 Subject: [Ironruby-core] Socket patch Message-ID: <000001c89da4$103ed610$30bc8230$@com> I have uploaded a patch to the rubyforge project site. You can see it at: http://rubyforge.org/tracker/index.php?func=detail&aid=19494&group_id=4359&a tid=16800 Here is the blurb if you don't have time to check it out. Pete >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> This patch is a further development of the current Socket classes. Source files - The methods in the all the Socket classes, except for Socket itself, have been implemented. - The classes have been moved into a subfolder of the IronRuby.Libraries project in line with other "library" classes such as Digest. - The SocketError class has been implemented. - Various Errno:: classes still need to be implemented since the not all Socket errors come back as SocketError exceptions! - Various conversion methods have been abstracted, such as ConvertToPort, ConvertToHost and so on. These are stored in BasicSocket.cs Testing files Some initial Socket RSpec files have been moved into the /trunk/tests/ironruby/specs/library/socket folder. Particularly the UDPSocket folder has some runnable tests. The spec_runner.rb file has been modified to allow rake rspec and rake spec2 to run these files. The general format is to use : colons to separate folders in order to run non-core specs. For example: > rake rspec library:socket:udpsocket - fail Will run all the specs in the trunk/tests/ironruby/specs/library/socket/udpsocket folder. From robert.brotherus at napa.fi Tue Apr 15 04:13:28 2008 From: robert.brotherus at napa.fi (Robert Brotherus) Date: Tue, 15 Apr 2008 11:13:28 +0300 Subject: [Ironruby-core] Discrepancy in operation of File.exist? Message-ID: <53194650933664488F3F0C3A0AB56832354730@nw60.napa.fi> Consider simple file.rb: puts File.exist?("C:/work/napa.net/gui/bin/script") There exists directory C:/work/napa.net/gui/bin/script -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080415/a14628d2/attachment.html From robert.brotherus at napa.fi Tue Apr 15 04:15:25 2008 From: robert.brotherus at napa.fi (Robert Brotherus) Date: Tue, 15 Apr 2008 11:15:25 +0300 Subject: [Ironruby-core] Discrepancy in operation of File.exist Message-ID: <53194650933664488F3F0C3A0AB56832354731@nw60.napa.fi> Consider simple file.rb: puts File.exist?("C:/work/napa.net/gui/bin/script") There exists directory C:/work/napa.net/gui/bin/script With C-ruby: [11:11:29 ~/irb_test] ruby file.rb true With IronRuby: [11:11:35 ~/irb_test] rbx file.rb false This discrepancy (among others) currently breaks the nice utility find.rb Robert Brotherus Software architect Napa Ltd Tammasaarenkatu 3, Helsinki FI-00180 P.O.Box 470, Helsinki FI-00181 Tel. +358 9 22 813 1 Direct. +358 9 22 813 611 GSM +358 45 11 456 02 Fax. +358 9 22 813 800 Email: Robert.Brotherus at napa.fi www.napa.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080415/4fe5bf34/attachment.html From ksunair at yahoo.com Tue Apr 15 15:21:26 2008 From: ksunair at yahoo.com (Unnikrishnan Nair) Date: Tue, 15 Apr 2008 12:21:26 -0700 (PDT) Subject: [Ironruby-core] RBX Question Message-ID: <834927.3325.qm@web50611.mail.re2.yahoo.com> I see only difference is the there is no local variable concept when run in interpreter mode. Is this correct? Thanks. Unni What is the difference in running ruby code in interpreter mode on rbxand running rbx with ruby code in a file passed as a parameter? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080415/f69c4198/attachment.html From Jimmy.Schementi at microsoft.com Tue Apr 15 17:04:56 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Tue, 15 Apr 2008 14:04:56 -0700 Subject: [Ironruby-core] RBX Question In-Reply-To: <834927.3325.qm@web50611.mail.re2.yahoo.com> References: <834927.3325.qm@web50611.mail.re2.yahoo.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328457FD5218C@NA-EXMSG-C116.redmond.corp.microsoft.com> > Unnikrishnan Nair writes: > I see only difference is the there is no local variable concept when run in interpreter mode. Is this correct? Yes, currently local variables don't work in rbx when running it interactively. The work to fix this is being done, though John/Tomas can chime in here about how close they are. > What is the difference in running ruby code in interpreter mode on rbx and running rbx with ruby code in a file passed as a parameter? It revolves around getting ruby Binding working properly. Here's a good explanation of binding: http://onestepback.org/index.cgi/Tech/Ruby/RubyBindings.rdoc/style/print Binding lets you evaluate a block against an arbitrary scope. With a file, you use the same scope to execute the top-level code. However a console requires you to execute each line against the console's scope. Methods, instance variables, and globals work without binding because they are implicitly declared on Object in some form or another, but local variables are defined in the binding. Does that help clear things up? ~Jimmy From robert.brotherus at napa.fi Thu Apr 17 04:30:41 2008 From: robert.brotherus at napa.fi (Robert Brotherus) Date: Thu, 17 Apr 2008 11:30:41 +0300 Subject: [Ironruby-core] Exception handling discrepancies Message-ID: <53194650933664488F3F0C3A0AB56832354B91@nw60.napa.fi> Consider following simple program exceptions.rb: begin a = ABC rescue puts "We have exception: " + $! end cruby can treat the exception as string, but rbx fails: [11:24:38 ~/irb_test] ruby exceptions.rb We have exception: uninitialized constant ABC [11:25:10 ~/irb_test] rbx exceptions.rb Snippets:0:in `main': undefined local variable or method `to_str' for uninitialized constant Object::ABC:NameError (NoMethodError) from Snippets:0:in `Initialize'[11:25:16 ~/irb_test] The problem can be circumvented currently with to_s: puts "We have exception: " + $!.to_s Robert Brotherus Software architect Napa Ltd Tammasaarenkatu 3, Helsinki FI-00180 P.O.Box 470, Helsinki FI-00181 Tel. +358 9 22 813 1 Direct. +358 9 22 813 611 GSM +358 45 11 456 02 Fax. +358 9 22 813 800 Email: Robert.Brotherus at napa.fi www.napa.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080417/793a6ac3/attachment.html From bacondarwin at googlemail.com Thu Apr 17 05:51:46 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Thu, 17 Apr 2008 10:51:46 +0100 Subject: [Ironruby-core] Exception handling discrepancies In-Reply-To: <53194650933664488F3F0C3A0AB56832354B91@nw60.napa.fi> References: <53194650933664488F3F0C3A0AB56832354B91@nw60.napa.fi> Message-ID: <000a01c8a070$a73886a0$f5a993e0$@com> These bugs are great. Are you reporting them on the RubyForge IronRuby site? That way they won't get lost in the mailing list archives. Pete From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Robert Brotherus Sent: Thursday,17 April 17, 2008 09:31 To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Exception handling discrepancies Consider following simple program exceptions.rb: begin a = ABC rescue puts "We have exception: " + $! end cruby can treat the exception as string, but rbx fails: [11:24:38 ~/irb_test] ruby exceptions.rb We have exception: uninitialized constant ABC [11:25:10 ~/irb_test] rbx exceptions.rb Snippets:0:in `main': undefined local variable or method `to_str' for uninitialized constant Object::ABC:NameError (NoMethodError) from Snippets:0:in `Initialize'[11:25:16 ~/irb_test] The problem can be circumvented currently with to_s: puts "We have exception: " + $!.to_s Robert Brotherus Software architect Napa Ltd Tammasaarenkatu 3, Helsinki FI-00180 P.O.Box 470, Helsinki FI-00181 Tel. +358 9 22 813 1 Direct. +358 9 22 813 611 GSM +358 45 11 456 02 Fax. +358 9 22 813 800 Email: Robert.Brotherus at napa.fi www.napa.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080417/a3c2dc1d/attachment.html From robert.brotherus at napa.fi Fri Apr 18 03:29:46 2008 From: robert.brotherus at napa.fi (Robert Brotherus) Date: Fri, 18 Apr 2008 10:29:46 +0300 Subject: [Ironruby-core] Exception handling discrepancies References: <53194650933664488F3F0C3A0AB56832354B91@nw60.napa.fi> <000a01c8a070$a73886a0$f5a993e0$@com> Message-ID: <53194650933664488F3F0C3A0AB56832354D86@nw60.napa.fi> Bugs 19625 and 19626 submitted to the tracker. Will submit bugs directly there in the future. Thanks for reminder. Robert Brotherus Software architect Napa Ltd _____ From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: 17. huhtikuuta 2008 12:52 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Exception handling discrepancies These bugs are great. Are you reporting them on the RubyForge IronRuby site? That way they won't get lost in the mailing list archives. Pete From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Robert Brotherus Sent: Thursday,17 April 17, 2008 09:31 To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Exception handling discrepancies Consider following simple program exceptions.rb: begin a = ABC rescue puts "We have exception: " + $! end cruby can treat the exception as string, but rbx fails: [11:24:38 ~/irb_test] ruby exceptions.rb We have exception: uninitialized constant ABC [11:25:10 ~/irb_test] rbx exceptions.rb Snippets:0:in `main': undefined local variable or method `to_str' for uninitialized constant Object::ABC:NameError (NoMethodError) from Snippets:0:in `Initialize'[11:25:16 ~/irb_test] The problem can be circumvented currently with to_s: puts "We have exception: " + $!.to_s Robert Brotherus Software architect Napa Ltd Tammasaarenkatu 3, Helsinki FI-00180 P.O.Box 470, Helsinki FI-00181 Tel. +358 9 22 813 1 Direct. +358 9 22 813 611 GSM +358 45 11 456 02 Fax. +358 9 22 813 800 Email: Robert.Brotherus at napa.fi www.napa.fi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080418/2d21a13d/attachment-0001.html From brianblackwell at realemail.net Fri Apr 18 16:46:22 2008 From: brianblackwell at realemail.net (Brian Blackwell) Date: Sat, 19 Apr 2008 06:46:22 +1000 Subject: [Ironruby-core] Running activerecord Message-ID: <1208551582.7898.1248680957@webmail.messagingengine.com> I wanted to test my prototype ADO.NET database wrappers for SQLite and MySQL, so I thought I would see how far I could get in an attempt to run activerecord. Running activerecord is of course a necessary step in the path to running Rails. At this point I'm simply trying to get "require 'active_record.rb'" to work, which in turn requires activesupport. Here are some issues I've come across thus far: (1) Missing method File.expand_path - Adapted the implementation from Ruby.NET, along with some other unimplemented methods from File. I will check on licensing issues before posting a patch. (2) rubygems is not yet running in IronRuby - Commented out all "require 'rubygems'" in the activerecord and activesupport source, since they are not absolutely necessary (i.e. rubygems is used to grab packages not present on the local filesystem). (3) Missing method Class.method_added - This is just a 'dummy' method that gets overridden - see patch for ModuleOps.cs (4) C:\brian\ironruby\trunk\src\IronRuby.Libraries\Builtins\Kernel.cs:611:in `InstanceEval': instance_eval on Module or Class needs singleton support (NotImplementedError) - It seems that instance_eval has different semantics when invoked with a class or method as receiver. I haven't yet worked out what is involved with implementing this method, so for the time being I commented out the NotImplementedError in Kernel.cs: //if (self is RubyModule) { // throw RubyExceptions.CreateNotImplementedError("instance_eval on Module or Class needs singleton support"); //} (5) :0:in `__init__': wrong number or type of arguments for `define_method' (ArgumentError) - Problem: current implementation of define_method does not accept Proc objects as arguments, hence the following line in activesupport-2.0.2\lib\active_support\core_ext\module\attr_accessor_with_default.rb throws an exception: define_method(sym, block_given? ? block : Proc.new { default }) - Solution: added an overload for DefineMethod that accepts a Proc object as an argument; see patch for ModuleOps.cs (6) Missing method Thread.critical - Hacked a prototype implementation - see patch for ThreadOps.cs (it's ugly and purely for the purposes of trying to get activerecord to import :-) (7) Missing method Dir.glob - Adapted the implementation from Ruby.NET (see (1) above) (8) Missing method File.basename - Adapted the implementation from Ruby.NET (see (1) above) (9) Problem with activesupport-2.0.2\lib\active_support\core_ext\array\conversions.rb - unknown: Cannot cast from 'Microsoft.Scripting.SymbolId' to 'Ruby.Builtins.Proc' (ArgumentError) - This is the offending piece of code in conversions.rb: def to_param map(&:to_param).join '/' end I must say that I'm not familiar with the &:symbol syntax. Anyone have any suggestions here? - For the time being I have commented out this method in conversions.rb. (10) Libraries 'enumerator.so' and 'bigdecimal.so' not available - Solution: commented out the requires in the activesupport source for the time being (11) Problem with the Ruby library 'rational.rb': :0:in `main': Can't inherit from a class without a default or code context constructor (System::NotSupportedException) - The problem is that Rational is a subclass of Numeric, which is an abstract class with no constructor: class Rational < Numeric - Solution: hacked Ruby.Builtins.Numeric so that it is no longer abstract, and has a zero-arg constructor - see patch for Numeric.cs (12) C:\brian\ironruby\trunk\src\IronRuby.Libraries\Builtins\Kernel.cs:804:in `Require': Expression transformation not implemented: MemberAssignmentExpression (System::NotImplementedException) - The problem is in the Ruby library date/format.rb, although I haven't narrowed it down further than that. - Solution: commented out all "require 'date'" for the time being (13) Problem with the Ruby library delegate.rb: Class.new not supported (e.g. no zero-arg constructor for "Class") This is as far as I have got at this point - hopefully someone might find all this useful. - Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: ModuleOps.cs.patch Type: application/octet-stream Size: 2860 bytes Desc: not available Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080419/d41e8633/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Numeric.cs.patch Type: application/octet-stream Size: 504 bytes Desc: not available Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080419/d41e8633/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadOps.cs.patch Type: application/octet-stream Size: 645 bytes Desc: not available Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080419/d41e8633/attachment-0002.obj From jflam at microsoft.com Fri Apr 18 18:56:32 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Fri, 18 Apr 2008 15:56:32 -0700 Subject: [Ironruby-core] Running activerecord In-Reply-To: <1208551582.7898.1248680957@webmail.messagingengine.com> References: <1208551582.7898.1248680957@webmail.messagingengine.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92AD9DAB@NA-EXMSG-C115.redmond.corp.microsoft.com> Brian Blackwell: > I wanted to test my prototype ADO.NET database wrappers for SQLite and > MySQL, so I thought I would see how far I could get in an attempt to > run activerecord. Running activerecord is of course a necessary step in > the path to running Rails. At this point I'm simply trying to get > "require 'active_record.rb'" to work, which in turn requires > activesupport. Here are some issues I've come across thus far: > > ... awesome list of observations elided ... Thanks for doing this work, Brian! This will give me a bunch of things to look at around the core libs this weekend. -John From jayme.edwards at gmail.com Fri Apr 18 20:08:57 2008 From: jayme.edwards at gmail.com (Jayme) Date: Fri, 18 Apr 2008 19:08:57 -0500 Subject: [Ironruby-core] Running activerecord In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92AD9DAB@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <1208551582.7898.1248680957@webmail.messagingengine.com> <372109E149E8084D8E6C7D9CFD82E0632D92AD9DAB@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: I submitted an implementation of File.expand_path a while ago but it hasn't been comitted yet. If your implementation works better go for it. I need it for some things I'm doing with IronRuby too. -Jayme On Fri, Apr 18, 2008 at 5:56 PM, John Lam (IRONRUBY) wrote: > Brian Blackwell: > > > I wanted to test my prototype ADO.NET database > wrappers for SQLite and > > MySQL, so I thought I would see how far I could get in an attempt to > > run activerecord. Running activerecord is of course a necessary step in > > the path to running Rails. At this point I'm simply trying to get > > "require 'active_record.rb'" to work, which in turn requires > > activesupport. Here are some issues I've come across thus far: > > > > ... awesome list of observations elided ... > > Thanks for doing this work, Brian! This will give me a bunch of things to > look at around the core libs this weekend. > > -John > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080418/6fd5404a/attachment.html From jflam at microsoft.com Fri Apr 18 20:36:17 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Fri, 18 Apr 2008 17:36:17 -0700 Subject: [Ironruby-core] Running activerecord Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D9283EB6C@NA-EXMSG-C115.redmond.corp.microsoft.com> Sorry about the delay. It's in the queue. Once i get my shelveset past the checkin troll i'll be going through the backlog of patches. - John Sent from my phone ________________________________ From: Jayme Sent: Friday, April 18, 2008 5:13 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Running activerecord I submitted an implementation of File.expand_path a while ago but it hasn't been comitted yet. If your implementation works better go for it. I need it for some things I'm doing with IronRuby too. -Jayme On Fri, Apr 18, 2008 at 5:56 PM, John Lam (IRONRUBY) > wrote: Brian Blackwell: > I wanted to test my prototype ADO.NET database wrappers for SQLite and > MySQL, so I thought I would see how far I could get in an attempt to > run activerecord. Running activerecord is of course a necessary step in > the path to running Rails. At this point I'm simply trying to get > "require 'active_record.rb'" to work, which in turn requires > activesupport. Here are some issues I've come across thus far: > > ... awesome list of observations elided ... Thanks for doing this work, Brian! This will give me a bunch of things to look at around the core libs this weekend. -John _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080418/dc8c670b/attachment.html From lists at ruby-forum.com Sat Apr 19 00:39:44 2008 From: lists at ruby-forum.com (Rahil Kantharia) Date: Sat, 19 Apr 2008 06:39:44 +0200 Subject: [Ironruby-core] Nice Inspiration for IronRuby, online Codes Message-ID: <7fb731d1e9382436c7d97ed5c0decf00@ruby-forum.com> Hello, Here is a nice inspiration to put " IronRuby and IronPython Codes online. Have a look here to work with plethora of languages. http://codepad.org Just go to codepad.org and enter your code in any of the following languages: C, C++, D, Haskell, OCaml, Perl, Plain Text, Python, Ruby, Scheme, and Tcl. Once you?ve entered your code you then have the option of either pasting and running your code to test it or just pasting it. If any errors are found in the code that you have written, Codepad will point out the error and give you an explanation of what you have done wrong along with the line in which that error occurs. Also, after entering your code, Codepad will create a page where you and others clan go to test and collaborate. This is a simple free tool that allows both advanced and beginner-level programmers to test their code. Most appealing is the potential it offers for group collaboration. I hope some one will implement something like this for IronRuby / IronPython -- Posted via http://www.ruby-forum.com/. From m.david at xmlhacker.com Sun Apr 20 11:54:24 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Sun, 20 Apr 2008 09:54:24 -0600 Subject: [Ironruby-core] Nice Inspiration for IronRuby, online Codes In-Reply-To: <7fb731d1e9382436c7d97ed5c0decf00@ruby-forum.com> References: <7fb731d1e9382436c7d97ed5c0decf00@ruby-forum.com> Message-ID: On Fri, 18 Apr 2008 22:39:44 -0600, Rahil Kantharia wrote: > I hope some one will implement something like this for IronRuby / > IronPython They have, but in a way that in my own opinion is even better via adding intellisense and various other interactive way to learn both the programming languages supported by the DLR as well as features of the Silverlight API itself. See: http://dynamicsilverlight.net/learn/dlrconsole/ as well as http://www.voidspace.org.uk/ironpython/webide/webide.html for more detail. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From ben2004uk at googlemail.com Sun Apr 20 13:22:10 2008 From: ben2004uk at googlemail.com (Ben Hall) Date: Sun, 20 Apr 2008 18:22:10 +0100 Subject: [Ironruby-core] Nice Inspiration for IronRuby, online Codes In-Reply-To: References: <7fb731d1e9382436c7d97ed5c0decf00@ruby-forum.com> Message-ID: Hi everyone, I'm currently playing around with a few ideas based around this, I've got a rough feature set sorted and free time allocated. I will share more when I have more to share :) Out of interest, could you expand on "various other interactive way" for me :) Cheers Ben Blog.BenHall.me.uk On Sun, Apr 20, 2008 at 4:54 PM, M. David Peterson wrote: > On Fri, 18 Apr 2008 22:39:44 -0600, Rahil Kantharia > wrote: > > > I hope some one will implement something like this for IronRuby / > > IronPython > > They have, but in a way that in my own opinion is even better via adding > intellisense and various other interactive way to learn both the > programming languages supported by the DLR as well as features of the > Silverlight API itself. See: > http://dynamicsilverlight.net/learn/dlrconsole/ as well as > http://www.voidspace.org.uk/ironpython/webide/webide.html for more detail. > > -- > /M:D > > M. David Peterson > Co-Founder & Chief Architect, 3rd&Urban, LLC > Email: m.david at 3rdandUrban.com | m.david at amp.fm > Mobile: (206) 999-0588 > http://3rdandUrban.com | http://amp.fm | > http://www.oreillynet.com/pub/au/2354 > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > From w.kelly at qut.edu.au Mon Apr 21 18:57:56 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Tue, 22 Apr 2008 08:57:56 +1000 Subject: [Ironruby-core] module_function Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979A@QUTEXMBX02.qut.edu.au> Is anyone currently working on or have any ideas regarding the implementation of Module::module_function? (this is where I'm currently stuck in trying to execute setup.rb for gems) module_function is meant to take a list of names of instance methods and make then also callable as class (or singleton) methods. It's easy enough to locate the existing methods using something like: RubyMethodInfo method = (RubyMethodInfo)module.ResolveMethod(method_name); (BTW, why doesn't ResolveMethod return a RubyMethodInfo?) However, I'm not entirely sure how to programmatically create a new class method (in Ruby.NET we had a helper method that would create a singleton for a module if one didn't already exist, but I'm not sure what the equivalent of this is in IronRuby) Anyway, it seems that invoking: module.SingletonClass.DefineMethod( ...) creates a new method in the right place (provided SingletonClass has been properly initialized). However, when I try calling such a method as a class method I get a wrong number of arguments exception, presumably because different parameters are expected depending on whether it is called as an instance method or as a class method. Any ideas? Cheers, Wayne. From w.kelly at qut.edu.au Tue Apr 22 03:21:35 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Tue, 22 Apr 2008 17:21:35 +1000 Subject: [Ironruby-core] gem setup.rb Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979C@QUTEXMBX02.qut.edu.au> Still working towards executing setup.rb for gems ... After sidestepping the lack of a module_function implementation and implementing a few dummy modules such as etc.so ... 1) Undefined method 'extend' (missing from Kernel) see attached patch file that implements Kernel::extend and related Module::extend_object and Module::extended methods. 2) Undefined method 'singleton_methods' (missing from Kernel) - anyone feel like implementing this method? 3) Expression tranformation not implemented for Ruby.Compiler.Ast.MemberAssignmentExpression - need to generate MSA for expression of the form: lhs.member op= rhs (the lhs expression needs to be written to a local temp since it is used twice, once to read the value of member which is 'op'ed with the rhs, and a second time to write the result to member). 4) Undefined method 'fail' when attempting to alias - method fail is correctly defined in Kernel, but there is a bug in the method resolution algorithm used by the alias method. Inside a module, you can successfully call the fail method, but you can't alias it: module Fred begin fail rescue alias fail! fail end end When trying to call method 'fail', the method resolution starts looking in the singleton class of module Fred, but when trying to alias the method 'fail', it starts looking in module Fred. (I'll add these patches and bugs to the RubyForge tracker) Cheers, Wayne. From bacondarwin at googlemail.com Tue Apr 22 03:34:12 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Tue, 22 Apr 2008 08:34:12 +0100 Subject: [Ironruby-core] module_function In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979A@QUTEXMBX02.qut.edu.au> References: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979A@QUTEXMBX02.qut.edu.au> Message-ID: <000301c8a44b$43898e90$ca9cabb0$@com> I know that a IronRuby expects singleton methods to have a signature of the form SomeReturnType MySingletonMethod(CodeContext context, RubyClass klass, Other parameters, ...) And if you don't create them like this, e.g. forget the context or klass parameters you do get this problem. And instance methods, canonically to have the form SomeReturnType MyInstanceMethod(CodeContext context, object self, Other parameters, ...) Although instance methods seem to be more resilient to alternatives, such as not including the context parameter. I suspect that you will need to create a wrapper method around the method that you are converting in module_function so that it has the correct signature. Pete -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly Sent: Monday,21 April 21, 2008 23:58 To: ironruby-core at rubyforge.org Subject: [Ironruby-core] module_function Is anyone currently working on or have any ideas regarding the implementation of Module::module_function? (this is where I'm currently stuck in trying to execute setup.rb for gems) module_function is meant to take a list of names of instance methods and make then also callable as class (or singleton) methods. It's easy enough to locate the existing methods using something like: RubyMethodInfo method = (RubyMethodInfo)module.ResolveMethod(method_name); (BTW, why doesn't ResolveMethod return a RubyMethodInfo?) However, I'm not entirely sure how to programmatically create a new class method (in Ruby.NET we had a helper method that would create a singleton for a module if one didn't already exist, but I'm not sure what the equivalent of this is in IronRuby) Anyway, it seems that invoking: module.SingletonClass.DefineMethod( ...) creates a new method in the right place (provided SingletonClass has been properly initialized). However, when I try calling such a method as a class method I get a wrong number of arguments exception, presumably because different parameters are expected depending on whether it is called as an instance method or as a class method. Any ideas? Cheers, Wayne. _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From jflam at microsoft.com Tue Apr 22 08:43:24 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 22 Apr 2008 05:43:24 -0700 Subject: [Ironruby-core] SVN r94: Getting Ruby String to Rails spec pass rate of 89% Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92BC7FFF@NA-EXMSG-C115.redmond.corp.microsoft.com> Summary: Changes in String to get us closer to running Rails. We are now passing Rails specs at a 375/421 (89%) rate. String specs overall are passing at a 572/744 (76%) rate. Most of the specs that are failing are related to different regex implementation between .NET and Ruby. This shelveset passed SNAP this morning. Details: This is a targeted set of changes that aims to implement only the String methods that our Rails dynamic traces list. The goal is to get these changes to maximum conformance with the spec test suite. Overall, these are the test pass results from methods used by Rails: Pass Total % % 63 69 91% * 6 6 100% + 4 4 100% <=> 10 11 91% == 5 5 100% [] 88 89 99% chop 9 9 100% concat 10 10 100% delete[!] 10 11 91% downcase[!] 7 7 100% dump 4 4 100% each 8 10 80% empty? 1 1 100% gsub[!] 26 38 68% hash 1 1 100% inspect 2 3 67% length 1 1 100% match[=~] 11 11 100% replace 5 5 100% scan 11 15 73% size 1 1 100% split 26 27 96% strip[!] 4 5 80% sub[!] 26 39 67% to_i 10 12 83% to_s 3 3 100% to_str 3 3 100% to_sym 2 2 100% tr 11 11 100% unpack 0 1 0% upcase[!] 7 7 86% 375 421 89% Frozen / taint related changes: - Added Protocols.FlowTaint() helpers to add taint tracking to String APIs - Added Protocols.AssertNotFrozen() helpers - Simple changes in Hash and Array to clean up some of the simple frozen / taint specs that were failing. Regex related changes: - Added Match#begin, which is used by String APIs - Fixed Match#match and Match#=~ methods so that they pass the specs - Added Match.escape/quote and Match.last_match - Added some constructors and an IDuplicable implementation for Regexp builtin Miscellaneous changes: - 1 line change to Socket.cs that reflects changes in MutableString - Added helper methods and a new char ctor to MutableString - Kernel#clone, Kernel#dup, Kernel#to_s now flow taint correctly - Fixed a bug in at_exit related to recent DLR DynamicSites refactoring (rubycontext.cs). - Resets the baseline spec excludes to reflect new 572 passing baseline String formatter related changes: StringFormatter: This class contains a lot of changes to correctly support the String#% specs. That said, right now StringFormatter really needs a rewrite so that we align our error messages with Ruby error messages when format strings are incorrect. Some of the changes around how numbers are formatted will remain, but there is future work to be done here to clean up this class. We are mostly correct in the specs today, with just a few corner cases where we break. Some of these corner case examples are commented out in the modulo_spec.rb file. When we migrate to the latest Rubinius specs these will break again, which is fine since that will be a good time for us to revisit these changes. String related changes MutableStringOps: The specs that we are failing today fall into one of two camps: 1) those that are related to creating subclasses of String in methods that return Strings. - Added helpers to create String subclasses - due to a bug today in not calling inherited initializers, these helpers aren't wired up everywhere yet today. - Added helpers for detecting frozen strings. - Added RangeParser/IntervalParser helper classes to parse format strings used in #delete, #count, and #tr methods. These are strings of the form c1-c2 with negation (^) and intersection. - Started inserting ri#method documentation as comments before each method to better capture the Ruby semantics of a method in our sources. These docs are not as complete as the specs, which are much more authoritative here. - Many modifications to existing methods to support flowing taint and frozen semantics. - Fixed implementation of #<<, #concat. - Added 'turn-it-around' comparison logic to String#<=> - Added Regex support to #slice[!] methods - Rewrote String#chomp implementation to pass 100% of specs and run on Silverlight - Fixed implementations of #casecmp, #capitalize[!], #downcase[!], #swapcase[!], #upcase[!], #chop[!], - Added some missing metacharacters to #dump, #inspect. - Fixed implementation of #each, #each_line to correctly deal with defaults - Fixed a number of bugs in #sub[!], #gsub[!] - Removed overloads that take a string parameter. We only have overloads that accept MutableString and object (via Protocols.CastToString()). - Cleaned up implementation of #index - Added new implementations of #delete[!] and #count - Added #=~ and cleaned up #match - Added #scan implementation - Cleaned up #succ[!] - Added full implementation of #split[!] - Added an implementation of #to_i that uses Ruby tokenizer to generate output - Added full implementation of #replace - Added full implementation of #tr[!] There are also a ton of other DLR and Ruby-related changes in this changeset, but these are the most visible ones at this time. Will summarize details in a future mail. Thanks, -John From jflam at microsoft.com Tue Apr 22 09:55:56 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 22 Apr 2008 06:55:56 -0700 Subject: [Ironruby-core] Protocols and implicit conversions Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92BC8012@NA-EXMSG-C115.redmond.corp.microsoft.com> I wanted to call out a fairly simple pattern that shows up in our libraries that folks largely haven't caught onto in the patches that they've been submitting: Wayne recently submitted a patch for exist? and exists? which fixes bug #19626: [RubyMethod("exist?", RubyMethodAttributes.PublicSingleton)] [RubyMethod("exists?", RubyMethodAttributes.PublicSingleton)] public static bool Exists(object self/*!*/, MutableString/*!*/ path) { return File.Exists(path.ToString()) || Directory.Exists(path.ToString()); } While this works fine, if you pass it legal arguments, it blows up when the invariants are broken (eg path == null). You can see it blow up when you run the specs for this method from the command line via: rake spec file exist dox To make this patch complete, you'll need to add an overload that accepts a nullable object parameter, and add a [NotNull] attribute to the previous overload: [RubyMethod("exist?", RubyMethodAttributes.PublicSingleton)] [RubyMethod("exists?", RubyMethodAttributes.PublicSingleton)] public static bool Exists(object self/*!*/, [NotNull]MutableString/*!*/ path) { return File.Exists(path.ToString()) || Directory.Exists(path.ToString()); } [RubyMethod("exist?", RubyMethodAttributes.PublicSingleton)] [RubyMethod("exists?", RubyMethodAttributes.PublicSingleton)] public static bool Exists(CodeContext/*!*/ context, object self/*!*/, object path) { return Exists(self, Protocols.CastToString(context, path)); } Notice how the null case is taken care of by Protocols.CastToString(). It also will handle the case where the user passes a string that can 'act like' a string by implementing to_str. This is an *extremely* common case in the Ruby libraries. The [NotNull] attribute is used by the binder to ensure that a null is never passed as a parameter to the first overload, but instead directs the caller to the second overload. This is the case which correctly handles null (and is also reflected by the fact that we are declaring via comments that path is *nullable* eg missing the spec# bang). Let me know if this isn't clear or needs some further clarification. Thanks! -John From Tomas.Matousek at microsoft.com Tue Apr 22 11:40:55 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Tue, 22 Apr 2008 08:40:55 -0700 Subject: [Ironruby-core] Protocols and implicit conversions In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92BC8012@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92BC8012@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: Just typo: public static bool Exists(object self/*!*/, ... should be public static bool Exists(object/*!*/ self, ... /*!*/ is a type modifier. Anyway, note that [NotNull] and /*!*/ are two semantically different things. The attribute is directing the overload resolution to select a different overload if the argument is null. The non-null contract /*!*/ is declaring that the method expects the argument not to be null, otherwise an exception is thrown. Seems to be similar, but consider this case: [RubyMethod("eval")] public static object Evaluate(CodeContext/*!*/ context, object self, [NotNull]MutableString/*!*/ code, [Optional]Binding binding, [Optional, NotNull]MutableString file) { ... } The last parameter is Optional and NotNull. That means, if I pass null as 5th argument, this overload is not applicable. If I call this method only with 4 arguments, this overload is selected (provided that other arguments match the parameters) and 'file' parameter is assigned null. Therefore this parameter is not marked by /*!*/. Or I can just call it with 5 arguments, 5th being a string. Another difference is that the contract is not available at run-time. It's only used by tools that recognizes it (Spec#). Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Tuesday, April 22, 2008 6:56 AM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Protocols and implicit conversions I wanted to call out a fairly simple pattern that shows up in our libraries that folks largely haven't caught onto in the patches that they've been submitting: Wayne recently submitted a patch for exist? and exists? which fixes bug #19626: [RubyMethod("exist?", RubyMethodAttributes.PublicSingleton)] [RubyMethod("exists?", RubyMethodAttributes.PublicSingleton)] public static bool Exists(object self/*!*/, MutableString/*!*/ path) { return File.Exists(path.ToString()) || Directory.Exists(path.ToString()); } While this works fine, if you pass it legal arguments, it blows up when the invariants are broken (eg path == null). You can see it blow up when you run the specs for this method from the command line via: rake spec file exist dox To make this patch complete, you'll need to add an overload that accepts a nullable object parameter, and add a [NotNull] attribute to the previous overload: [RubyMethod("exist?", RubyMethodAttributes.PublicSingleton)] [RubyMethod("exists?", RubyMethodAttributes.PublicSingleton)] public static bool Exists(object self/*!*/, [NotNull]MutableString/*!*/ path) { return File.Exists(path.ToString()) || Directory.Exists(path.ToString()); } [RubyMethod("exist?", RubyMethodAttributes.PublicSingleton)] [RubyMethod("exists?", RubyMethodAttributes.PublicSingleton)] public static bool Exists(CodeContext/*!*/ context, object self/*!*/, object path) { return Exists(self, Protocols.CastToString(context, path)); } Notice how the null case is taken care of by Protocols.CastToString(). It also will handle the case where the user passes a string that can 'act like' a string by implementing to_str. This is an *extremely* common case in the Ruby libraries. The [NotNull] attribute is used by the binder to ensure that a null is never passed as a parameter to the first overload, but instead directs the caller to the second overload. This is the case which correctly handles null (and is also reflected by the fact that we are declaring via comments that path is *nullable* eg missing the spec# bang). Let me know if this isn't clear or needs some further clarification. Thanks! -John _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From michael.letterle at gmail.com Tue Apr 22 13:00:53 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Tue, 22 Apr 2008 13:00:53 -0400 Subject: [Ironruby-core] "Native" Zlib Implementation Patch Message-ID: A patch implementing Zlib decompression (with GZip decompression support) as a built in library has been submitted to RubyForge: http://rubyforge.org/tracker/index.php?func=detail&aid=19711&group_id=4359&atid=16800 . It's quite a bit faster then trying to use Zliby (this is essentially a port of that). It works, though binary files seem to be causing some problem, I suspect it's because of the differences in Unicode Strings in the CLR vs non-Unicode strings in ruby 1.8.6. Anyway, it's a start. -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From mental at rydia.net Tue Apr 22 13:39:08 2008 From: mental at rydia.net (MenTaLguY) Date: Tue, 22 Apr 2008 10:39:08 -0700 Subject: [Ironruby-core] IronRuby concurrency Message-ID: <99abacfbb6e83926dc711de61c861974@localhost> So, I was wondering what the IronRuby concurrency story was like at this point... are there any articles or other public resources on this topic? Thanks, -mental From jflam at microsoft.com Tue Apr 22 18:49:47 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 22 Apr 2008 15:49:47 -0700 Subject: [Ironruby-core] IronRuby patch # 19175 - compiling under Mono Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92BC84C2@NA-EXMSG-C115.redmond.corp.microsoft.com> Has this been fixed in Mono? I'm reluctant to make changes in our sources regarding this issue unless there is no workaround in Mono. Thanks, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080422/8925c192/attachment.html From michael.letterle at gmail.com Tue Apr 22 19:10:18 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Tue, 22 Apr 2008 19:10:18 -0400 Subject: [Ironruby-core] IronRuby patch # 19175 - compiling under Mono In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92BC84C2@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92BC84C2@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: There's a command line switch (--noconfig:Disables implicit references to assemblies) for the mono compiler that resolves the issue, Sanghyeon Seo has a patch here:http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/patch-mono-r93 Doesn't require altering the source files, just the rake file. The patch does contain some changes to some source files, but the changes don't appear to be related. On Tue, Apr 22, 2008 at 6:49 PM, John Lam (IRONRUBY) wrote: > > > > > Has this been fixed in Mono? I'm reluctant to make changes in our sources > regarding this issue unless there is no workaround in Mono. > > > > Thanks, > > -John > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From jflam at microsoft.com Tue Apr 22 19:12:01 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 22 Apr 2008 16:12:01 -0700 Subject: [Ironruby-core] IronRuby patch # 19175 - compiling under Mono In-Reply-To: References: <372109E149E8084D8E6C7D9CFD82E0632D92BC84C2@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92BC84E8@NA-EXMSG-C115.redmond.corp.microsoft.com> Ah yes, I could have sworn I saw this patch earlier. In the future, Seo - can you post your patches to Rubyforge so I don't wind up losing them in email? Thanks, -John > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Michael Letterle > Sent: Tuesday, April 22, 2008 4:10 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] IronRuby patch # 19175 - compiling under > Mono > > There's a command line switch (--noconfig:Disables implicit references > to assemblies) for the mono compiler that resolves the issue, Sanghyeon > Seo has a patch > here:http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/patch-mono- > r93 > Doesn't require altering the source files, just the rake file. The > patch does contain some changes to some source files, but the changes > don't appear to be related. > > On Tue, Apr 22, 2008 at 6:49 PM, John Lam (IRONRUBY) > wrote: > > > > > > > > > > Has this been fixed in Mono? I'm reluctant to make changes in our > > sources regarding this issue unless there is no workaround in Mono. > > > > > > > > Thanks, > > > > -John > > > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > > > > -- > Michael Letterle > [Polymath Prokrammer] > http://blog.prokrams.com > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core From jflam at microsoft.com Tue Apr 22 20:08:12 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 22 Apr 2008 17:08:12 -0700 Subject: [Ironruby-core] "Native" Zlib Implementation Patch In-Reply-To: References: Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92BC8536@NA-EXMSG-C115.redmond.corp.microsoft.com> Michael Letterle: > "Native" Zlib Implementation Patch Thanks for sending this in! FYI - a few quick pointers about your contribution. No need to take any action since I've fixed most of them on my machine already. 1. Bangs Please do your best to incorporate the bangs in your contributions. The bangs indicate a non-nullable reference type. I find that it's best if you create a VS macro to insert them - I bind this macro to the CTRL-! key: Sub InsertBang() DTE.ActiveDocument.Selection.Text = "/*!*/" End Sub This helps to reinforce in your mind (and in the mind of the code reviewer) whether a given reference type is non-nullable or not. This will also greatly help us out when we start running spec# for real across our codebase to look for violations of this contract. Generally you'll find that any time you get a CodeContext from us it's guaranteed to not be null, which means that you don't have to do a null check. The converse is also true - if you have a nullable reference type, you'll need to validate it with one of the helpers in our Microsoft.Scripting.ContractUtils class. 2. General formatting issues Please do try and stick with .NET naming conventions if possible when porting code from Java etc. I realize that it does take time to do this, and thanks, but it's either you do it or I have to :) Not a big deal since I can just do a CTRL-K CTRL-F on your code, but it would rock if you could format along the same lines as the rest of the code. 3. Testing / coverage If possible please let us know how many specs from the spec suite your code passes etc. That would help us determine how much to look into the codebase itself. Thanks, -John From michael.letterle at gmail.com Tue Apr 22 22:49:36 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Tue, 22 Apr 2008 22:49:36 -0400 Subject: [Ironruby-core] "Native" Zlib Implementation Patch In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92BC8536@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92BC8536@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: The rubinius specs for Zlib are... wanting. Though there are some. Are the rubinius specs used as is? On Tue, Apr 22, 2008 at 8:08 PM, John Lam (IRONRUBY) wrote: > Michael Letterle: > > > "Native" Zlib Implementation Patch > > Thanks for sending this in! > > FYI - a few quick pointers about your contribution. No need to take any action since I've fixed most of them on my machine already. > > 1. Bangs > > Please do your best to incorporate the bangs in your contributions. The bangs indicate a non-nullable reference type. I find that it's best if you create a VS macro to insert them - I bind this macro to the CTRL-! key: > > Sub InsertBang() > DTE.ActiveDocument.Selection.Text = "/*!*/" > End Sub > > This helps to reinforce in your mind (and in the mind of the code reviewer) whether a given reference type is non-nullable or not. This will also greatly help us out when we start running spec# for real across our codebase to look for violations of this contract. > > Generally you'll find that any time you get a CodeContext from us it's guaranteed to not be null, which means that you don't have to do a null check. The converse is also true - if you have a nullable reference type, you'll need to validate it with one of the helpers in our Microsoft.Scripting.ContractUtils class. > > 2. General formatting issues > > Please do try and stick with .NET naming conventions if possible when porting code from Java etc. I realize that it does take time to do this, and thanks, but it's either you do it or I have to :) Not a big deal since I can just do a CTRL-K CTRL-F on your code, but it would rock if you could format along the same lines as the rest of the code. > > 3. Testing / coverage > > If possible please let us know how many specs from the spec suite your code passes etc. That would help us determine how much to look into the codebase itself. > > Thanks, > -John > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From jflam at microsoft.com Tue Apr 22 23:23:51 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 22 Apr 2008 20:23:51 -0700 Subject: [Ironruby-core] "Native" Zlib Implementation Patch In-Reply-To: References: <372109E149E8084D8E6C7D9CFD82E0632D92BC8536@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92BC85C1@NA-EXMSG-C115.redmond.corp.microsoft.com> Michael Letterle: > > The rubinius specs for Zlib are... wanting. Though there are some. > Are the rubinius specs used as is? > Just peeked at the latest rubinius specs and there is some coverage. I'm going to start working on running the latest rubinius spec runner in my next checkin. -John From charles.nutter at Sun.COM Tue Apr 22 23:51:12 2008 From: charles.nutter at Sun.COM (Charles Oliver Nutter) Date: Tue, 22 Apr 2008 22:51:12 -0500 Subject: [Ironruby-core] Can't build after updating r94 Message-ID: <480EB230.4050005@sun.com> I know absolutely nothing about the build process, mono, or how this stuff is wired together, but I can't get it to build today. ~/NetBeansProjects/ironruby ? rake --trace compile mono=1 (in /Users/headius/NetBeansProjects/ironruby) ** Invoke compile (first_time) ** Invoke happy (first_time) ** Execute happy ** Invoke clean_build (first_time) ** Invoke happy ** Execute clean_build ** Invoke compile_dlr (first_time) ** Invoke clean_build ** Execute compile_dlr Read in 33 resources from '/users/headius/netbeansprojects/ironruby/src/microsoft.scripting.core/Microsoft.Scripting.txt' Writing resource file... Done. ./shell/BasicConsole.cs(25,33): error CS0246: The type or namespace name `IConsole' could not be found. Are you missing a using directive or an assembly reference? Compilation failed: 1 error(s), 0 warnings rake aborted! Command failed with status (1): [gmcs /out:"/users/headius/netbeansprojects...] /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:899:in `sh' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:906:in `call' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:906:in `sh' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:985:in `sh' ./context.rb:183:in `exec' ./context.rb:447:in `compile' ./context.rb:432:in `chdir' ./context.rb:432:in `compile' /Users/headius/NetBeansProjects/ironruby/rakefile:137 ./context.rb:578:in `instance_eval' ./context.rb:578:in `source_context' /Users/headius/NetBeansProjects/ironruby/rakefile:135 /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in `call' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in `execute' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `execute' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:508:in `invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `synchronize' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:518:in `invoke_prerequisites' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `send' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1183:in `each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:515:in `invoke_prerequisites' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:507:in `invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `synchronize' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:494:in `invoke' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1931:in `invoke_task' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in `standard_exception_handling' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1903:in `top_level' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1881:in `run' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in `standard_exception_handling' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1878:in `run' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/bin/rake:31 /usr/bin/rake:19:in `load' /usr/bin/rake:19 - Charlie From sanxiyn at gmail.com Wed Apr 23 00:28:29 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 23 Apr 2008 13:28:29 +0900 Subject: [Ironruby-core] Can't build after updating r94 In-Reply-To: <480EB230.4050005@sun.com> References: <480EB230.4050005@sun.com> Message-ID: <5b0248170804222128x25e15d07oa4c8ce29a01c4287@mail.gmail.com> 2008/4/23, Charles Oliver Nutter : > I know absolutely nothing about the build process, mono, or how this > stuff is wired together, but I can't get it to build today. > > ./shell/BasicConsole.cs(25,33): error CS0246: The type or namespace name > `IConsole' could not be found. Are you missing a using directive or an > assembly reference? Just delete the file. -- Seo Sanghyeon From charles.nutter at sun.com Wed Apr 23 00:56:37 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 22 Apr 2008 23:56:37 -0500 Subject: [Ironruby-core] Can't build after updating r94 In-Reply-To: <5b0248170804222128x25e15d07oa4c8ce29a01c4287@mail.gmail.com> References: <480EB230.4050005@sun.com> <5b0248170804222128x25e15d07oa4c8ce29a01c4287@mail.gmail.com> Message-ID: <480EC185.3080305@sun.com> Sanghyeon Seo wrote: > 2008/4/23, Charles Oliver Nutter : >> I know absolutely nothing about the build process, mono, or how this >> stuff is wired together, but I can't get it to build today. >> >> ./shell/BasicConsole.cs(25,33): error CS0246: The type or namespace name >> `IConsole' could not be found. Are you missing a using directive or an >> assembly reference? > > Just delete the file. Thanks...deleted it, and then SuperConsole.cs complains. Delete that, and ConsoleHost.cs complains. Delete that, and Program.cs complains. Delete that, and it doesn't appear IronRuby can start up: error CS5001: Program `/users/headius/netbeansprojects/ironruby/build/mono_debug/rbx.exe' does not contain a static `Main' method suitable for an entry point But deleting nothing, rake clean_build, and svn revert seems to get me to a different error: ** Execute compile_ruby ./Compiler/Parser/Parser.cs(51,17): error CS0104: `Action`2' is an ambiguous reference between `System.Action`2' and `Microsoft.Scripting.Utils.Action`2' /Library/Frameworks/Mono.framework/Versions/1.9/lib/mono/gac/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll (Location of the symbol related to previous error) /Users/headius/NetBeansProjects/ironruby/build/mono_debug/Microsoft.Scripting.Core.dll (Location of the symbol related to previous error) ./Compiler/Parser/Parser.cs(74,16): error CS0104: `Action`2' is an ambiguous reference between `System.Action`2' and `Microsoft.Scripting.Utils.Action`2' /Library/Frameworks/Mono.framework/Versions/1.9/lib/mono/gac/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll (Location of the symbol related to previous error) /Users/headius/NetBeansProjects/ironruby/build/mono_debug/Microsoft.Scripting.Core.dll (Location of the symbol related to previous error) Is clean simply not cleaning like it's supposed to? Or what? - Charlie From sanxiyn at gmail.com Wed Apr 23 06:18:39 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 23 Apr 2008 19:18:39 +0900 Subject: [Ironruby-core] Can't build after updating r94 In-Reply-To: <480EC185.3080305@sun.com> References: <480EB230.4050005@sun.com> <5b0248170804222128x25e15d07oa4c8ce29a01c4287@mail.gmail.com> <480EC185.3080305@sun.com> Message-ID: <5b0248170804230318l6ef903a8kac6d690b2ef8e0eb@mail.gmail.com> 2008/4/23, Charles Oliver Nutter : > ./Compiler/Parser/Parser.cs(51,17): error CS0104: `Action`2' is an > ambiguous reference between `System.Action`2' and > `Microsoft.Scripting.Utils.Action`2' System.Action collision is a different problem, but the same problem was there in r93 too. The solution is to add "swithces :all, 'noconfig'" in the correct place. I posted a patch here: http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/ I replied "delete the file" because one change between r93 and r94 was that microsoft.scipring.core/shell moved to microsoft.scripting/hosting/shell. I assumed that you had a leftover. -- Seo Sanghyeon From w.kelly at qut.edu.au Wed Apr 23 09:01:09 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Wed, 23 Apr 2008 23:01:09 +1000 Subject: [Ironruby-core] Module::class_eval Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979E@QUTEXMBX02.qut.edu.au> What's the story with ModuleOps.Evaluate(CodeContext, RubyModule, MutableString) ? I could get the previous version to work by uncommenting the code at the bottom to call scriptCode.Run but in the new version, the signature of the Run method has changed to expect a Scope rather than a CodeContext. What value should be passed as the Scope? I've tried context.Scope and context2.Scope - they both compile and execute OK, but they don't execute the code in the correct Scope. At this stage, I'm just interested in a quick fix to this method so that I can use it to continue exploring the rest of gems setup.rb Cheers, Wayne. From jflam at microsoft.com Wed Apr 23 09:05:39 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Wed, 23 Apr 2008 06:05:39 -0700 Subject: [Ironruby-core] Module::class_eval In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979E@QUTEXMBX02.qut.edu.au> References: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979E@QUTEXMBX02.qut.edu.au> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92BC865B@NA-EXMSG-C115.redmond.corp.microsoft.com> Wayne Kelly: > Module::class_eval eval and friends with binding support should arrive this week. Hang in there! Thanks, -John From charles.nutter at sun.com Wed Apr 23 09:07:02 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 23 Apr 2008 08:07:02 -0500 Subject: [Ironruby-core] Can't build after updating r94 In-Reply-To: <5b0248170804230318l6ef903a8kac6d690b2ef8e0eb@mail.gmail.com> References: <480EB230.4050005@sun.com> <5b0248170804222128x25e15d07oa4c8ce29a01c4287@mail.gmail.com> <480EC185.3080305@sun.com> <5b0248170804230318l6ef903a8kac6d690b2ef8e0eb@mail.gmail.com> Message-ID: <480F3476.6000406@sun.com> Sanghyeon Seo wrote: > 2008/4/23, Charles Oliver Nutter : >> ./Compiler/Parser/Parser.cs(51,17): error CS0104: `Action`2' is an >> ambiguous reference between `System.Action`2' and >> `Microsoft.Scripting.Utils.Action`2' > > System.Action collision is a different problem, but the same problem > was there in r93 too. The solution is to add "swithces :all, > 'noconfig'" in the correct place. I posted a patch here: > > http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/ > > I replied "delete the file" because one change between r93 and r94 was > that microsoft.scipring.core/shell moved to > microsoft.scripting/hosting/shell. I assumed that you had a leftover. Ahh, I had forgotten about the patch, ultimately reverted when I could not get deleting to work. Is that going to get included any time soon? - Charlie From michael.letterle at gmail.com Wed Apr 23 09:13:53 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Wed, 23 Apr 2008 09:13:53 -0400 Subject: [Ironruby-core] Can't build after updating r94 In-Reply-To: <480F3476.6000406@sun.com> References: <480EB230.4050005@sun.com> <5b0248170804222128x25e15d07oa4c8ce29a01c4287@mail.gmail.com> <480EC185.3080305@sun.com> <5b0248170804230318l6ef903a8kac6d690b2ef8e0eb@mail.gmail.com> <480F3476.6000406@sun.com> Message-ID: I think it's likely, judging by this topic: http://www.ruby-forum.com/topic/150570 On Wed, Apr 23, 2008 at 9:07 AM, Charles Oliver Nutter wrote: > Sanghyeon Seo wrote: > > 2008/4/23, Charles Oliver Nutter : > >> ./Compiler/Parser/Parser.cs(51,17): error CS0104: `Action`2' is an > >> ambiguous reference between `System.Action`2' and > >> `Microsoft.Scripting.Utils.Action`2' > > > > System.Action collision is a different problem, but the same problem > > was there in r93 too. The solution is to add "swithces :all, > > 'noconfig'" in the correct place. I posted a patch here: > > > > http://sparcs.kaist.ac.kr/~tinuviel/download/IronRuby/ > > > > I replied "delete the file" because one change between r93 and r94 was > > that microsoft.scipring.core/shell moved to > > microsoft.scripting/hosting/shell. I assumed that you had a leftover. > > Ahh, I had forgotten about the patch, ultimately reverted when I could > not get deleting to work. Is that going to get included any time soon? > > - Charlie > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From bacondarwin at googlemail.com Wed Apr 23 09:16:47 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Wed, 23 Apr 2008 14:16:47 +0100 Subject: [Ironruby-core] Module::class_eval In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979E@QUTEXMBX02.qut.edu.au> References: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979E@QUTEXMBX02.qut.edu.au> Message-ID: <001701c8a544$4a1d1c00$de575400$@com> Try: return scriptCode.Run(context2.Scope, false); Haven't tested that though. Pete _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly Sent: Wednesday,23 April 23, 2008 14:01 To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Module::class_eval What's the story with ModuleOps.Evaluate(CodeContext, RubyModule, MutableString) ? I could get the previous version to work by uncommenting the code at the bottom to call scriptCode.Run but in the new version, the signature of the Run method has changed to expect a Scope rather than a CodeContext. What value should be passed as the Scope? I've tried context.Scope and context2.Scope - they both compile and execute OK, but they don't execute the code in the correct Scope. At this stage, I'm just interested in a quick fix to this method so that I can use it to continue exploring the rest of gems setup.rb Cheers, Wayne. _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From w.kelly at qut.edu.au Thu Apr 24 09:32:55 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Thu, 24 Apr 2008 23:32:55 +1000 Subject: [Ironruby-core] New Towards Rails WIKI page Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979F@QUTEXMBX02.qut.edu.au> I've created a new WIKI page at http://ironruby.rubyforge.org/wiki/wiki.pl?TowardsRails to summarize the current progress towards executing Gems and Rails. It contains a priority list of unresolved bugs, unimplemented methods and uncommitted patches. It's certainly not a complete list, just those issues that I've explicitly encountered so far. Anyone looking for a method to implement or a bug to fix could certainly look here. Feel free to edit, append and further annotate it as appropriate and put your name against methods on the list. Cheers, Wayne. From michael.letterle at gmail.com Thu Apr 24 09:52:25 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Thu, 24 Apr 2008 09:52:25 -0400 Subject: [Ironruby-core] New Towards Rails WIKI page In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979F@QUTEXMBX02.qut.edu.au> References: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979F@QUTEXMBX02.qut.edu.au> Message-ID: Has anyone told you lately how much you rock? Cause, you rock! On Thu, Apr 24, 2008 at 9:32 AM, Wayne Kelly wrote: > I've created a new WIKI page at http://ironruby.rubyforge.org/wiki/wiki.pl?TowardsRails to summarize the current progress towards executing Gems and Rails. It contains a priority list of unresolved bugs, unimplemented methods and uncommitted patches. It's certainly not a complete list, just those issues that I've explicitly encountered so far. > > Anyone looking for a method to implement or a bug to fix could certainly look here. > > Feel free to edit, append and further annotate it as appropriate and put your name against methods on the list. > > Cheers, Wayne. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From jdeville at microsoft.com Thu Apr 24 10:56:08 2008 From: jdeville at microsoft.com (Jim Deville) Date: Thu, 24 Apr 2008 07:56:08 -0700 Subject: [Ironruby-core] New Towards Rails WIKI page In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979F@QUTEXMBX02.qut.edu.au> References: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979F@QUTEXMBX02.qut.edu.au> Message-ID: Thanks! -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly Sent: Thursday, April 24, 2008 6:33 AM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] New Towards Rails WIKI page I've created a new WIKI page at http://ironruby.rubyforge.org/wiki/wiki.pl?TowardsRails to summarize the current progress towards executing Gems and Rails. It contains a priority list of unresolved bugs, unimplemented methods and uncommitted patches. It's certainly not a complete list, just those issues that I've explicitly encountered so far. Anyone looking for a method to implement or a bug to fix could certainly look here. Feel free to edit, append and further annotate it as appropriate and put your name against methods on the list. Cheers, Wayne. _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From jflam at microsoft.com Thu Apr 24 12:12:53 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Thu, 24 Apr 2008 09:12:53 -0700 Subject: [Ironruby-core] New Towards Rails WIKI page In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979F@QUTEXMBX02.qut.edu.au> References: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA5979F@QUTEXMBX02.qut.edu.au> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92C65C0C@NA-EXMSG-C115.redmond.corp.microsoft.com> Wayne Kelly: > New Towards Rails WIKI page Awesome. Thanks for doing this, Wayne! FYI I've gone through most of your patches and accepted the ones that make most sense (see the followup patch mails for more details). I'll come back and update this page once we push the update out to SVN. Thanks, -John From jflam at microsoft.com Thu Apr 24 15:45:11 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Thu, 24 Apr 2008 12:45:11 -0700 Subject: [Ironruby-core] Seo's patch for building on mono Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92C65DF4@NA-EXMSG-C115.redmond.corp.microsoft.com> FYI I'm accepting part of the patch only. This won't be accepted - if folks want this to compile under Mono, please submit a patch that fixes this correctly (new defines etc). Index: src/microsoft.scripting.core/shell/BasicConsole.cs protected void WriteColor(TextWriter output, string str, ConsoleColor c) { -#if !SILVERLIGHT // Console.ForegroundColor - ConsoleColor origColor = Console.ForegroundColor; - Console.ForegroundColor = c; -#endif output.Write(str); output.Flush(); - -#if !SILVERLIGHT // Console.ForegroundColor - Console.ForegroundColor = origColor; -#endif } Regarding the Mono compiler bug: will the latest mono c# compiler compile these? I'm reluctant to change our sources Index: src/ironruby/Builtins/RubyModule.cs =================================================================== - _mixins = ArrayUtils.InsertAt(_mixins, 0, allModules.ToArray()); + _mixins = ArrayUtils.InsertAt(_mixins, 0, allModules.ToArray()); Index: src/microsoft.scripting.core/utils/ArrayUtils.cs =================================================================== - return InsertAt(MakeArray(list), index, items); + return InsertAt(MakeArray(list), index, items); Thanks, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080424/7d96a2d0/attachment.html From brianblackwell at realemail.net Thu Apr 24 21:19:55 2008 From: brianblackwell at realemail.net (Brian Blackwell) Date: Fri, 25 Apr 2008 11:19:55 +1000 Subject: [Ironruby-core] Running activerecord Message-ID: <1209086395.10576.1249769439@webmail.messagingengine.com> On Fri, 18 Apr 2008 15:56:32 -0700, "John Lam (IRONRUBY)" said: > > Thanks for doing this work, Brian! This will give me a bunch of things to > look at around the core libs this weekend. Thanks John! I have encountered some further issues trying to run activerecord which I will detail in a moment, but firstly I've worked out what is going on with issue (9) in my previous email: > (9) Problem with > activesupport-2.0.2\lib\active_support\core_ext\array\conversions.rb > - unknown: Cannot cast from 'Microsoft.Scripting.SymbolId' to > 'Ruby.Builtins.Proc' > (ArgumentError) > - This is the offending piece of code in conversions.rb: > > def to_param > map(&:to_param).join '/' > end The & operator should call to_proc on the object, but IronRuby is currently not doing so - I have filed a bug report on RubyForge. Symbol.to_proc is defined in activesupport in order to support the above piece of syntactic sugar. "&:some_symbol" is simply shorthand for "Proc.new { |a| a.some_symbol }", so as a temporary workaround, any such occurrences in activesupport can be replaced with the latter expression. Here are some new issues that I have encountered with activesupport/activerecord: (1) Missing library stringio - As a workaround, I copied the pure Ruby implementation from YAML (this should be in C:\ruby\lib\ruby\1.8\yaml\stringio.rb in the MRI distribution). (2) Problem with active_support/core_ext/logger.rb :0:in `define_around_helper': wrong number or type of arguments for `module_eval' (ArgumentError) - There is currently no implementation of module_eval that accepts a string parameter. As a workaround, I rewrote logger.rb so that it passes a block to module_eval (see attached logger.rb). John has mentioned that the eval methods should be coming soon, which would be very helpful indeed... (3) Problem with active_support/core_ext/module/attr_internal :0:in `main': undefined local variable or method `attr_internal_naming_format=' for Module:Class (NoMethodError) - The same problem as (2): activesupport defines a method mattr_accessor which calls module_eval with a string parameter. As a workaround, I manually defined the accessor attr_internal_naming_format in attr_internal.rb (see attachment) (4) Missing method Regexp.quote - active_support\core_ext\pathname.rb requires the Ruby library pathname, which in turn calls Regexp.quote. - Workaround: commented out "require 'pathname'" (5) Problem with active_support/core_ext/string/iterators.rb - Logical operators in method arguments won't parse - the following line is the culprit: loop { yield(scanner.scan(char) || break) } - I have filed a bug report in RubyForge. Wayne Kelly has confirmed that this is a parser bug (incorrect grammar) - see http://rubyforge.org/tracker/index.php?func=detail&aid=19672&group_id=4359&atid=16798 - As a workaround, I rewrote the above line as: loop do s = scanner.scan(char) if !s break end yield(s) end - We are also missing library 'strscan.so' - but StringScanner is built into IronRuby, so as a workaround, I changed the first line to: require 'strscan' unless defined?(StringScanner) More activesupport/activerecord observations should be coming soon. I will add them to Wayne's TowardsRails Wiki page at some point. -Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: attr_internal.rb Type: application/x-ruby Size: 1193 bytes Desc: not available Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080425/91c5fb1c/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: logger.rb Type: application/x-ruby Size: 875 bytes Desc: not available Url : http://rubyforge.org/pipermail/ironruby-core/attachments/20080425/91c5fb1c/attachment-0001.bin From Jimmy.Schementi at microsoft.com Thu Apr 24 23:33:17 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Thu, 24 Apr 2008 20:33:17 -0700 Subject: [Ironruby-core] Manipulating Silverlight controls dynamically from IronRuby - is it currently possible ? In-Reply-To: <4a68b8cf0804080542l77e76679xf760b742747d62c9@mail.gmail.com> References: <4a68b8cf0804080516n2a872d3fs88af9886bb4e1435@mail.gmail.com> <4a68b8cf0804080542l77e76679xf760b742747d62c9@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284580224A53@NA-EXMSG-C116.redmond.corp.microsoft.com> Hey Thibaut, sorry for the very delayed response ... Every Silverlight object you place on a page is sandboxed, so other Silverlight objects cannot access each other. So a Silverlight greasemonkey-esk thing isn't really possible. =( When you create a Silverlight object, you implicitly say whether you want to use the Silverlight 1 or Silverlight 2 behavior with the 'source' attribute; when you give it a XAML file: You're saying you want to use Silverlight 1, which bypasses the CLR and gives you JavaScript programmability of the Silverlight visual elements. However, when you give it a xap file: You're saying you want to use Silverlight 2, which gives you Ruby, Python, C#, etc. Unfortunately, there's no way to combine these "modes", so you can have native JavaScript and .NET languages both manipulating the Silverlight control. However, if you're just using HTML, you *can* use Ruby to monkey-patch the page. =) Hope that answers your questions, ~Jimmy From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re Sent: Tuesday, April 08, 2008 5:42 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Manipulating Silverlight controls dynamically from IronRuby - is it currently possible ? Hi Ivan, thanks a lot for all this, that will definitely be useful! > Is it currently possible to add children to an existing Silverlight control from the ruby code side ? Any hint most welcome on that point too ! cheers -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080424/0ced85c0/attachment-0001.html From sanxiyn at gmail.com Fri Apr 25 01:49:01 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 25 Apr 2008 14:49:01 +0900 Subject: [Ironruby-core] Seo's patch for building on mono In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C65DF4@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92C65DF4@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <5b0248170804242249j48f50effg6602a59d51277ddb@mail.gmail.com> 2008/4/25, John Lam (IRONRUBY) : > FYI I'm accepting part of the patch only. This won't be accepted ? if folks > want this to compile under Mono, please submit a patch that fixes this > correctly (new defines etc). > > (Regarding Mono console workaround and Mono compiler workaround) I never expected otherwise. :-) Those workarounds are there for people who want to try IronRuby on Mono right now. I never intended them to be merged. -- Seo Sanghyeon From jflam at microsoft.com Fri Apr 25 23:47:23 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Fri, 25 Apr 2008 20:47:23 -0700 Subject: [Ironruby-core] SVN r96 is out Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92C6650F@NA-EXMSG-C115.redmond.corp.microsoft.com> This revision integrates a number of smaller community contributions from Eric Nicholson, Wayne Kelly, Jayme Edwards, and Seo Sanghyeon. Patches 19708, 19745, 19746, 19748, 19749 from Wayne Kelly Patch 19754 from Nobody (trivial fix for range error in GetCurrentMatchGroup) Patch 19230 from Eric Nicholson (Time) Patch 19004 from Jayme Edwards (File.expand_path) And a patch from Seo that fixes some Mono build issues There is also the long-awaited patch from Tomas that contains our first pass at implementing eval(string) with binding support. This involved a lot of effort from Tomas, as it is one of the most complex features in the language. Congrats! This revision implements Module.nesting, which was blocking a number of specs from running. This revision now passes 2005/2961 (67%) of the specs. There are also a number of bug fixes in this patch as we start burning down some of the bugs from Rubyforge: 19755, 19626, 19625. Thanks, -John From paul.batum at gmail.com Sat Apr 26 14:34:20 2008 From: paul.batum at gmail.com (Paul Batum) Date: Sat, 26 Apr 2008 19:34:20 +0100 Subject: [Ironruby-core] rbx.exe hits 3GB memory usage during "rake test" Message-ID: <5c1715780804261134n5d1ca443p964ed295770aec70@mail.gmail.com> Hi there, Today I decided to take a look at IronRuby. I pulled the source down as demonstrated in the video, followed the build instructions on the wiki, and then ran the unit tests using the command 'rake test'. After letting it execute for a minute or two, I noticed no new results were appearing, my system was no longer responding properly and the rbx.exe process was using approximately 3GB of memory. I killed it, and this is is what was in the console buffer: repro: (a,b),c = *[nil] nil; nil; nil; repro: (a,b),c = *[1] 1; nil; nil; repro: (a,b),c = *[1,2] 1; nil; 2; repro: (a,b),c = 1,*[2,3] 1; nil; 2; repro: (a,b),c = *[[]] nil; nil; nil; repro: (a,b),c = 1,*[] 1; nil; nil; repro: (a,b),c = [1,2],3 1; 2; 3; repro: (a,b),c = nil,1 nil; nil; 1; rake aborted! I'm running 64-bit Vista. I did a 'gem update' before building the source. ruby -v gives me: ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] After it happened the first time, I deleted my entire local copy of the source, pulled it all down again and then got the exact same result. I was wondering whether anyone has come across this before or has any suggestions. Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tranqy at gmail.com Sat Apr 26 15:41:29 2008 From: tranqy at gmail.com (Aaron Junod) Date: Sat, 26 Apr 2008 15:41:29 -0400 Subject: [Ironruby-core] rbx.exe hits 3GB memory usage during "rake test" In-Reply-To: <5c1715780804261134n5d1ca443p964ed295770aec70@mail.gmail.com> References: <5c1715780804261134n5d1ca443p964ed295770aec70@mail.gmail.com> Message-ID: I just ran rake test and didn't get the same result. rbx never took more then 50 megs of ram, but the process ended with the error below after running for a few minutes. I'm on the same version of Ruby as you, but running 32 bit Windows 2k3 Standard. What version is your pathname2 gem (I think that's the only gem that's required, and I know there are version problems there). I'm on 1.5.2. Did you try rake spec as well? :0:in `do_generate': undefined local variable or method `methods' for main:Objec t (NoMethodError) from :0:in `#block162' from c:\IronRuby\src\IronRuby.Libraries\Extensions\IListOps.cs:785:in `E ach' from :0:in `Initialize##1'rake aborted! Command failed with status (1): ["c:\ironruby\build\debug\rbx.exe" "test_eh...] C:/IronRuby/rakefile:196 (See full trace by running task with --trace) C:\IronRuby> On Sat, Apr 26, 2008 at 2:34 PM, Paul Batum wrote: > Hi there, > > Today I decided to take a look at IronRuby. I pulled the source down as > demonstrated in the video, followed the build instructions on the wiki, and > then ran the unit tests using the command 'rake test'. After letting it > execute for a minute or two, I noticed no new results were appearing, my > system was no longer responding properly and the rbx.exe process was using > approximately 3GB of memory. I killed it, and this is is what was in the > console buffer: > > repro: (a,b),c = *[nil] > nil; nil; nil; > repro: (a,b),c = *[1] > 1; nil; nil; > repro: (a,b),c = *[1,2] > 1; nil; 2; > repro: (a,b),c = 1,*[2,3] > 1; nil; 2; > repro: (a,b),c = *[[]] > nil; nil; nil; > repro: (a,b),c = 1,*[] > 1; nil; nil; > repro: (a,b),c = [1,2],3 > 1; 2; 3; > repro: (a,b),c = nil,1 > nil; nil; 1; > rake aborted! > > I'm running 64-bit Vista. I did a 'gem update' before building the source. > ruby -v gives me: > > ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] > > After it happened the first time, I deleted my entire local copy of the > source, pulled it all down again and then got the exact same result. > > I was wondering whether anyone has come across this before or has any > suggestions. Cheers! > > _______________________________________________ > 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 jflam at microsoft.com Sat Apr 26 16:42:31 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Sat, 26 Apr 2008 13:42:31 -0700 Subject: [Ironruby-core] rbx.exe hits 3GB memory usage during "rake test" In-Reply-To: References: <5c1715780804261134n5d1ca443p964ed295770aec70@mail.gmail.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92C66553@NA-EXMSG-C115.redmond.corp.microsoft.com> Sorry about the experience - I haven't been using rake test as a part of our test matrix for some time now - I'll update the tests and the Rakefile in the next release. In the meantime, the most comprehensive way of running tests are the community-produced specs. You can run these via: rake spec - - coverage This will give you an indication of the pass / fail rate of the specs which can be found under tests\ironruby\specs\core\** Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Aaron Junod Sent: Saturday, April 26, 2008 12:41 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] rbx.exe hits 3GB memory usage during "rake test" I just ran rake test and didn't get the same result. rbx never took more then 50 megs of ram, but the process ended with the error below after running for a few minutes. I'm on the same version of Ruby as you, but running 32 bit Windows 2k3 Standard. What version is your pathname2 gem (I think that's the only gem that's required, and I know there are version problems there). I'm on 1.5.2. Did you try rake spec as well? :0:in `do_generate': undefined local variable or method `methods' for main:Objec t (NoMethodError) from :0:in `#block162' from c:\IronRuby\src\IronRuby.Libraries\Extensions\IListOps.cs:785:in `E ach' from :0:in `Initialize##1'rake aborted! Command failed with status (1): ["c:\ironruby\build\debug\rbx.exe" "test_eh...] C:/IronRuby/rakefile:196 (See full trace by running task with --trace) C:\IronRuby> On Sat, Apr 26, 2008 at 2:34 PM, Paul Batum > wrote: Hi there, Today I decided to take a look at IronRuby. I pulled the source down as demonstrated in the video, followed the build instructions on the wiki, and then ran the unit tests using the command 'rake test'. After letting it execute for a minute or two, I noticed no new results were appearing, my system was no longer responding properly and the rbx.exe process was using approximately 3GB of memory. I killed it, and this is is what was in the console buffer: repro: (a,b),c = *[nil] nil; nil; nil; repro: (a,b),c = *[1] 1; nil; nil; repro: (a,b),c = *[1,2] 1; nil; 2; repro: (a,b),c = 1,*[2,3] 1; nil; 2; repro: (a,b),c = *[[]] nil; nil; nil; repro: (a,b),c = 1,*[] 1; nil; nil; repro: (a,b),c = [1,2],3 1; 2; 3; repro: (a,b),c = nil,1 nil; nil; 1; rake aborted! I'm running 64-bit Vista. I did a 'gem update' before building the source. ruby -v gives me: ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] After it happened the first time, I deleted my entire local copy of the source, pulled it all down again and then got the exact same result. I was wondering whether anyone has come across this before or has any suggestions. Cheers! _______________________________________________ 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 Tomas.Matousek at microsoft.com Sat Apr 26 21:07:21 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Sat, 26 Apr 2008 18:07:21 -0700 Subject: [Ironruby-core] rbx.exe hits 3GB memory usage during "rake test" In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66553@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <5c1715780804261134n5d1ca443p964ed295770aec70@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66553@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: I know about this issue, it's a bug in IronRuby that leads to massive memory leaks. I think it could be that 64bit pointers are just twice as big so it consumes even more memory there. Will get to fixing it soon. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Saturday, April 26, 2008 1:43 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] rbx.exe hits 3GB memory usage during "rake test" Sorry about the experience - I haven't been using rake test as a part of our test matrix for some time now - I'll update the tests and the Rakefile in the next release. In the meantime, the most comprehensive way of running tests are the community-produced specs. You can run these via: rake spec - - coverage This will give you an indication of the pass / fail rate of the specs which can be found under tests\ironruby\specs\core\** Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Aaron Junod Sent: Saturday, April 26, 2008 12:41 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] rbx.exe hits 3GB memory usage during "rake test" I just ran rake test and didn't get the same result. rbx never took more then 50 megs of ram, but the process ended with the error below after running for a few minutes. I'm on the same version of Ruby as you, but running 32 bit Windows 2k3 Standard. What version is your pathname2 gem (I think that's the only gem that's required, and I know there are version problems there). I'm on 1.5.2. Did you try rake spec as well? :0:in `do_generate': undefined local variable or method `methods' for main:Objec t (NoMethodError) from :0:in `#block162' from c:\IronRuby\src\IronRuby.Libraries\Extensions\IListOps.cs:785:in `E ach' from :0:in `Initialize##1'rake aborted! Command failed with status (1): ["c:\ironruby\build\debug\rbx.exe" "test_eh...] C:/IronRuby/rakefile:196 (See full trace by running task with --trace) C:\IronRuby> On Sat, Apr 26, 2008 at 2:34 PM, Paul Batum > wrote: Hi there, Today I decided to take a look at IronRuby. I pulled the source down as demonstrated in the video, followed the build instructions on the wiki, and then ran the unit tests using the command 'rake test'. After letting it execute for a minute or two, I noticed no new results were appearing, my system was no longer responding properly and the rbx.exe process was using approximately 3GB of memory. I killed it, and this is is what was in the console buffer: repro: (a,b),c = *[nil] nil; nil; nil; repro: (a,b),c = *[1] 1; nil; nil; repro: (a,b),c = *[1,2] 1; nil; 2; repro: (a,b),c = 1,*[2,3] 1; nil; 2; repro: (a,b),c = *[[]] nil; nil; nil; repro: (a,b),c = 1,*[] 1; nil; nil; repro: (a,b),c = [1,2],3 1; 2; 3; repro: (a,b),c = nil,1 nil; nil; 1; rake aborted! I'm running 64-bit Vista. I did a 'gem update' before building the source. ruby -v gives me: ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] After it happened the first time, I deleted my entire local copy of the source, pulled it all down again and then got the exact same result. I was wondering whether anyone has come across this before or has any suggestions. Cheers! _______________________________________________ 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 steve.eichert at gmail.com Sat Apr 26 22:11:05 2008 From: steve.eichert at gmail.com (Steve Eichert) Date: Sat, 26 Apr 2008 22:11:05 -0400 Subject: [Ironruby-core] rbx.exe hits 3GB memory usage during "rake test" In-Reply-To: References: <5c1715780804261134n5d1ca443p964ed295770aec70@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66553@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: After lurking on these forums for a while, and getting myself up to speed on where the project is, I'd like to see if I can lend a hand by contributing to the project. I've taken care of getting the contributor agreement squared away, so now I'm looking for some recommendations on what could use some attention. Is there a list of prioritized "items" that would benefit from some community love? Cheers, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.eichert at gmail.com Sat Apr 26 22:15:47 2008 From: steve.eichert at gmail.com (Steve Eichert) Date: Sat, 26 Apr 2008 22:15:47 -0400 Subject: [Ironruby-core] lending a hand Message-ID: After lurking on these forums for a while, and getting myself up to speed on where the project is, I'd like to see if I can lend a hand by contributing to the project. I've taken care of getting the contributor agreement squared away, so now I'm looking for some recommendations on what could use some attention. Is there a list of prioritized "items" that would benefit from some community love? Cheers, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan at flanders.co.nz Sun Apr 27 03:54:25 2008 From: ivan at flanders.co.nz (Ivan Porto Carrero) Date: Sun, 27 Apr 2008 19:54:25 +1200 Subject: [Ironruby-core] Databinding with WPF and Silverlight Message-ID: Hi Will plain ruby objects be able to participate in the WPF databinding scenario or I may be doing it wrong ? I'm asking because I tried the following and the C# class works but the ruby class doesn't. If I replace Person.new with CSPerson.new it works. I can bind to arrays with simple types and I've tried binding to Name or name. public class CSPerson { public CSPerson(int id, string name, int age){ Id=id; Name=name; Age=age; } public int Id{get; set;} public string Name{get; set;} public int Age{get; set;} } # get the necessary assemblies loaded for .NET require 'mscorlib' require 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' require 'System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' require 'PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' require 'PresentationCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' require File.expand_path('./csperson.dll' ) # include some namespaces for easy access include System include System::Windows include System::Windows::Markup include System::Xml class Person attr_accessor :name, :age, :id def initialize(id, name, age) @id, @name, @age = id, name, age end end #run the application xaml_path = "default.xaml" obj = XamlReader.load XmlReader.create(xaml_path) people = [] people << Person.new(1, "ivan", 30) people << Person.new(2, "jeff", 25) people << Person.new(3, "mark", 38) people << Person.new(4, "vicky", 33) obj.find_name('list').items_source = people Application.new.run obj Thanks Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.kelly at qut.edu.au Sun Apr 27 20:27:54 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Mon, 28 Apr 2008 10:27:54 +1000 Subject: [Ironruby-core] Gems progress summary In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C6650F@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92C6650F@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2FE5F590@QUTEXMBX02.qut.edu.au> Following the release of r96 I thought I'd summarize the current progress status in attempting to execute setup.rb for Gems ... Executing setup.rb requires 89 separate ruby source files to be loaded. (Many of these same files are also required by Rails). Currently, IronRuby is able to successfully load 33 (37%) of those source files. The remaining 56 currently fail to load for the following reasons: 11 - Module::class_eval not implemented 10 - Regexp.initialize(String, Fixnum, String) not implemented [bug #19806] 8 - MemberAssignmentExpression not implemented 6 - Module::module_function not implemented 4 - Alias resolution problem [bug #19706] 4 - YAML not implemented 3 - Can't inherit from Numeric [bug #19804] 3 - Syntax error relating to JumpStatements [bug #19803] 3 - Class.initialize() not implemented [bug #19805] 2 - Interrupt class not defined 1 - Module::extend_object not implemented See http://ironruby.rubyforge.org/wiki/wiki.pl?TowardsRails for more details of these issues. Cheers, Wayne. From lists at ruby-forum.com Mon Apr 28 00:37:52 2008 From: lists at ruby-forum.com (Rahil Kantharia) Date: Mon, 28 Apr 2008 06:37:52 +0200 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog Message-ID: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> Hi, I was just referring a blog from Charles Nutter about his thinking on IronRuby and future implementations for Rails. Here's the link.. http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html Just wondering, how true it sounds... I do not agree on many points. Looking forward to read more comments on this. Thanks -- Posted via http://www.ruby-forum.com/. From sanxiyn at gmail.com Mon Apr 28 01:31:21 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 28 Apr 2008 14:31:21 +0900 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> Message-ID: <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> 2008/4/28 Rahil Kantharia : > http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html > > Just wondering, how true it sounds... I do not agree on many points. > Looking forward to read more comments on this. It seems to be a rather good overview of the status to me. I mostly agree, except for the accusation that "Microsoft would never back an OSS web framework like Rails in preference to its own". -- Seo Sanghyeon From jflam at microsoft.com Mon Apr 28 10:05:02 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Mon, 28 Apr 2008 07:05:02 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Sanghyeon Seo: > It seems to be a rather good overview of the status to me. I mostly > agree, except for the accusation that "Microsoft would never back an > OSS web framework like Rails in preference to its own". He also gets a number of important technical details wrong about IronRuby, I'll respond later today. Thanks, -John From jflam at microsoft.com Mon Apr 28 10:10:16 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Mon, 28 Apr 2008 07:10:16 -0700 Subject: [Ironruby-core] Gems progress summary In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E2FE5F590@QUTEXMBX02.qut.edu.au> References: <372109E149E8084D8E6C7D9CFD82E0632D92C6650F@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E2FE5F590@QUTEXMBX02.qut.edu.au> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92C66681@NA-EXMSG-C115.redmond.corp.microsoft.com> Fantastic, Wayne! Thanks so much for staying on top of this. Will dig through your new bug reports this morning. Thanks, -John -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly Sent: Sunday, April 27, 2008 5:28 PM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Gems progress summary Following the release of r96 I thought I'd summarize the current progress status in attempting to execute setup.rb for Gems ... Executing setup.rb requires 89 separate ruby source files to be loaded. (Many of these same files are also required by Rails). Currently, IronRuby is able to successfully load 33 (37%) of those source files. The remaining 56 currently fail to load for the following reasons: 11 - Module::class_eval not implemented 10 - Regexp.initialize(String, Fixnum, String) not implemented [bug #19806] 8 - MemberAssignmentExpression not implemented 6 - Module::module_function not implemented 4 - Alias resolution problem [bug #19706] 4 - YAML not implemented 3 - Can't inherit from Numeric [bug #19804] 3 - Syntax error relating to JumpStatements [bug #19803] 3 - Class.initialize() not implemented [bug #19805] 2 - Interrupt class not defined 1 - Module::extend_object not implemented See http://ironruby.rubyforge.org/wiki/wiki.pl?TowardsRails for more details of these issues. Cheers, Wayne. _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From jflam at microsoft.com Mon Apr 28 10:14:58 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Mon, 28 Apr 2008 07:14:58 -0700 Subject: [Ironruby-core] Databinding with WPF and Silverlight In-Reply-To: References: Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92C66688@NA-EXMSG-C115.redmond.corp.microsoft.com> Ivan Porto Carrero: > Will plain ruby objects be able to participate in the WPF databinding > scenario or I may be doing it wrong ? I'm asking because I tried the > following and the C# class works but the ruby class doesn't. If I > replace Person.new with CSPerson.new it works. This will definitely work in the future. We'll revisit this post-RailsConf. I had this working a couple of years ago with RubyCLR: http://www.iunknown.com/2006/05/activerecord-an.html Thanks, -John From m.david at xmlhacker.com Mon Apr 28 10:50:48 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 08:50:48 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> Message-ID: On Sun, 27 Apr 2008 23:31:21 -0600, Sanghyeon Seo wrote: >> Just wondering, how true it sounds... I do not agree on many points. >> Looking forward to read more comments on this. > It seems to be a rather good overview of the status to me. I mostly > agree, except for the accusation that "Microsoft would never back an > OSS web framework like Rails in preference to its own". Hmmm... I think that's a pretty fair statement from Charlie. If I'm understanding his point correctly, Microsoft will never turn away from ASP.NET in favor or Rails, and instead will continue to push ASP.NET in the various directions necessary to keep up with the trends (e.g. ASP.NET MVC Framework.) They'll certainly put the money into providing support for Rails, whether that be through IronRuby, or directly through MRI via the IIS7 FastCGI layer. But it will never become the King at DEV.MSFT. Nor should it. ASP.NET is a kick a$$ web application framework. And regardless of the popularity of Rails in the OSS communities of the world, it will be a *VERY* long time -- if ever -- before the installed Rails developer base surpasses the installed ASP.NET developer base. Plus, the installed ASP.NET developer base is actually willing to spend money on development tools and related products, something the installed Rails-base is only partially willing to do (e.g. TextMate). And, in the end, it's the products that find ways to generate revenue that continue to both survive and thrive. That's not to suggest Rails isn't going to survive and/or thrive. The free-as-in-speech Rails project is funded by the profit making 37 Signals and its various not-free-as-in-gasoline products in the same way the free-as-in-beer .NET/ASP.NET/etc. projects are funded by the profit making Microsoft and its various not-free-as-in-gasoline products. And when you throw the free-as-in-speech IronPython/IronRuby/DLR/ASP.NET MVC/etc. projects into the mix, it's tough to criticize MSFT's intentions and contributions to the OSS ecosystem. Of course the Mono Project -- which in and of itself provides not only the web framework support that Rails represents, but the entire language and platform that MRI represents (and then some!) -- represents a *MASSIVE* OSS community that the Rails community pales in comparison to. So it's tough to take on any type of stance that suggests that .NET/ASP.NET and related frameworks are the wrong overall direction for us developer types to be placing focus on, regardless of our preference towards OSS and proprietary platforms. That said, I most definitely agree with Charlie's thoughts regarding the overall community collaboration and contributions as it relates to the IronRuby project. But I'm less inclined to put the blame entirely on MSFT's shoulders. The door has certainly been open for the community to contribute, and several folks have taken advantage of that. And John and company have certainly proven a willingness to rapidly inject the various contributions into the source tree as soon as these same contributions seem viable enough to be injected into the source tree. I don't want to put the burden entirely on the communities shoulders, but there certainly needs to be at least some recognition to the fact that this is a completely different situation than was JRuby when it came into the good graces of Sun. JRuby was a living, breathing, viable open source implementation of the Ruby language with a living, breathing, and active OSS community backing it up long before Sun came into the picture. On the other hand, IronRuby was a resuscitated proof-of-concept project that I'm not even sure really ever saw the light of the OSS-day before being brought into the MSFT fold. So while Charlie is correct: The IronRuby project needs to become more community oriented, that community orientation needs to come from not only MSFT's direction, but the communities direction as well. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Mon Apr 28 10:52:08 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 08:52:08 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY) wrote: > He also gets a number of important technical details wrong about > IronRuby, I'll respond later today. I can point out at least one: "IronRuby really has its roots in the Ruby.NET project from Queensland University of Technology" is incorrect. The IronRuby parser/scanner was bootstrapped by the Ruby.NET parser/scanner, but has since removed all signs of the Ruby.NET parser/scanner in favor of a from-the-ground-up implementation written entirely by -- I believe -- Tomas Matousek. Of course, as Charlie points out somewhat correctly in his opening paragraph, > IronRuby was still Wilco Bauer's IronRuby, a doomed codebase and project > name eventually to be adopted by Microsoft's later Ruby implementation > effort. ... which is at least partially correct, if not a bit misleading given that for all intents and purposes the IronRuby project of today is a from-the-ground-up implementation of the Ruby language and runtime based on top of the from-the-ground-up Dynamic Language Runtime code base and architecture. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From michael.letterle at gmail.com Mon Apr 28 11:00:04 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Mon, 28 Apr 2008 11:00:04 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: Well to be fair, IronRuby /does/ have it's roots in Ruby.NET in that it was the first Microsoft supported CLR implementation. And I believe Charles is referring to the /name/ of Bauer's IronRuby being adopted by Microsoft, not the codebase. On Mon, Apr 28, 2008 at 10:52 AM, M. David Peterson wrote: > On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY) > wrote: > > > > He also gets a number of important technical details wrong about IronRuby, > I'll respond later today. > > > > I can point out at least one: "IronRuby really has its roots in the > Ruby.NET project from Queensland University of Technology" is incorrect. The > IronRuby parser/scanner was bootstrapped by the Ruby.NET parser/scanner, but > has since removed all signs of the Ruby.NET parser/scanner in favor of a > from-the-ground-up implementation written entirely by -- I believe -- Tomas > Matousek. Of course, as Charlie points out somewhat correctly in his opening > paragraph, > > > > IronRuby was still Wilco Bauer's IronRuby, a doomed codebase and project > name eventually to be adopted by Microsoft's later Ruby implementation > effort. > > > > ... which is at least partially correct, if not a bit misleading given that > for all intents and purposes the IronRuby project of today is a > from-the-ground-up implementation of the Ruby language and runtime based on > top of the from-the-ground-up Dynamic Language Runtime code base and > architecture. > > -- > /M:D > > M. David Peterson > Co-Founder & Chief Architect, 3rd&Urban, LLC > Email: m.david at 3rdandUrban.com | m.david at amp.fm > Mobile: (206) 999-0588 > http://3rdandUrban.com | http://amp.fm | > http://www.oreillynet.com/pub/au/2354 > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From charles.nutter at sun.com Mon Apr 28 11:02:56 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 28 Apr 2008 10:02:56 -0500 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> Message-ID: <4815E720.4000706@sun.com> M. David Peterson wrote: > That said, I most definitely agree with Charlie's thoughts regarding the > overall community collaboration and contributions as it relates to the > IronRuby project. But I'm less inclined to put the blame entirely on > MSFT's shoulders. The door has certainly been open for the community to > contribute, and several folks have taken advantage of that. And John > and company have certainly proven a willingness to rapidly inject the > various contributions into the source tree as soon as these same > contributions seem viable enough to be injected into the source tree. I disagree, and you need look no further than this mailing list to see the truth. Of the perhaps 40 threads I see started since Apr 3, I see only 8 that were started by folks from Microsoft...all John Lam...two of those SVN update emails. So perhaps 6 substantive threads where the initiator is someone from the IronRuby team. In order for an OSS project to work, any core team needs to be having conversations in the open. Since this is clearly not happening, it would be the first thing to change. I don't know if it's Microsoft policy or just an oversight by the IronRuby team. And obviously not tossing SVN bundles over the wall would help foster a bit more dynamic community. It's far more difficult (maybe impossible) to run an OSS project well if the community members can't update their working copies to exactly what the core team sees day-to-day. This one is most likely an MS issue. - Charlie From charles.nutter at sun.com Mon Apr 28 11:07:01 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 28 Apr 2008 10:07:01 -0500 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <4815E815.3030102@sun.com> M. David Peterson wrote: > On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY) > wrote: > >> He also gets a number of important technical details wrong about >> IronRuby, I'll respond later today. > > I can point out at least one: "IronRuby really has its roots in the > Ruby.NET project from Queensland University of Technology" is incorrect. > The IronRuby parser/scanner was bootstrapped by the Ruby.NET > parser/scanner, but has since removed all signs of the Ruby.NET > parser/scanner in favor of a from-the-ground-up implementation written > entirely by -- I believe -- Tomas Matousek. Of course, as Charlie points > out somewhat correctly in his opening paragraph, The IronRuby parser/scanner being bootstrapped by the Ruby.NET parser/scanner is certainly enough to say that's where IronRuby's roots lie. And even without that, IronRuby probably wouldn't have been attempted if Ruby.NET had shown it to be too difficult or impossible. IronRuby owes Ruby.NET for its birth, at least. >> IronRuby was still Wilco Bauer's IronRuby, a doomed codebase and >> project name eventually to be adopted by Microsoft's later Ruby >> implementation effort. > > ... which is at least partially correct, if not a bit misleading given > that for all intents and purposes the IronRuby project of today is a > from-the-ground-up implementation of the Ruby language and runtime based > on top of the from-the-ground-up Dynamic Language Runtime code base and > architecture. No, it's an entirely correct statement. At the time, IronRuby was Wilco's project, and no IronRuby work had been started at MS. I did not make any claim that the codebase was somehow reused or incorporated into the official "IronRuby", and made a point of calling it doomed because as far as I know it's never going to be touched again. Perhaps I should have said: "IronRuby" was still Wilco Bauer's IronRuby, ... - Charlie From m.david at xmlhacker.com Mon Apr 28 11:08:49 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 09:08:49 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Mon, 28 Apr 2008 09:00:04 -0600, Michael Letterle wrote: > Well to be fair, IronRuby /does/ have it's roots in Ruby.NET in that > it was the first Microsoft supported CLR implementation. Fair enough. > And I > believe Charles is referring to the /name/ of Bauer's IronRuby being > adopted by Microsoft, not the codebase. That would make sense. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Mon Apr 28 11:27:53 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 09:27:53 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <4815E720.4000706@sun.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> Message-ID: On Mon, 28 Apr 2008 09:02:56 -0600, Charles Oliver Nutter wrote: > I disagree, and you need look no further than this mailing list to see > the truth. Of the perhaps 40 threads I see started since Apr 3, I see > only 8 that were started by folks from Microsoft...all John Lam...two of > those SVN update emails. So perhaps 6 substantive threads where the > initiator is someone from the IronRuby team. Oh, I don't disagree with this, just that I don't see any physical obstacles keeping the community from becoming more involved. Mental obstacles, for sure... And maybe that's really where the focus needs to be: Finding ways to remove the mental obstacles that keep people from contributing more aggressively. I know how you guys have done it and are continuing to do it. But putting yourself in IronRuby's Red Slippers for a moment, how would you do it if you were starting from scratch (or as close to scratch as you can get w/o literally starting from scratch) and had to find ways to first, sell the overall idea to the community to then get that same community to actively participate in the process while at the same time making attempt to convince that the once proprietary-only giant really is committed to building OSS into their overall software ecosystem? > In order for an OSS project to work, any core team needs to be having > conversations in the open. Since this is clearly not happening, it would > be the first thing to change. I don't know if it's Microsoft policy or > just an oversight by the IronRuby team. I can't say I really know the answer, but I do agree with your point. From my own perspective I would suggest it's a combination of the internal culture at MSFT attempting to change how they go about the business of courting the developer coupled with the size of the internal IronRuby team that still have to meet deadlines and expectations that are unrelated to IronRuby (e.g. integration with the DLR team, MIX and other high profile events, typical corporate culture stuff such as performance reviews, etc.) That's not an attempt to provide an excuse as to why they can't be more open. Just an attempt at understanding there are more forces involved than are immediately obvious from the outside looking in. > And obviously not tossing SVN bundles over the wall would help foster a > bit more dynamic community. Absolutely 100% agree. One of things I was curious to see when John first announced that IronRuby would be hosted on RubyForge was whether or not he could actually pull it off. From what I assume is both of our perspectives, thus far it hasn't worked out as well as it both could and should have. > It's far more difficult (maybe impossible) to run an OSS project well if > the community members can't update their working copies to exactly what > the core team sees day-to-day. This one is most likely an MS issue. It's absolutely 100% an internal MSFT issue. Can it be fixed? -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From jflam at microsoft.com Mon Apr 28 11:35:24 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Mon, 28 Apr 2008 08:35:24 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> M. David Peterson: > > It's far more difficult (maybe impossible) to run an OSS project well > > if the community members can't update their working copies to exactly > > what the core team sees day-to-day. This one is most likely an MS > issue. > > It's absolutely 100% an internal MSFT issue. Can it be fixed? While meta-level discussions are interesting, they generally don't offer much in the way of concrete guidance. So let me ask this question to the larger community: Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? Thanks, -John From m.david at xmlhacker.com Mon Apr 28 11:41:47 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 09:41:47 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> Message-ID: On Mon, 28 Apr 2008 09:27:53 -0600, M. David Peterson wrote: > But putting yourself in IronRuby's Red Slippers for a moment, To put this another way, JRuby was a successful OSS project *FIRST* which -- because of this fact -- attracted Sun to bring the project and its two core contributors (at that time -- if not mistaken, didn't Ola really begin his core involvement after the acquisition?) in house. The community didn't have to be convinced of the overall JRuby idea. That had already happened long before Corporate America began it's lust -> love fest with the project, gaining not only the already successful OSS JRuby project, but access to the best and the brightest minds/talent the Java development community had to offer as a result. MSFT, on the other, went out and found the best and brightest minds/talent the .NET development community had to offer -- at least as far as experience with the Ruby language was concerned -- and then tasked them with building not only an OSS Ruby implementation for the .NET platform, but in building an OSS community as well > Both -- for all intents and purposes -- from scratch. Two different situations. Two different scenarios. You've done it successfully from the outside in. How would you do it -- again successfully -- from the inside out? -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From jgbailey at gmail.com Mon Apr 28 11:43:29 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Mon, 28 Apr 2008 08:43:29 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Mon, Apr 28, 2008 at 8:35 AM, John Lam (IRONRUBY) wrote: > Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? I have a large block of code that is based on the long-ago RubyCLR bridge John implemented. I am very excited to get that onto native .NET. My impression is that IronRuby is not far enough along to support much of my codebase, but it's a moot point. I cannot access RubyForge's SVN repository from behind my employer's ISA firewall (it blocks certain HTTP headers SVN uses). I did manage to spider the latest release at one point using WGET but it wasn't an effort I'd repeat regularly. Another method for getting the codebase would make it easier for me to see what IronRuby is capable of so far. Justin From m.david at xmlhacker.com Mon Apr 28 11:43:58 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 09:43:58 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Mon, 28 Apr 2008 09:35:24 -0600, John Lam (IRONRUBY) wrote: > Has working on the SVN sources (with the attendant delays in propagating > to / from our version of 'the truth') blocked you from working on a > contribution? No. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From acangiano at gmail.com Mon Apr 28 11:44:50 2008 From: acangiano at gmail.com (Antonio Cangiano) Date: Mon, 28 Apr 2008 11:44:50 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <4815E720.4000706@sun.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> Message-ID: <4815F0F2.8090604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles Oliver Nutter wrote: > I disagree, and you need look no further than this mailing list to see > the truth. Of the perhaps 40 threads I see started since Apr 3, I see > only 8 that were started by folks from Microsoft...all John Lam...two of > those SVN update emails. So perhaps 6 substantive threads where the > initiator is someone from the IronRuby team. > > In order for an OSS project to work, any core team needs to be having > conversations in the open. Since this is clearly not happening, it would > be the first thing to change. I don't know if it's Microsoft policy or > just an oversight by the IronRuby team. > > And obviously not tossing SVN bundles over the wall would help foster a > bit more dynamic community. It's far more difficult (maybe impossible) > to run an OSS project well if the community members can't update their > working copies to exactly what the core team sees day-to-day. This one > is most likely an MS issue. I don't usually like to criticize open source projects but I must say that I wholeheartedly agree with you on this point. The development process behind JRuby and Rubinius is very open, while IronRuby's one is not nearly enough so. The end result is that JRuby and Rubinius appear to be improving really fast, while IronRuby seems to proceed at a glacial pace. Behind the scenes, this may not be the case, but by looking at the repository this is the impression that one gets. According to ohloh, IronRuby has 2 contributors who made commits, JRuby has 22 and Rubinius 152. JRuby and Rubinius get several commits on a daily basis, while IronRuby's commits are rare and 1 year after its announcement there still hasn't been a single release, the trunk is at version 96 and x = 2 in interactive mode is still broken. While granted IronRuby may appeal to less people than Rubinius or JRuby, I still feel that the development process could benefit a lot from incremental/daily commits, more transparency and a greater deal of control handed to the community. As Charlie mentioned somewhere else, JRuby is not Sun's, it belongs to the community. That statement is entirely backed up by facts, but I'm afraid that, at this stage, it isn' possible to claim the same for IronRuby. This, coupled with the fact that ASP.NET and languages like C# are clearly Microsoft's main interest, lead me to believe that IronRuby is not living up to its full potential. Microsoft has the resources and brilliant minds (e.g. John Lam) to seriously reconsider its approach to this project, in order to really let it take off. Just my 2 cents, Antonio - -- http://antoniocangiano.com - Zen and the Art of Programming http://stacktrace.it - Aperiodico di resistenza informatica http://math-blog.com - Math Blog: Mathematics is wonderful! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgV8PIACgkQqCqsu0qUj9SOrgCgww8tFRi03AQG0nnj6iE2MCuo KboAn0hzVO97RQgJIALx07e1j4px1iOl =Y1aM -----END PGP SIGNATURE----- From charles.nutter at sun.com Mon Apr 28 11:45:46 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 28 Apr 2008 10:45:46 -0500 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <4815F12A.8080906@sun.com> John Lam (IRONRUBY) wrote: > M. David Peterson: > >>> It's far more difficult (maybe impossible) to run an OSS project well >>> if the community members can't update their working copies to exactly >>> what the core team sees day-to-day. This one is most likely an MS >> issue. >> >> It's absolutely 100% an internal MSFT issue. Can it be fixed? > > While meta-level discussions are interesting, they generally don't offer much in the way of concrete guidance. So let me ask this question to the larger community: > > Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? And answer carefully, friends, because you could help correct this policy. Don't give an answer you think John wants to hear, because a little community pressure could go a long way toward improving the situation. I'm sure John would agree with me there... - Charlie From m.david at xmlhacker.com Mon Apr 28 11:49:58 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 09:49:58 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Mon, 28 Apr 2008 09:43:29 -0600, Justin Bailey wrote: > Another method for getting the codebase would make > it easier for me to see what IronRuby is capable of so far. Like? Is there another SCC/wire protocol that would work? If yes, there are plenty of bridges out there that are 1-to-1 compatible (meaning they retain 100% of the meta-data and related versioning/check-in info) with SVN both forwards and backwards. Tailor comes to mind. I know there are others. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From bacondarwin at googlemail.com Mon Apr 28 11:55:43 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Mon, 28 Apr 2008 16:55:43 +0100 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <000901c8a948$518e7850$f4ab68f0$@com> I have not personally been affected by the long time periods between the code drops. I doubt it has had a serious impact on many other contributors. Although there have certainly been a few issues highlighted in the mailing list around the hosting API and some other internal chunks of code that have delayed people trying to work on top of IR - the SaphireSteel guys come to mind, I still believe this has not really been a problem, since even in a totally open environment, people would need to wait on the core team to deliver API's anyway, no? I think the main problem with the current wall-tossing arrangement is that it creates a feeling of, "this is a their (Microsoft) project" rather than "this is our (community) project". Contributors feel no ownership of the code they contribute, let alone the project as a whole. What gets people excited, and encouraged to contribute, to a project is the feeling that they own some part of it or have some responsibility in the direction and decision making. Bug fixing patches and fleshing out code stubs is very important but not too exciting for many developers. It would have been an interesting exercise to break off self-standing components of the Iron Ruby libraries and set them up as independent OSS projects of their own that are primarily stored in SVN and imported into MS Team repositories on occasion rather than the other way around. Obvious candidates are the YAML processor, the Regex engine, and any other components that require substantial C# code to be written, and design decisions to be made. It is not too late to implement something like this. If a bit of work could be done on loading external IR libraries then projects could begin to be setup independently. This would have the multiple benefit of getting people to work on interesting and challenging projects, potentially creating alternative options to the IR community but also those people working on the projects are more likely to pickup bugs and add in the smaller patches to the core that are not getting people excited at the moment. My two pennies. Pete -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Monday,28 April 28, 2008 16:35 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog M. David Peterson: > > It's far more difficult (maybe impossible) to run an OSS project well > > if the community members can't update their working copies to exactly > > what the core team sees day-to-day. This one is most likely an MS > issue. > > It's absolutely 100% an internal MSFT issue. Can it be fixed? While meta-level discussions are interesting, they generally don't offer much in the way of concrete guidance. So let me ask this question to the larger community: Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? Thanks, -John _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From lists at ruby-forum.com Mon Apr 28 11:56:39 2008 From: lists at ruby-forum.com (Softmind Technology) Date: Mon, 28 Apr 2008 17:56:39 +0200 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: Hi, All I can say is... The Progress is slow. Refer to this thread in this forum only. One of the community member shouts, since there is no beta around even after one year. Here's the link.. http://www.ruby-forum.com/topic/144090#new All I can say clearly is...There is Lots of Delay in the progress. Thanks -- Posted via http://www.ruby-forum.com/. From m.david at xmlhacker.com Mon Apr 28 11:57:40 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 09:57:40 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <4815F12A.8080906@sun.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <4815F12A.8080906@sun.com> Message-ID: On Mon, 28 Apr 2008 09:45:46 -0600, Charles Oliver Nutter wrote: > And answer carefully, friends, because you could help correct this > policy. I answered honestly. No, it's not getting in the way. But that doesn't mean I believe that process isn't broken. It is without a doubt. I'm just not 100% sure -- taking in all considerations to the challenge at hand -- how to "fix" it from a truly ideal OSS community perspective. > Don't give an answer you think John wants to hear, because a little > community pressure could go a long way toward improving the situation. > I'm sure John would agree with me there... I dom't know if he will agree or not, but whether he does or doesn't, the fact of the matter is that there are two options, - Do nothing and wait for something to happen on its own. - Do something and see what happens as a result. I'm 100% the notion of applying pressure. Where's the best place to start? -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Mon Apr 28 12:03:37 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 10:03:37 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <4815F0F2.8090604@gmail.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <4815F0F2.8090604@gmail.com> Message-ID: On Mon, 28 Apr 2008 09:44:50 -0600, Antonio Cangiano wrote: > As Charlie mentioned somewhere else, JRuby is not Sun's, it belongs to > the community. That statement is entirely backed up by facts, but I'm > afraid that, at this stage, it isn' possible to claim the same for > IronRuby. This, coupled with the fact that ASP.NET and languages like C# > are clearly Microsoft's main interest, lead me to believe that IronRuby > is not living up to its full potential. Nicely stated! Of course, as per my previous argument, I do believe consideration needs to be made as to the difference between the outside > in approach that JRuby represents and the inside > out approach represented by IronRuby. None-the-less, there needs to be some faith building exercises coming from the direction of MSFT that help bring a better sense of community ownership to the project, that's without a doubt! > Microsoft has the resources and brilliant minds (e.g. John Lam) to > seriously reconsider its approach to this project, in order to really > let it take off. Absolutely! -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From sanxiyn at gmail.com Mon Apr 28 12:03:49 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 29 Apr 2008 01:03:49 +0900 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <5b0248170804280903t1b225f4dk195cfc6bccad5e7@mail.gmail.com> 2008/4/29 John Lam (IRONRUBY) : > Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? Blocked? No. Discouraged? Hell sure. (The same applies to IronPython, but IronPython is much more stable than IronRuby, so it changes less frequently, which makes keeping up to date easier.) -- Seo Sanghyeon From charles.nutter at sun.com Mon Apr 28 12:05:43 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 28 Apr 2008 11:05:43 -0500 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <000901c8a948$518e7850$f4ab68f0$@com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> Message-ID: <4815F5D7.6010008@sun.com> Peter Bacon Darwin wrote: > I have not personally been affected by the long time periods between the > code drops. I doubt it has had a serious impact on many other contributors. > Although there have certainly been a few issues highlighted in the mailing > list around the hosting API and some other internal chunks of code that have > delayed people trying to work on top of IR - the SaphireSteel guys come to > mind, I still believe this has not really been a problem, since even in a > totally open environment, people would need to wait on the core team to > deliver API's anyway, no? In general the problem I see most often goes like this: 1. Contributor tries to run IronRuby from RubyForge trunk. 2. Contributor finds a bug. 3. Contributor emails the list, asking if this bug has been fixed, and often volunteering to fix it. 4. IronRuby Team Member replies, saying the bug is fixed and will be in the next drop. 5. Contributor waits, maybe moving on to other IronRuby work or maybe walking away from the project until the next drop. And this seems to happen again and again. Not only does it slow the process of fixing bugs, it makes it impossible for people to want to help fix them. If you can never know you're running against the latest sources, the process of finding a bug, emailing to see if it's fixed already, and probably waiting for that fix to arrive is extremely discouraging. - Charlie From m.david at xmlhacker.com Mon Apr 28 12:07:51 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 10:07:51 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <5b0248170804280903t1b225f4dk195cfc6bccad5e7@mail.gmail.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <5b0248170804280903t1b225f4dk195cfc6bccad5e7@mail.gmail.com> Message-ID: On Mon, 28 Apr 2008 10:03:49 -0600, Sanghyeon Seo wrote: > Blocked? No. Discouraged? Hell sure. I can't think of a better way to accurately portray the reality of the situation. Nicely stated, Seo! -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From michael.letterle at gmail.com Mon Apr 28 12:24:20 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Mon, 28 Apr 2008 12:24:20 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: In a technical fashion? No. From an emotional standpoint? Yes. Right now IronRuby is very unstable from the view of an outside contributor, you don't know if the code you're working on now is going to need /major/ changes in the next drop, and you don't know when that's going to be. Why work on a bug that "in truth" may already be fixed? The most important change that MSFT can do is let you push to rubyforge DIRECTLY, none of this internal updates pushed to rubyforge once in a while. I assume it's corporate preventing this, because it really make no sense otherwise. What we have here isn't an OSS community project in the traditional sense, what we have is a Microsoft project that they've so kindly, in their infinite wisdom allow us commoners to work on now and then. Oh but you can't see or touch the real code until we're ready to let you. This is HIGHLY discouraging. Don't get me wrong, I applaud Microsoft for going this far, it's a major step, but only a step, there's still a long way to go. On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) wrote: > Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? > > Thanks, > -John > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From m.david at xmlhacker.com Mon Apr 28 12:28:29 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 10:28:29 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <4815F5D7.6010008@sun.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <4815F5D7.6010008@sun.com> Message-ID: On Mon, 28 Apr 2008 10:05:43 -0600, Charles Oliver Nutter wrote: > And this seems to happen again and again. Not only does it slow the > process of fixing bugs, it makes it impossible for people to want to > help fix them. If you can never know you're running against the latest > sources, the process of finding a bug, emailing to see if it's fixed > already, and probably waiting for that fix to arrive is extremely > discouraging. I agree. If I am remembering correctly, one of the primary reasons behind the dual-repository approach is the need to run a myriad of internal tests from a test suite that reaches farther and deeper than just IronRuby, and therefore can not see the light of day outside the MSFT firewall. John, is this an accurate assessment? If yes, while I certainly recognize the need to run the code against internal test suites, couldn't it be looked at from the opposite perspective?That of: We, the community, tell you, the big bad corporate firewall, when you get to gain access to *our* code to run your tests. We will continue on our way checking it whatever we want whenever we want, and you can use repository revisions as a marker to determine what can be viewed as "blessed" and what can not as far as releases are concerned. If it really is an issue with intellectual property et. al, you can keep those results locked up in a bit locker that guarantees they'll never experience life outside their darkened dungeon. We, the community, are not interested in the results of internal tests, and we certainly would understand that, regardless of the results of our external tests, there are certain check boxes that need to be checked by powers unknown to us before an officially blessed release can be made. All we care about is passing the spec, something which is, quite obviously, controlled outside the grasp of Redmond's barbed [fire]wire-trimmed walls. If it takes a few extra weeks to take a particular revision of the repository through the internal ringer before getting the official rubber stamp, then so be it. It wouldn't be getting in the way of development progress, and if not mistaken, this is really the core of the argument as to why the process is currently broken. Food for thought... -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From Tomas.Matousek at microsoft.com Mon Apr 28 12:42:01 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Mon, 28 Apr 2008 09:42:01 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: "but since removed all signs of the Ruby.NET parser/scanner in favor of a from-the-ground-up implementation written entirely by -- I believe -- Tomas Matousek" More precisely, I've heavily refactored the tokenizer (and it's still not finished) and rewrote semantic actions in the grammar to create IronRuby AST - which I wrote from scratch. The grammar rules themselves are more or less as they was in Ruby.NET. With some renames and minor changes. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of M. David Peterson Sent: Monday, April 28, 2008 7:52 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY) wrote: > He also gets a number of important technical details wrong about > IronRuby, I'll respond later today. I can point out at least one: "IronRuby really has its roots in the Ruby.NET project from Queensland University of Technology" is incorrect. The IronRuby parser/scanner was bootstrapped by the Ruby.NET parser/scanner, but has since removed all signs of the Ruby.NET parser/scanner in favor of a from-the-ground-up implementation written entirely by -- I believe -- Tomas Matousek. Of course, as Charlie points out somewhat correctly in his opening paragraph, > IronRuby was still Wilco Bauer's IronRuby, a doomed codebase and project > name eventually to be adopted by Microsoft's later Ruby implementation > effort. ... which is at least partially correct, if not a bit misleading given that for all intents and purposes the IronRuby project of today is a from-the-ground-up implementation of the Ruby language and runtime based on top of the from-the-ground-up Dynamic Language Runtime code base and architecture. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From m.david at xmlhacker.com Mon Apr 28 12:54:19 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 10:54:19 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Mon, 28 Apr 2008 10:42:01 -0600, Tomas Matousek wrote: > More precisely, I've heavily refactored the tokenizer (and it's still > not finished) and rewrote semantic actions in the grammar to create > IronRuby AST - which I wrote from scratch. The grammar rules themselves > are more or less as they was in Ruby.NET. With some renames and minor > changes. Thanks for the clarification, Tomas! -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From steve.eichert at gmail.com Mon Apr 28 13:04:06 2008 From: steve.eichert at gmail.com (Steve Eichert) Date: Mon, 28 Apr 2008 13:04:06 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: I can't say that the delay has stopped me from working on a contribution since I've just recently started investigating where I may be able to lend a hand. However, I can say that I'm much more reluctant to jump in and start working on something since I don't want to work on a implementing or fixing something that has already been addressed. I think it would be great to have a more open environment where the community knows what the members of the IronRuby team are working on and what they're currently thinking about, as well as what things they aren't able to get to yet but are higher priority. This would help the community understand what they should stay away from, as well as what would be a good place to contribute. In order to foster a community around IronRuby I believe there needs to be something that can rally the community around a cause. Right now, most of the people I've spoken to are in a wait and see mode with IronRuby. It would be great if we could do something to get people in a "what can I do to contribute value to the project" mode. This is coming from someone who has just recently "joined" the IronRuby community, so I may not be looking in the right places. Cheers, Steve On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) wrote: > M. David Peterson: > > > > It's far more difficult (maybe impossible) to run an OSS project well > > > if the community members can't update their working copies to exactly > > > what the core team sees day-to-day. This one is most likely an MS > > issue. > > > > It's absolutely 100% an internal MSFT issue. Can it be fixed? > > While meta-level discussions are interesting, they generally don't offer > much in the way of concrete guidance. So let me ask this question to the > larger community: > > Has working on the SVN sources (with the attendant delays in propagating > to / from our version of 'the truth') blocked you from working on a > contribution? > > Thanks, > -John > _______________________________________________ > 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 bacondarwin at googlemail.com Mon Apr 28 13:36:58 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Mon, 28 Apr 2008 18:36:58 +0100 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <001301c8a956$77273940$6575abc0$@com> I believe one of the key problems is the DLR. As I understand, it MS makes a distinction between "important" stuff (i.e. the DLR) and "peripheral" stuff (i.e. IronXxxx). MS wants to have complete control over the DLR and is not interested in making it Open Source. Rather the DLR code is just community viewable, much like the rest of the .NET framework code. I can understand this since core .NET Framework code is central to the MS strategy and they don't want things sneaking in the sides. IronRuby, IronPython and so on are not so important to MS strategy and they are more happy to let the community muck about with the code. I believe that the long term goal is to open up the IronXxxx code much more to the community but the problem is that the line between the DLR and the IronXxxx languages is not yet nailed down. Therefore until that happens MS is unlikely to hand over the project to the community. I would be interested to know how often an SVN dump is created compared to successful check-ins going through the SNAP process. Ideally, every successful SNAP check-in should get automatically dumped out on the RubyForge SVN repos, whether it added value or broke the tests or whatever. You can always have SVN tags on the "good" builds and also create downloadable "good" releases on the RubyForge site - this point would probably help Justin Bailey's access problems too. Another scenario, which /M:D alludes to if I understand correctly, is to allow the community to modify the code in the RubyForge project and then let MS select "good" builds to check back into the Team system via the SNAP process. That way, the community feels ownership of the project and MS get that quality control on what finally goes into IronRuby. There are obviously many technical hurdles to overcome before this could become reality. In particular, there needs to be a separation of DLR from IronXxxx, including, probably, some kind of stable release of the DLR for the IronXxxx projects to work off. Any other ideas? John what are you thinking here? Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdeville at microsoft.com Mon Apr 28 14:41:02 2008 From: jdeville at microsoft.com (Jim Deville) Date: Mon, 28 Apr 2008 11:41:02 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog Message-ID: So, as the new guy on the other (MSFT) side of the fence, I am interested in all of these suggestions and ideas. In addition, I have some questions/suggestions for you. * Would mirroring our internal repo on a commit-by-commit basis help with the repository issues? Would it help with the ownership feelings? * How can we be more transparent about what we are working on, and where we are heading? A blog? A weekly posting? * Would mirroring the repo to other formats help? Would releasing alpha binaries be worthwhile? I'm new, but I want to help build a community, and show that this is a real OSS project. So, I really appreciate the discource. I think that these meta discussions are worthwhile in helping define the community. Jim Deville -----Original Message----- From: "Steve Eichert" To: "ironruby-core at rubyforge.org" Sent: 4/28/08 10:05 AM Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog I can't say that the delay has stopped me from working on a contribution since I've just recently started investigating where I may be able to lend a hand. However, I can say that I'm much more reluctant to jump in and start working on something since I don't want to work on a implementing or fixing something that has already been addressed. I think it would be great to have a more open environment where the community knows what the members of the IronRuby team are working on and what they're currently thinking about, as well as what things they aren't able to get to yet but are higher priority. This would help the community understand what they should stay away from, as well as what would be a good place to contribute. In order to foster a community around IronRuby I believe there needs to be something that can rally the community around a cause. Right now, most of the people I've spoken to are in a wait and see mode with IronRuby. It would be great if we could do something to get people in a "what can I do to contribute value to the project" mode. This is coming from someone who has just recently "joined" the IronRuby community, so I may not be looking in the right places. Cheers, Steve On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) > wrote: M. David Peterson: > > It's far more difficult (maybe impossible) to run an OSS project well > > if the community members can't update their working copies to exactly > > what the core team sees day-to-day. This one is most likely an MS > issue. > > It's absolutely 100% an internal MSFT issue. Can it be fixed? While meta-level discussions are interesting, they generally don't offer much in the way of concrete guidance. So let me ask this question to the larger community: Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? Thanks, -John _______________________________________________ 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 michael.letterle at gmail.com Mon Apr 28 14:53:55 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Mon, 28 Apr 2008 14:53:55 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: Message-ID: Yes, Yes, Yes. Do it! Specifically, mirroring the repo would help. Using rubyforge has the main repo would be better. A blog would be fantastic, though most of the "core" team already have blogs.. still an official IronRuby blog will regular updates would be awesome. Alpha binaries always encourage people to at least download and try it out. Some projects use this crazy thing called daily builds... On Mon, Apr 28, 2008 at 2:41 PM, Jim Deville wrote: > > So, as the new guy on the other (MSFT) side of the fence, I am interested > in all of these suggestions and ideas. In addition, I have some > questions/suggestions for you. > > * Would mirroring our internal repo on a commit-by-commit basis help with > the repository issues? Would it help with the ownership feelings? > * How can we be more transparent about what we are working on, and where we > are heading? A blog? A weekly posting? > * Would mirroring the repo to other formats help? Would releasing alpha > binaries be worthwhile? > > I'm new, but I want to help build a community, and show that this is a real > OSS project. So, I really appreciate the discource. I think that these meta > discussions are worthwhile in helping define the community. > > Jim Deville > > -----Original Message----- > From: "Steve Eichert" > To: "ironruby-core at rubyforge.org" > Sent: 4/28/08 10:05 AM > Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from > this blog > > > > > I can't say that the delay has stopped me from working on a contribution > since I've just recently started investigating where I may be able to lend a > hand. However, I can say that I'm much more reluctant to jump in and start > working on something since I don't want to work on a implementing or fixing > something that has already been addressed. > > I think it would be great to have a more open environment where the > community knows what the members of the IronRuby team are working on and > what they're currently thinking about, as well as what things they aren't > able to get to yet but are higher priority. This would help the community > understand what they should stay away from, as well as what would be a good > place to contribute. In order to foster a community around IronRuby I > believe there needs to be something that can rally the community around a > cause. Right now, most of the people I've spoken to are in a wait and see > mode with IronRuby. It would be great if we could do something to get > people in a "what can I do to contribute value to the project" mode. > > This is coming from someone who has just recently "joined" the IronRuby > community, so I may not be looking in the right places. > > Cheers, > Steve > > > On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) > wrote: > > > M. David Peterson: > > > > > > > > It's far more difficult (maybe impossible) to run an OSS project well > > > > if the community members can't update their working copies to exactly > > > > what the core team sees day-to-day. This one is most likely an MS > > > issue. > > > > > > It's absolutely 100% an internal MSFT issue. Can it be fixed? > > > > While meta-level discussions are interesting, they generally don't offer > much in the way of concrete guidance. So let me ask this question to the > larger community: > > > > Has working on the SVN sources (with the attendant delays in propagating > to / from our version of 'the truth') blocked you from working on a > contribution? > > > > Thanks, > > -John > > > > > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From m.david at xmlhacker.com Mon Apr 28 15:46:28 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 13:46:28 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: Message-ID: On Mon, 28 Apr 2008 12:41:02 -0600, Jim Deville wrote: > So, as the new guy on the other (MSFT) side of the fence, Welcome, Jim! :D > I am interested in all of these suggestions and ideas. Great! > In addition, I have some questions/suggestions for you. > > * Would mirroring our internal repo on a commit-by-commit basis help > with the repository issues? Depends on which issues you are referring to, though I can't imagine it would hurt any of the issues, and will certainly help with many, if not all of them. > Would it help with the ownership feelings? Yes, especially if the external repository was seen as the master repository with daily, hourly, or per-commit syncs with the internal MSFT repository, not vice-versa. > * How can we be more transparent about what we are working on, and where > we are heading? A blog? A weekly posting? This is always going to be somewhat of a gray area due to the fact that there will always be things (e.g. new features un-related to the Ruby language, related products such as development tools, DLR-specific extensions, Silverlight, etc.) that the powers that be @ MSFT will not want exposed to the outside community and/or given to the community to control. These are both fair and understood concerns, but I believe easy enough to work around. In this regard, if a line in the sand could be drawn that stated something like, * The community owns the Ruby implementation as it relates to the external specs and existing Ruby applications. * MSFT owns the rest. And the community was then given control -- with John and associates leading the way, of course -- of pushing forward the portion of the repository they were in control of, I believe we would all be in the exact position we've been jockeying for, that of controlling each of our destinies and primary areas of drive and interest. > * Would mirroring the repo to other formats help? Would releasing alpha > binaries be worthwhile? I think a per-check-in build process monitored and implemented by something similar to CruiseControl.NET would be ideal. This would ensure that the state of the repository at any given time was well understoood, providing access to the resulting binaries with each new build for further analysis and testing by anyone who felts so inclined to access the binaries and begin running tests against them. In this regard, it would be *great* to implement and Atom-based subscription service for keeping a local cache of binaries up-to-date with the repository head. In fact, I'll write that service if enough interest exists in having access to just such a service. > I'm new, but I want to help build a community, and show that this is a > real OSS project. So, I really appreciate the discource. I think that > these meta discussions are worthwhile in helping define the community. Agreed. Looking forward to see what you are able to make of all this! And thanks! -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Mon Apr 28 15:57:21 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 13:57:21 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: Message-ID: On Mon, 28 Apr 2008 12:53:55 -0600, Michael Letterle wrote: > still an official IronRuby blog will regular updates would be > awesome. Not sure what legal barriers, if any, might stand in the way of using the existing ironruby.net domain to host a community-driven blog, but if they do exist yet could somehow be overcome, that would be ideal. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From jdlewis at xactware.com Mon Apr 28 15:16:53 2008 From: jdlewis at xactware.com (Jeff Lewis) Date: Mon, 28 Apr 2008 13:16:53 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it soundsfrom this blog In-Reply-To: References: Message-ID: <10149100A9B32A45A934362B602ABE5B0273A012@POSTMASTER.xactware.com> +1 for commit by commit mirror or using (even better) using rubyforge as primary and mirroring it back to TFS. +1 for daily builds (preferably automated so that no one has to spend much time on it) I honestly think that until it is primarily hosted at rubyforge, people will complain that the project isn't "open enough." That definitely won't quiet down everyone, but it would make great strides towards it. But, it may simply be too early to do so since the DLR is still evolving. From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville Sent: Monday, April 28, 2008 12:41 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Regarding IronRuby... How true it soundsfrom this blog So, as the new guy on the other (MSFT) side of the fence, I am interested in all of these suggestions and ideas. In addition, I have some questions/suggestions for you. * Would mirroring our internal repo on a commit-by-commit basis help with the repository issues? Would it help with the ownership feelings? * How can we be more transparent about what we are working on, and where we are heading? A blog? A weekly posting? * Would mirroring the repo to other formats help? Would releasing alpha binaries be worthwhile? I'm new, but I want to help build a community, and show that this is a real OSS project. So, I really appreciate the discource. I think that these meta discussions are worthwhile in helping define the community. Jim Deville -----Original Message----- From: "Steve Eichert" To: "ironruby-core at rubyforge.org" Sent: 4/28/08 10:05 AM Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog I can't say that the delay has stopped me from working on a contribution since I've just recently started investigating where I may be able to lend a hand. However, I can say that I'm much more reluctant to jump in and start working on something since I don't want to work on a implementing or fixing something that has already been addressed. I think it would be great to have a more open environment where the community knows what the members of the IronRuby team are working on and what they're currently thinking about, as well as what things they aren't able to get to yet but are higher priority. This would help the community understand what they should stay away from, as well as what would be a good place to contribute. In order to foster a community around IronRuby I believe there needs to be something that can rally the community around a cause. Right now, most of the people I've spoken to are in a wait and see mode with IronRuby. It would be great if we could do something to get people in a "what can I do to contribute value to the project" mode. This is coming from someone who has just recently "joined" the IronRuby community, so I may not be looking in the right places. Cheers, Steve On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) wrote: M. David Peterson: > > It's far more difficult (maybe impossible) to run an OSS project well > > if the community members can't update their working copies to exactly > > what the core team sees day-to-day. This one is most likely an MS > issue. > > It's absolutely 100% an internal MSFT issue. Can it be fixed? While meta-level discussions are interesting, they generally don't offer much in the way of concrete guidance. So let me ask this question to the larger community: Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? Thanks, -John _______________________________________________ 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 ryan.riley at panesofglass.org Mon Apr 28 16:44:26 2008 From: ryan.riley at panesofglass.org (Ryan Riley) Date: Mon, 28 Apr 2008 15:44:26 -0500 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog Message-ID: Jeff Lewis wrote: > > +1 for commit by commit mirror or using (even better) using rubyforge as > primary and mirroring it back to TFS. > > +1 for daily builds (preferably automated so that no one has to spend > much time on it) +1 I complete agree with David and Jeff. -- Ryan Riley ryan.riley at panesofglass.org http://www.panesofglass.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.eichert at gmail.com Mon Apr 28 17:15:11 2008 From: steve.eichert at gmail.com (Steve Eichert) Date: Mon, 28 Apr 2008 17:15:11 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: Message-ID: > * Would mirroring our internal repo on a commit-by-commit basis help with the repository issues? Would it help with the ownership feelings? > > I think it would help for sure. > * How can we be more transparent about what we are working on, and where we are heading? A blog? A weekly posting? > > I'm not as concerned with the medium of the information (blog, this mailing list, wiki) as long as the community has access to the information. A daily or weekly or as often as possible scrum like status update that the community would be able to see would be cool. What did you work on since the last update What will you be working on until the next scheduled update What's getting in the way of progress This would provide the benefit of letting people have a glimpse of where the team is focusing their attention, as well as potential areas that they could lend a hand. As an example, if Tomas says he's working on X, but the fact that Y isn't done yet is making it a little more difficult, and he also makes it clear that Y isn't something he or anyone else is going to be able to get to in the near future Y could be something the community tries to lend a hand with. I could see someone like Wayne doing a similar status since at least from the sounds of it he's trying to spearhead some of the work on ruby gems + rails. > * Would mirroring the repo to other formats help? Would releasing alpha binaries be worthwhile? > > Conceptually a git like repo seems like it would offer some interesting advantages. I'm a git newbie, but from what I've heard and read it really encourages people to fork projects and play around with different ideas. Currently, I can't see what anyone else in the community is working on, let alone the IronRuby team itself. I think in order to foster a real community around IronRuby we need to not only make the ironRuby team itself more transparent, but increase the transparency of the community as a whole. Perhaps IronRuby should jump on the github bandwagon? :) > I'm new, but I want to help build a community, and show that this is a real OSS project. So, I really appreciate the discource. I think that these meta discussions are worthwhile in helping define the community. > > I'm new (on the opposite side) and feel the same way. Cheers, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From mental at rydia.net Mon Apr 28 17:24:19 2008 From: mental at rydia.net (MenTaLguY) Date: Mon, 28 Apr 2008 14:24:19 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds fromthis blog In-Reply-To: References: Message-ID: <62fb20bf628e6577e76f05d9c3f2b61b@localhost> On Mon, 28 Apr 2008 15:44:26 -0500, "Ryan Riley" wrote: >> +1 for commit by commit mirror or using (even better) using rubyforge as >> primary and mirroring it back to TFS. >> >> +1 for daily builds (preferably automated so that no one has to spend >> much time on it) I also strongly agree on both points. -mental From Tomas.Matousek at microsoft.com Mon Apr 28 18:58:25 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Mon, 28 Apr 2008 15:58:25 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: So, one of the "details" that are wrong is that we don't support multiple isolated engines in a single process. It's actually quite simple to do so via DLR Hosting API. The main concept here is ScriptRuntime. This class represents the world for a dynamic language. The class holds on loaded assemblies, .NET namespace references, etc. Each language could also associate its own global state with the runtime. IronRuby has all Ruby global state there: global variables table, class hierarchy etc. So, unless you use CLR interop, there is no way how the script could get outside this sandbox. If you want to isolate the runtimes even more (for CLR interop) you can always create a ScriptRuntime inside a separate app-domain. Let's show some example (a self-contained C# source code of a simple IronRuby host follows): using System.IO; using Microsoft.Scripting.Hosting; class RubyHostingExample { public static void Main() { const string write = @"C:\Temp\write.rb"; const string read = @"C:\Temp\read.rb"; File.WriteAllText(write, @" $x = 'Hello from runtime #1!' C = 'some constant' module Kernel def say_bye puts 'bye' end end "); File.WriteAllText(read, @" puts $x if defined? C puts C else puts 'C not defined' end say_bye rescue puts $! puts "); ScriptRuntime runtime1 = ScriptRuntime.Create(); ScriptRuntime runtime2 = ScriptRuntime.Create(); runtime1.ExecuteFile(write); runtime2.ExecuteFile(read); runtime1.ExecuteFile(read); } } --- Let's compile and run it: C:\IronRuby\Bin\Debug>csc /r:Microsoft.Scripting.dll /r:Microsoft.Scripting.Core.dll /r:IronRuby.dll rt.cs Microsoft (R) Visual C# 2008 Compiler version 3.5.21022.8 for Microsoft (R) .NET Framework version 3.5 Copyright (C) Microsoft Corporation. All rights reserved. C:\IronRuby\Bin\Debug>rt.exe nil C not defined undefined local variable or method `say_bye' for main:Object Hello from runtime #1! some constant bye --- And if you want app-domain isolation, just do ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")). That was easy, wasn't it? Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Monday, April 28, 2008 7:05 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog Sanghyeon Seo: > It seems to be a rather good overview of the status to me. I mostly > agree, except for the accusation that "Microsoft would never back an > OSS web framework like Rails in preference to its own". He also gets a number of important technical details wrong about IronRuby, I'll respond later today. Thanks, -John _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From fuzzyman at voidspace.org.uk Mon Apr 28 19:19:39 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 29 Apr 2008 00:19:39 +0100 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <48165B8B.3070405@voidspace.org.uk> Tomas Matousek wrote: > [snip...] > > And if you want app-domain isolation, just do ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")). > > Does this actually work? No one has been able to post working code on creating an IronPython engine in another app domain on the IronPython mailing list. Can you use this to place restrictions on the app domain - like restrict which assemblies can be loaded and control network / filesystem access? A working example would be a wonderful thing... The reason I am dubious is that it seems that the code generation used by the DLR requires pretty much full trust in .NET 2, so *any* restrictions (which is usually the point of running in another app domain) blow up. I would dearly love to be proved wrong on this of course. Michael Foord > That was easy, wasn't it? > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) > Sent: Monday, April 28, 2008 7:05 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog > > Sanghyeon Seo: > > >> It seems to be a rather good overview of the status to me. I mostly >> agree, except for the accusation that "Microsoft would never back an >> OSS web framework like Rails in preference to its own". >> > > He also gets a number of important technical details wrong about IronRuby, I'll respond later today. > > Thanks, > -John > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > From curt at hagenlocher.org Mon Apr 28 19:25:01 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 28 Apr 2008 16:25:01 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <48165B8B.3070405@voidspace.org.uk> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> <48165B8B.3070405@voidspace.org.uk> Message-ID: On Mon, Apr 28, 2008 at 4:19 PM, Michael Foord wrote: > Tomas Matousek wrote: > > [snip...] > > > > And if you want app-domain isolation, just do > ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")). > Does this actually work? No one has been able to post working code on > creating an IronPython engine in another app domain on the IronPython > mailing list. Actually, I seem to recall that this works fine in IronPython -- provided that you're running under FullTrust. (Which, as you pointed out, needs to be addressed.) -- Curt Hagenlocher curt at hagenlocher.org From mental at rydia.net Mon Apr 28 19:48:38 2008 From: mental at rydia.net (MenTaLguY) Date: Mon, 28 Apr 2008 16:48:38 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds fromthis blog In-Reply-To: References: Message-ID: <37b14a54acb43454231d95c1fadfbd85@localhost> On Mon, 28 Apr 2008 13:57:21 -0600, "M. David Peterson" wrote: > On Mon, 28 Apr 2008 12:53:55 -0600, Michael Letterle > wrote: > >> still an official IronRuby blog will regular updates would be >> awesome. > > Not sure what legal barriers, if any, might stand in the way of using the > existing ironruby.net domain to host a community-driven blog, but if they > do exist yet could somehow be overcome, that would be ideal. A Planet Venus instance set up on planet.ironruby.net might be appropriate. -mental From dinov at exchange.microsoft.com Mon Apr 28 19:46:38 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 28 Apr 2008 16:46:38 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <48165B8B.3070405@voidspace.org.uk> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> <48165B8B.3070405@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C2227012B27AD7820@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Here's a working example (no partial trust) in Python: import clr clr.AddReference('Microsoft.Scripting.Core') import System from Microsoft.Scripting import SourceCodeKind from Microsoft.Scripting.Hosting import ScriptRuntime ad = System.AppDomain.CreateDomain('foo') sr = ScriptRuntime.Create(ad) sr.LoadAssembly(clr.GetClrType(str).Assembly) py = sr.GetEngine('py') su = py.CreateScriptSourceFromString('import System\nprint System.AppDomain.CurrentDomain\n', SourceCodeKind.File) su.Execute() Indeed partial trust might be a problem - we've run into a few bugs there on the desktop CLR where we have divergent code paths from Silverlight. It's also only available on Orcas / .NET 2.0 Sp1 or later where we'll use anonymously hosted dynamic methods if they're available. Finally I believe our "optimized module" and other subclassing of .NET standard types won't work because those need full reflection.emit but I haven't verified that. Anyway, the issue of partial trust has been brought up with various people on the DLR side of things and there should be a push at some point to ensure this works. But there are other advantages w/ app domains than just security. You also get: the ability to unload code w/ a decreased worry of corruption This is using Thread.Abort safely. Large amounts of code can be safely unloaded because there's no shared state outside of the app domain which can be corrupted (note there's some code in the world that this doesn't apply to, but it applies to most of the .NET framework). isolation of static variables that live outside of the script environment I think Tomas alluded to this the ability to unload assemblies Ye-olde-reason to use app domains on the CLR -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Foord Sent: Monday, April 28, 2008 4:20 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog Tomas Matousek wrote: > [snip...] > > And if you want app-domain isolation, just do ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")). > > Does this actually work? No one has been able to post working code on creating an IronPython engine in another app domain on the IronPython mailing list. Can you use this to place restrictions on the app domain - like restrict which assemblies can be loaded and control network / filesystem access? A working example would be a wonderful thing... The reason I am dubious is that it seems that the code generation used by the DLR requires pretty much full trust in .NET 2, so *any* restrictions (which is usually the point of running in another app domain) blow up. I would dearly love to be proved wrong on this of course. Michael Foord > That was easy, wasn't it? > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) > Sent: Monday, April 28, 2008 7:05 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog > > Sanghyeon Seo: > > >> It seems to be a rather good overview of the status to me. I mostly >> agree, except for the accusation that "Microsoft would never back an >> OSS web framework like Rails in preference to its own". >> > > He also gets a number of important technical details wrong about IronRuby, I'll respond later today. > > Thanks, > -John > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From fuzzyman at voidspace.org.uk Mon Apr 28 19:55:59 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 29 Apr 2008 00:55:59 +0100 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <7AD436E4270DD54A94238001769C2227012B27AD7820@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66677@NA-EXMSG-C115.redmond.corp.microsoft.com> <48165B8B.3070405@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227012B27AD7820@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4816640F.2010205@voidspace.org.uk> Dino Viehland wrote: > Here's a working example (no partial trust) in Python: > > Cool! Thanks Dino. I don't normally speak to you here. :-) Michael > import clr > clr.AddReference('Microsoft.Scripting.Core') > > import System > from Microsoft.Scripting import SourceCodeKind > from Microsoft.Scripting.Hosting import ScriptRuntime > > ad = System.AppDomain.CreateDomain('foo') > sr = ScriptRuntime.Create(ad) > sr.LoadAssembly(clr.GetClrType(str).Assembly) > py = sr.GetEngine('py') > su = py.CreateScriptSourceFromString('import System\nprint System.AppDomain.CurrentDomain\n', SourceCodeKind.File) > su.Execute() > > Indeed partial trust might be a problem - we've run into a few bugs there on the desktop CLR where we have divergent code paths from Silverlight. It's also only available on Orcas / .NET 2.0 Sp1 or later where we'll use anonymously hosted dynamic methods if they're available. Finally I believe our "optimized module" and other subclassing of .NET standard types won't work because those need full reflection.emit but I haven't verified that. > > Anyway, the issue of partial trust has been brought up with various people on the DLR side of things and there should be a push at some point to ensure this works. > > But there are other advantages w/ app domains than just security. You also get: > the ability to unload code w/ a decreased worry of corruption > This is using Thread.Abort safely. Large amounts of code can be safely unloaded because there's no shared state outside of the app domain which can be corrupted (note there's some code in the world that this doesn't apply to, but it applies to most of the .NET framework). > isolation of static variables that live outside of the script environment > I think Tomas alluded to this > the ability to unload assemblies > Ye-olde-reason to use app domains on the CLR > > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Foord > Sent: Monday, April 28, 2008 4:20 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog > > Tomas Matousek wrote: > >> [snip...] >> >> And if you want app-domain isolation, just do ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")). >> >> >> > Does this actually work? No one has been able to post working code on > creating an IronPython engine in another app domain on the IronPython > mailing list. > > Can you use this to place restrictions on the app domain - like restrict > which assemblies can be loaded and control network / filesystem access? > > A working example would be a wonderful thing... > > The reason I am dubious is that it seems that the code generation used > by the DLR requires pretty much full trust in .NET 2, so *any* > restrictions (which is usually the point of running in another app > domain) blow up. I would dearly love to be proved wrong on this of course. > > Michael Foord > > > >> That was easy, wasn't it? >> >> Tomas >> >> -----Original Message----- >> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) >> Sent: Monday, April 28, 2008 7:05 AM >> To: ironruby-core at rubyforge.org >> Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog >> >> Sanghyeon Seo: >> >> >> >>> It seems to be a rather good overview of the status to me. I mostly >>> agree, except for the accusation that "Microsoft would never back an >>> OSS web framework like Rails in preference to its own". >>> >>> >> He also gets a number of important technical details wrong about IronRuby, I'll respond later today. >> >> Thanks, >> -John >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > From m.david at xmlhacker.com Mon Apr 28 20:15:54 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 18:15:54 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds fromthis blog In-Reply-To: <37b14a54acb43454231d95c1fadfbd85@localhost> References: <37b14a54acb43454231d95c1fadfbd85@localhost> Message-ID: On Mon, 28 Apr 2008 17:48:38 -0600, MenTaLguY wrote: > > A Planet Venus instance set up on planet.ironruby.net might be > appropriate. I had one set-up at planet.rubyon.net but them phukt things up when I added elastic IP's to the various EC2 instances I had running which now points that same domain to the wrong server. I'll get that fixed later this evening, but regardless, I do agree that a planet-style approach is the right overall approach. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Mon Apr 28 20:21:11 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Mon, 28 Apr 2008 18:21:11 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds fromthis blog In-Reply-To: <37b14a54acb43454231d95c1fadfbd85@localhost> References: <37b14a54acb43454231d95c1fadfbd85@localhost> Message-ID: On Mon, 28 Apr 2008 17:48:38 -0600, MenTaLguY wrote: > A Planet Venus BTW... Wouldn't it be the right thing to do to get Planet Mars running instead of Planet Venus? > http://intertwingly.net/code/mars/ -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From ironruby at monnet-usa.com Mon Apr 28 22:43:34 2008 From: ironruby at monnet-usa.com (Philippe Monnet) Date: Mon, 28 Apr 2008 20:43:34 -0600 Subject: [Ironruby-core] Calling SOAP services from IronRuby Message-ID: <48168B56.7070305@monnet-usa.com> An HTML attachment was scrubbed... URL: From jflam at microsoft.com Mon Apr 28 23:35:34 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Mon, 28 Apr 2008 20:35:34 -0700 Subject: [Ironruby-core] How we will do better at community outreach Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> Thanks for the discussions in the rather long thread today. I wanted to start a new thread under a better subject heading to continue the discussion. I'll be the first to admit that we suffer from the problem where we work on a different source code repository, with an internal-only testing infrastructure, and different internal tools. This causes friction and pain for a lot of folks, and to be blunt there are no simple fixes to this. Everything here involves a trade-off and it boils down to who's going to feel the pain at this point. So let's summarize what most folks would like to see: 1. Move the primary repository to SVN with TFS as our mirror. 2. Move more communication into the external mailing list 3. Release of binaries 4. Scrum-like status updates on the list So let's talk about a few of these issues in turn. 1. SVN as primary repository. This won't happen for several reasons. First, we have effectively four different teams (IronRuby, IronPython, Managed JScript and DLR) working on the same codebase. Only the IronRuby team is on RubyForge (yes, we also drop the DLR sources there, but that's a convenience thing for y'all and not a permanent place for those sources). As the DLR is changed in our TFS repository, it is the responsibility of the dev making those changes to ensure that they don't break any of the languages (and to fix them if the change breaks them). Today we gain the advantage of tight integration between these four projects. The DLR can evolve rapidly which is goodness for folks on the outside. Remember - we're building the platform and the languages in parallel here. Second, we do run what folks would call a continuous integration server. I call it the troll that guards 'the truth' in our repository. When a dev wants to commit code to our repository they need to run those changes past the troll. The troll runs a comprehensive suite of check-in tests against the changes before it commits them to the repository after a successful test run. This provides pretty strong guarantees that the tree is in a consistent state which means that things continue to work when you pull the latest sources. That's much better than the alternative which means that you spend time tracking down build breaks after you sync. The troll has strong dependencies on TFS, and would be very difficult to replicate outside of the company (the troll is really 20 servers inside one of our labs). 2. Move more communication onto the external mailing list This is totally doable, and something we should have done for some time now. What I'm now proposing is this: all IronRuby code reviews will go out through the public mailing list. We will generate a TFS 'unified diff' (http://msdn2.microsoft.com/en-us/library/6fd7dc73.aspx) and attach that diff to the code review email that will be CC'd to ironruby-core. This way you'll have the context for the changes (the source code) along with a detailed email that describes what those changes are, along with some commentary. Note that complex changes are often reviewed face-to-face on our team (think pair-reviewing). But many changes are reviewed entirely by email, so those follow-on emails will be captured for all to see. 3. Release of binaries There is nothing blocking this today, and since we're in a better position to let folks 'kick the tires' these days, I'll add binaries to our repository. 4. Scrum-like status updates to the list This makes sense and I'll talk tomorrow to Tomas and Jim about what we'll do from this point forward. Note that these are just *my* ideas at this point. I'd like to use this as a kick-off for some broader discussions on other issues that are on your mind. Thanks, -John From sanxiyn at gmail.com Tue Apr 29 00:10:45 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 29 Apr 2008 13:10:45 +0900 Subject: [Ironruby-core] Calling SOAP services from IronRuby In-Reply-To: <48168B56.7070305@monnet-usa.com> References: <48168B56.7070305@monnet-usa.com> Message-ID: <5b0248170804282110q38da945fmeb88e7ce8dbafe01@mail.gmail.com> 2008/4/29 Philippe Monnet : > Is that right? Btw what is the 50,000 feet direction for dealing with > generics? Following code works *right now*. (Put it in a file and run with rbx.exe.) require 'mscorlib' include System::Collections::Generic IntList = List.of(Fixnum) a = IntList.new a.add 1 puts a[0] -- Seo Sanghyeon From ryan.riley at panesofglass.org Tue Apr 29 00:34:53 2008 From: ryan.riley at panesofglass.org (Ryan Riley) Date: Mon, 28 Apr 2008 23:34:53 -0500 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog Message-ID: On Mon, Apr 28, 2008 at 08:50:48 -0600, M. David Peterson < m.david at xmlhacker.com> wrote: > > So while Charlie is correct: The IronRuby > project needs to become more community oriented, that community > orientation needs to come from not only MSFT's direction, but the > communities direction as well. > Very well stated. And Wayne's list certainly helps in giving a better understanding of what is left. Such a status sent weekly (at a minimum) could certainly help keep everyone up-to-date. Also, nothing prevents anyone from starting their own git or mercurial branch. If the community wants to actively work by that method, by all means we should. That could potentially even help with the community aspect. The only thing holding anyone back is a desire to stay completely on the same page (a la subversion and rubyforge). Better and more frequent communication would better serve the community in this case. -- Ryan Riley ryan.riley at panesofglass.org http://www.panesofglass.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.kelly at qut.edu.au Tue Apr 29 01:13:35 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Tue, 29 Apr 2008 15:13:35 +1000 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E30017C8C@QUTEXMBX02.qut.edu.au> The issue that Charles raised about people not knowing what others are already working on is an important one. At a higher level, I'd like to see a clearer statement of short term and medium term goals and plans for getting there. Those plans require people taking ownership of certain tasks, so it would be nice to know who is working on what at any given stage - both for people within and external to Microsoft. I also note that this email list serves two audiences, those interested in using IronRuby and those interested in building it. It's probably too early to split the email list, but we should be conscious of this fact when we are trying to manage the activities of this latter core-development group - there probably aren't that many of us! In terms of community building for this core-development group, I'd certainly be interested to know a bit more about who my peers are in this virtual community. Perhaps we could set up a WIKI for core-developers to at least list their names, a little about themselves (no more than one paragraph) and what they're currently working on. With respect to the code repository, the experience as an external contributor is certainly more painful than my experience with Ruby.NET where I could directly commit changes. I'm not suggesting that we should have such privileges with IronRuby, just confirming that there is an issue here. I don't have any concrete suggestions for improvement. Certainly frequent revisions helps (ideally 2 or 3 per week), also timely feedback on what's happening with submitted patches. A number of people are working on entirely new and separate bits, for example implementations of native standard libraries. Currently there is no common place for external contributors to upload prototypes of bits that they are working on. Some form of fileshare or ftp system where people could create directories and unload files may be useful, prior to them being formally merged into the official distribution. This would help us see what people are working on, how far progressed they are, and to make comments. Cheers, Wayne. From sanxiyn at gmail.com Tue Apr 29 01:23:08 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 29 Apr 2008 14:23:08 +0900 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <001301c8a956$77273940$6575abc0$@com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <001301c8a956$77273940$6575abc0$@com> Message-ID: <5b0248170804282223x1c8a38b8ub46ace00699d1de8@mail.gmail.com> 2008/4/29 Peter Bacon Darwin : > I believe one of the key problems is the DLR. As I understand, it MS makes > a distinction between "important" stuff (i.e. the DLR) and "peripheral" > stuff (i.e. IronXxxx). MS wants to have complete control over the DLR and > is not interested in making it Open Source. Rather the DLR code is just > community viewable, much like the rest of the .NET framework code. I can > understand this since core .NET Framework code is central to the MS strategy > and they don't want things sneaking in the sides. I disagree. I think DLR is a non-problem. Reality check: do you have any change in your mind you would like to make to DLR? For example, (sorry for using CPython as an example; I am not familiar with Ruby world) many people contributes to CPython runtime without touching CPython's custom memory allocator. Still many people contributes to CPython standard library and C extensions without touching CPython runtime. -- Seo Sanghyeon From sanxiyn at gmail.com Tue Apr 29 01:35:28 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 29 Apr 2008 14:35:28 +0900 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <5b0248170804282235v3c5e4742id46644c905d0d56a@mail.gmail.com> 2008/4/29 John Lam (IRONRUBY) : > Second, we do run what folks would call a continuous integration server. I call it the troll that guards 'the truth' in our repository. When a dev wants to commit code to our repository they need to run those changes past the troll. The troll runs a comprehensive suite of check-in tests against the changes before it commits them to the repository after a successful test run. This provides pretty strong guarantees that the tree is in a consistent state which means that things continue to work when you pull the latest sources. That's much better than the alternative which means that you spend time tracking down build breaks after you sync. This is very true, but it is ironic since I get to track down build breaks after sync anyway. Sorry, couldn't resist. -- Seo Sanghyeon From bacondarwin at googlemail.com Tue Apr 29 02:06:15 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Tue, 29 Apr 2008 07:06:15 +0100 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <5b0248170804282223x1c8a38b8ub46ace00699d1de8@mail.gmail.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <001301c8a956$77273940$6575abc0$@com> <5b0248170804282223x1c8a38b8ub46ace00699d1de8@mail.gmail.com> Message-ID: <002201c8a9bf$236fb430$6a4f1c90$@com> My point wasn't that one needs to have access to the DLR code. It was that because IronRuby is so tightly coupled to DLR at the moment, it is not possible to remove its tethers and let it free as a proper OSS. Pete -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Sanghyeon Seo Sent: Tuesday,29 April 29, 2008 06:23 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog 2008/4/29 Peter Bacon Darwin : > I believe one of the key problems is the DLR. As I understand, it MS makes > a distinction between "important" stuff (i.e. the DLR) and "peripheral" > stuff (i.e. IronXxxx). MS wants to have complete control over the DLR and > is not interested in making it Open Source. Rather the DLR code is just > community viewable, much like the rest of the .NET framework code. I can > understand this since core .NET Framework code is central to the MS strategy > and they don't want things sneaking in the sides. I disagree. I think DLR is a non-problem. Reality check: do you have any change in your mind you would like to make to DLR? For example, (sorry for using CPython as an example; I am not familiar with Ruby world) many people contributes to CPython runtime without touching CPython's custom memory allocator. Still many people contributes to CPython standard library and C extensions without touching CPython runtime. -- Seo Sanghyeon _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From lists at ruby-forum.com Tue Apr 29 05:06:32 2008 From: lists at ruby-forum.com (Huw Collingbourne) Date: Tue, 29 Apr 2008 11:06:32 +0200 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <5b0248170804282235v3c5e4742id46644c905d0d56a@mail.gmail.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> <5b0248170804282235v3c5e4742id46644c905d0d56a@mail.gmail.com> Message-ID: <855f9c254a924b62f96177ce982ba6ba@ruby-forum.com> John, speaking from our perspective, as the developers of the only currently available IronRuby IDE ( http://www.sapphiresteel.com/Ruby-In-Steel-For-IronRuby ) I can tell you that what we really need is a clearly stated project plan - a 'road map' with well-defined points along the route with features and dates attached. This would be similar to the road map which, for example, the MS SDK team published. Until we have such a plan to work to, our own development on the IronRuby IDE remains stalled as we can't make our own future plans. We have always published road maps for future versions of our standard Ruby IDE but until we have a firm development plan from the IronRuby team, we can't make any future commitments on the IronRuby IDE. best wishes Huw SapphireSteel Software Ruby and Rails In Visual Studio http://www.sapphiresteel.com -- Posted via http://www.ruby-forum.com/. From w.kelly at qut.edu.au Tue Apr 29 08:30:17 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Tue, 29 Apr 2008 22:30:17 +1000 Subject: [Ironruby-core] Rails progress summary Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E2FA597A5@QUTEXMBX02.qut.edu.au> While waiting for some of the gems related issues to be resolved, I thought I'd expand my test suite to include all the ruby source files required by a broader range of use cases, including: - gems setup.rb - gem install rails - rails myapp - start webrick server and process simple HTTP request This includes over 500 real world ruby source files ... Currently, IronRuby is able to successfully load 214 of those. Note that successfully loading these files doesn't necessarily mean that all of the semantics are correct, simply that they don't throw an exception when they are loaded. The remaining 300 odd files currently fail to load for the following reasons: 59 - Loading file paths that contain forward slashes [bug #19841] 47 - ModuleOps.Evaluate not complete 34 - Module::module_function not implemented 33 - Class.new() not implemented [bug #19805] 19 - MemberAssignmentExpression not implemented 17 - Kernel::extend not implemented 16 - to_sym not called on block parameters to convert them to Procs [bug #19714] 12 - Regexp.initialize(String, Fixnum, String) not implemented [bug #19806] 11 - Can't inherit from Numeric [bug #19804] 5 - nkf library not implemented 5 - yaml library not implemented 4 - fctl library not implemented 4 - Interrupt class not defined 4 - Alias resolution problem [bug #19706] 4 - Syntax error relating to JumpStatements [bug #19803] 3 - Module::module_eval not implemented 2 - Module::extend_object not implemented 2 - Module::undef_method(String) not implemented [bug #19842] 1 - enumerator library not implemented 1 - Dir::glob illegal pattern [bug #19843] 1 - eval doesn't handle assignment to constants [bug #19844] 1 - Syntax error relating to do blocks [bug #19845] 1 - Kernel::trap not implemented 1 - stringio library not implemented Cheers, Wayne. From jflam at microsoft.com Tue Apr 29 09:05:55 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 06:05:55 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <001301c8a956$77273940$6575abc0$@com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <001301c8a956$77273940$6575abc0$@com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B490@NA-EXMSG-C115.redmond.corp.microsoft.com> Peter Bacon Darwin: > I believe one of the key problems is the DLR. As I understand, it MS > makes a distinction between "important" stuff (i.e. the DLR) and > "peripheral" stuff (i.e. IronXxxx). MS wants to have complete control > over the DLR and is not interested in making it Open Source. Rather > the DLR code is just community viewable, much like the rest of the > .NET framework code. I can understand this since core .NET Framework > code is central to the MS strategy and they don't want things sneaking > in the sides. Minor correction to this point: The DLR is Open Source in as far as the license is concerned (which is not like the .NET Framework libraries source which is released under a much more restrictive read-only license), which works for folks who are interested in packaging / redistributing / forking. The DLR is does not accept contributions from the community, but feedback is certainly welcome. That said, the bar for feedback is set rather high on the DLR. Most folks are not compiler implementers, and that's the feedback that is needed there. Most folks working on libraries do not need to know anything about how the DLR is implemented (which is useful since that is changing rapidly right now). However, if you're building a language (we're doing 3) you have valuable feedback for the DLR team and that's one of the goals of IronRuby - to provide feedback to the DLR team. The reason why the DLR does not accept contributions from the community is because we intend to ship it in the next version of the .NET framework. And that means that it ships inside of our commercial products like Windows. Having community contributions in Windows is something that we simply cannot do today. > IronRuby, IronPython and so on are not so important to MS strategy and > they are more happy to let the community muck about with the code. I > believe that the long term goal is to open up the IronXxxx code much > more to the community but the problem is that the line between the DLR > and the IronXxxx languages is not yet nailed down. Therefore until > that happens MS is unlikely to hand over the project to the community. IronPython will move to an accept contributions from the community model soon. > I would be interested to know how often an SVN dump is created > compared to successful check-ins going through the SNAP process. > Ideally, every successful SNAP check-in should get automatically > dumped out on the RubyForge SVN repos, whether it added value or broke > the tests or whatever. You can always have SVN tags on the "good" > builds and also create downloadable "good" releases on the RubyForge > site - this point would probably help Justin Bailey's access problems too. Today we do not push to SVN on every successful SNAP check-in. That said, the process on my machine is more-or-less "rake to_svn", with a manual check-in after that. I would be more than happy to push on a daily basis. > Another scenario, which /M:D alludes to if I understand correctly, is > to allow the community to modify the code in the RubyForge project and > then let MS select "good" builds to check back into the Team system > via the SNAP process. That way, the community feels ownership of the > project and MS get that quality control on what finally goes into > IronRuby. > There are obviously many technical hurdles to overcome before this > could become reality. In particular, there needs to be a separation > of DLR from IronXxxx, including, probably, some kind of stable release > of the DLR for the IronXxxx projects to work off. Exactly. Right now the integrated model is good since it means that we progress faster. In the future, when we move to a modular model, it means that DLR changes will break IronRuby which means more work for everyone on this end (the DLR devs will be happier since they'll spend less time fixing us). The bottom line is that work is generated - it's just who feels the pain. > Any other ideas? John what are you thinking here? I collected my thoughts in the other thread that I started last night. Thanks for your ideas! -John From michael.letterle at gmail.com Tue Apr 29 09:06:06 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Tue, 29 Apr 2008 09:06:06 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <001301c8a956$77273940$6575abc0$@com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <001301c8a956$77273940$6575abc0$@com> Message-ID: On Mon, Apr 28, 2008 at 1:36 PM, Peter Bacon Darwin wrote: > > > > > I believe one of the key problems is the DLR. As I understand, it MS makes > a distinction between "important" stuff (i.e. the DLR) and "peripheral" > stuff (i.e. IronXxxx). MS wants to have complete control over the DLR and > is not interested in making it Open Source. Rather the DLR code is just > community viewable, much like the rest of the .NET framework code. I can > understand this since core .NET Framework code is central to the MS strategy > and they don't want things sneaking in the sides. > The DLR sources are under the Microsoft Public License as well. > > Another scenario, which /M:D alludes to if I understand correctly, is to > allow the community to modify the code in the RubyForge project and then let > MS select "good" builds to check back into the Team system via the SNAP > process. That way, the community feels ownership of the project and MS get > that quality control on what finally goes into IronRuby. There are > obviously many technical hurdles to overcome before this could become > reality. In particular, there needs to be a separation of DLR from > IronXxxx, including, probably, some kind of stable release of the DLR for > the IronXxxx projects to work off. > > > At some point the DLR and the languages will have to be separated, once the DLR stabilizes to some point. I don't really think the current arraignment is viable in the long term, not from an OSS point of view anyway. -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From michael.letterle at gmail.com Tue Apr 29 09:10:55 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Tue, 29 Apr 2008 09:10:55 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: Message-ID: The problem with trying to branch IronRuby like that is the DLR is likely to change from underneath it. Not that the idea hasn't occurred to me before, but it's really not a viable option in this scenario. On Tue, Apr 29, 2008 at 12:34 AM, Ryan Riley wrote: > On Mon, Apr 28, 2008 at 08:50:48 -0600, M. David Peterson > wrote: > > So while Charlie is correct: The IronRuby > > project needs to become more community oriented, that community > > orientation needs to come from not only MSFT's direction, but the > > communities direction as well. > > > > Very well stated. And Wayne's list certainly helps in giving a better > understanding of what is left. Such a status sent weekly (at a minimum) > could certainly help keep everyone up-to-date. Also, nothing prevents anyone > from starting their own git or mercurial branch. If the community wants to > actively work by that method, by all means we should. That could potentially > even help with the community aspect. The only thing holding anyone back is a > desire to stay completely on the same page (a la subversion and rubyforge). > Better and more frequent communication would better serve the community in > this case. > > -- > Ryan Riley > ryan.riley at panesofglass.org > http://www.panesofglass.org/ > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From jflam at microsoft.com Tue Apr 29 09:12:47 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 06:12:47 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B493@NA-EXMSG-C115.redmond.corp.microsoft.com> Michael Letterle: > In a technical fashion? No. From an emotional standpoint? Yes. > Right now IronRuby is very unstable from the view of an outside > contributor, you don't know if the code you're working on now is going > to need /major/ changes in the next drop, and you don't know when > that's going to be. Why work on a bug that "in truth" may already be > fixed? Agreed. We do maintain our external bug list in Rubyforge which folks can monitor (are you all receiving update mails on status changes in tracker?). So you'll know when we've fixed a bug when you see the Resolution changes from None to Accepted along with some kind of comment that says 'fixed in next release'. > The most important change that MSFT can do is let you push to rubyforge > DIRECTLY, none of this internal updates pushed to rubyforge once in a > while. I assume it's corporate preventing this, because it really make > no sense otherwise. What we have here isn't an OSS community project > in the traditional sense, what we have is a Microsoft project that > they've so kindly, in their infinite wisdom allow us commoners to work > on now and then. Oh but you can't see or touch the real code until > we're ready to let you. This is HIGHLY discouraging. I've set the releases traditionally based on whether we had something 'interesting' to ship. Sometimes we might go a week or even longer before substantive changes happen in the Ruby tree. Such is life when working on compilers - you simply do not check in very often. Remember that we have Tomas as a full time dev and me as a part time dev on this project. We're hiring as well - please send me mail off-list if you're interested. You'll see more frequent changes in the DLR tree since they have more devs working on the project. Thanks, -John From jflam at microsoft.com Tue Apr 29 09:18:06 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 06:18:06 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <002201c8a9bf$236fb430$6a4f1c90$@com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <001301c8a956$77273940$6575abc0$@com> <5b0248170804282223x1c8a38b8ub46ace00699d1de8@mail.gmail.com> <002201c8a9bf$236fb430$6a4f1c90$@com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B495@NA-EXMSG-C115.redmond.corp.microsoft.com> Peter Bacon Darwin: > My point wasn't that one needs to have access to the DLR code. It was > that because IronRuby is so tightly coupled to DLR at the moment, it is > not possible to remove its tethers and let it free as a proper OSS. > Pete Yep. BTW, this is exactly the set of arguments that are used in making the distinction between integrated and modular systems. We are integrated now because we are optimizing for finishing our work on the DLR (and the first set of languages) sooner. We will become modular in the future because it lets folks build on top of us more easily. If you're curious listen to Clay Christensen's most excellent thoughts on this topic in this podcast: http://itc.conversationsnetwork.org/shows/detail135.html -John From jflam at microsoft.com Tue Apr 29 09:19:57 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 06:19:57 -0700 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <5b0248170804282235v3c5e4742id46644c905d0d56a@mail.gmail.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> <5b0248170804282235v3c5e4742id46644c905d0d56a@mail.gmail.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B499@NA-EXMSG-C115.redmond.corp.microsoft.com> Sanghyeon Seo: > This is very true, but it is ironic since I get to track down build > breaks after sync anyway. Sorry, couldn't resist. Point taken :) That said, what you're seeing here are fairly minor build breaks since most if not all of those build breakages are due to bugs in Mono/gmcs. Imagine if Mono were under heavy development and changing daily. Those kinds of breaks are what you would see if we decoupled IronRuby from DLR. Thanks, -John From michael.letterle at gmail.com Tue Apr 29 09:25:14 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Tue, 29 Apr 2008 09:25:14 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B493@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <372109E149E8084D8E6C7D9CFD82E0632D92D0B493@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Tue, Apr 29, 2008 at 9:12 AM, John Lam (IRONRUBY) wrote: > Michael Letterle: > > > > In a technical fashion? No. From an emotional standpoint? Yes. > > Right now IronRuby is very unstable from the view of an outside > > contributor, you don't know if the code you're working on now is going > > to need /major/ changes in the next drop, and you don't know when > > that's going to be. Why work on a bug that "in truth" may already be > > fixed? > > Agreed. We do maintain our external bug list in Rubyforge which folks can monitor (are you all receiving update mails on status changes in tracker?). So you'll know when we've fixed a bug when you see the Resolution changes from None to Accepted along with some kind of comment that says 'fixed in next release'. > > Is the internal bug list maintained on RubyForge? RubyForge has been getting alot more love then before, but I would still like to see more community members actively use it. > > The most important change that MSFT can do is let you push to rubyforge > > DIRECTLY, none of this internal updates pushed to rubyforge once in a > > while. I assume it's corporate preventing this, because it really make > > no sense otherwise. What we have here isn't an OSS community project > > in the traditional sense, what we have is a Microsoft project that > > they've so kindly, in their infinite wisdom allow us commoners to work > > on now and then. Oh but you can't see or touch the real code until > > we're ready to let you. This is HIGHLY discouraging. > > I've set the releases traditionally based on whether we had something 'interesting' to ship. Sometimes we might go a week or even longer before substantive changes happen in the Ruby tree. Such is life when working on compilers - you simply do not check in very often. Remember that we have Tomas as a full time dev and me as a part time dev on this project. We're hiring as well - please send me mail off-list if you're interested. "Check-in early and often", it doesn't matter if the changes are interesting or there's new features, maybe something that isn't interesting to you that seems mundane is something that causes another developer to be able to create something new and interesting. OSS development is all about collaboration, collaborating is hard when one is left in the dark until something "interesting" happens :) -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From bacondarwin at googlemail.com Tue Apr 29 09:31:01 2008 From: bacondarwin at googlemail.com (Peter Bacon Darwin) Date: Tue, 29 Apr 2008 14:31:01 +0100 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <002901c8a9fd$454eeec0$cfeccc40$@com> What about the "fast-tracking the external Ruby library loading", idea? In other words, allowing external "IronRuby" library code to be developed and compiled into a separate assembly so that it can be loaded into the Ruby runtime via require "...". (Not to be confused with "requiring" a straight .NET assembly, which of course we can do already). This will allow separate OSS projects to be set up that really can have direct community interaction for those libraries that are not core to the IronRuby runtime. The guts of IronRuby are starting to stabilize and there will be less and less to do there but more and more to do on external libraries. It could encourage people to start building library code against IronRuby, therefore providing even more feedback on both IronRuby runtime and so DLR. Also, it could allow the development process to scale out and potentially accelerate toward goals such as running Rails. In the long run, surely, this is the model that you want to have anyway. So why not push toward it now? Pete From jflam at microsoft.com Tue Apr 29 09:41:25 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 06:41:25 -0700 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E30017C8C@QUTEXMBX02.qut.edu.au> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E30017C8C@QUTEXMBX02.qut.edu.au> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4AE@NA-EXMSG-C115.redmond.corp.microsoft.com> Wayne Kelly: > The issue that Charles raised about people not knowing what others are > already working on is an important one. At a higher level, I'd like to > see a clearer statement of short term and medium term goals and plans > for getting there. Those plans require people taking ownership of > certain tasks, so it would be nice to know who is working on what at > any given stage - both for people within and external to Microsoft. Wayne - do you think this would be addressed by a scheduled weekly Monday morning scrum round of emails? Folks can post status updates out of band, of course, but observers can watch those scrum mails for more visibility into what various folks are working on. > I also note that this email list serves two audiences, those interested > in using IronRuby and those interested in building it. It's probably > too early to split the email list, but we should be conscious of this > fact when we are trying to manage the activities of this latter core- > development group - there probably aren't that many of us! In terms of > community building for this core-development group, I'd certainly be > interested to know a bit more about who my peers are in this virtual > community. Perhaps we could set up a WIKI for core-developers to at > least list their names, a little about themselves (no more than one > paragraph) and what they're currently working on. I started a page here: http://ironruby.rubyforge.org/wiki/wiki.pl?Who > Certainly frequent revisions helps (ideally 2 or 3 per > week), also timely feedback on what's happening with submitted patches. That's my fault and I apologize for this. I'll start by doing daily pushes of our tree. > A number of people are working on entirely new and separate bits, for > example implementations of native standard libraries. Currently there > is no common place for external contributors to upload prototypes of > bits that they are working on. Some form of fileshare or ftp system > where people could create directories and unload files may be useful, > prior to them being formally merged into the official distribution. > This would help us see what people are working on, how far progressed > they are, and to make comments. Let me think about this point a bit more. This is related to a point that Pete brought up in a different thread - getting us to fix require and then making it possible for folks to create separate projects. Part of this will involve granting external commit access to the SVN repository - which I'm more than happy to provide. I'll get back to the list about this point later today. Thanks, -John From jflam at microsoft.com Tue Apr 29 09:45:13 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 06:45:13 -0700 Subject: [Ironruby-core] Calling SOAP services from IronRuby In-Reply-To: <48168B56.7070305@monnet-usa.com> References: <48168B56.7070305@monnet-usa.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4B8@NA-EXMSG-C115.redmond.corp.microsoft.com> Philippe Monnet: > I was investigating the ability to call SOAP services (developed in > either Rails or .NET) from a Silverlight/IronRuby client. Since I > think the Ruby Soap libraries are not yet available I looked into > using the Wcf classes in System.ServiceModel but it looks like I have > to wait for generics support so that we can use things like > ChannelFactory. > Is that right? Btw what is the 50,000 feet direction for dealing with > generics? > > Otherwise another option is to generate the client proxies in C# and > include them in the .xap file. I guess I would prefer to keep all my > code in IronRuby though. What are other folks doing in that space? The bigger problem that you're likely to run into is lack of support for attributes in IronRuby. In the Silverlight sample that I wrote which defines the contracts in C# http://www.iunknown.com/2008/03/dynamic-silve-1.html Thanks, -John From jflam at microsoft.com Tue Apr 29 09:53:29 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 06:53:29 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4BF@NA-EXMSG-C115.redmond.corp.microsoft.com> Steve Eichert: > * How can we be more transparent about what we are working on, and > where we are heading? A blog? A weekly posting? > > I'm not as concerned with the medium of the information (blog, this > mailing list, wiki) as long as the community has access to the > information. A daily or weekly or as often as possible scrum like > status update that the community would be able to see would be cool. > > What did you work on since the last update > What will you be working on until the next scheduled update > What's getting in the way of progress This is an excellent idea - would folks prefer a Monday or a Friday update? > > Conceptually a git like repo seems like it would offer some > interesting advantages. I'm a git newbie, but from what I've heard > and read it really encourages people to fork projects and play around > with different ideas. Currently, I can't see what anyone else in the > community is working on, let alone the IronRuby team itself. I think > in order to foster a real community around IronRuby we need to not > only make the ironRuby team itself more transparent, but increase the > transparency of the community as a whole. Perhaps IronRuby should > jump on the github bandwagon? :) > The nice thing about GIT is that you can use they're GIT->SVN bridge and work in a GIT repro on your own box while syncing changes to SVN. So there's nothing stopping you from using GIT today if you want ... Thanks, -John From jflam at microsoft.com Tue Apr 29 10:06:57 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 07:06:57 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <4815F5D7.6010008@sun.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4D4@NA-EXMSG-C115.redmond.corp.microsoft.com> M. David Peterson: > I agree. If I am remembering correctly, one of the primary reasons > behind the dual-repository approach is the need to run a myriad of > internal tests from a test suite that reaches farther and deeper than > just IronRuby, and therefore can not see the light of day outside the > MSFT firewall. There are several issues around this. We run our tests against internal drops of Silverlight (remember we're building IronRuby while simultaneously building DLR *and* CoreCLR). Externals won't be able to see this stuff, and to keep our tree consistent we need to continue to test and run against CoreCLR. > John, is this an accurate assessment? If yes, while I certainly > recognize the need to run the code against internal test suites, > couldn't it be looked at from the opposite perspective?That of: We, the > community, tell you, the big bad corporate firewall, when you get to > gain access to *our* code to run your tests. We will continue on our > way checking it whatever we want whenever we want, and you can use > repository revisions as a marker to determine what can be viewed as > "blessed" and what can not as far as releases are concerned. This is largely a philosophical issue - do you want to resolve build breaks when you sync or do you want to resolve build breaks when you commit. The former is worse than the latter, especially when it takes a significant amount of time to see if things work (40 minutes today). > If it takes a few extra weeks to take a particular > revision of the repository through the internal ringer before getting > the official rubber stamp, then so be it. > It wouldn't be getting in the way of development progress, and if not > mistaken, this is really the core of the argument as to why the process > is currently broken. This will impede progress a lot more than you think it would ... remember - you're writing library code on top of a changing IronRuby compiler + runtime which itself is built on top of a changing DLR which is itself built on top of a changing CoreCLR (aka Silverlight CLR). One of our DLR devs recently spent 30 hours debugging a buffer overrun in a daily build of CoreCLR that was fixed in a subsequent build. Is this the world that you really want to live in? Thanks, -John From michael.letterle at gmail.com Tue Apr 29 10:09:33 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Tue, 29 Apr 2008 10:09:33 -0400 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <002901c8a9fd$454eeec0$cfeccc40$@com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> <002901c8a9fd$454eeec0$cfeccc40$@com> Message-ID: /signed This would help immensely. As of right now all the external libraries are loaded when you run rbx, this is in contrast to mri in that the external libraries have to be required. On Tue, Apr 29, 2008 at 9:31 AM, Peter Bacon Darwin wrote: > What about the "fast-tracking the external Ruby library loading", idea? In > other words, allowing external "IronRuby" library code to be developed and > compiled into a separate assembly so that it can be loaded into the Ruby > runtime via require "...". (Not to be confused with "requiring" a straight > .NET assembly, which of course we can do already). > > This will allow separate OSS projects to be set up that really can have > direct community interaction for those libraries that are not core to the > IronRuby runtime. > > The guts of IronRuby are starting to stabilize and there will be less and > less to do there but more and more to do on external libraries. It could > encourage people to start building library code against IronRuby, therefore > providing even more feedback on both IronRuby runtime and so DLR. Also, it > could allow the development process to scale out and potentially accelerate > toward goals such as running Rails. > > In the long run, surely, this is the model that you want to have anyway. So > why not push toward it now? > > Pete > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From charles.nutter at sun.com Tue Apr 29 10:15:11 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 29 Apr 2008 09:15:11 -0500 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4BF@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4BF@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <48172D6F.50004@sun.com> John Lam (IRONRUBY) wrote: > The nice thing about GIT is that you can use they're GIT->SVN bridge and work in a GIT repro on your own box while syncing changes to SVN. So there's nothing stopping you from using GIT today if you want ... I've been using git-svn for a while now, and it's pretty nice. I'm not using the branching all that much (don't like having long periods of work live only on my machine) but the local committing is oddly satisfying. - Charlie From jflam at microsoft.com Tue Apr 29 10:22:07 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 07:22:07 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <4815F0F2.8090604@gmail.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <4815F0F2.8090604@gmail.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4DC@NA-EXMSG-C115.redmond.corp.microsoft.com> Antonio Cangiano: > The development > process behind JRuby and Rubinius is very open, while IronRuby's one is > not nearly enough so. Impressions are important, and we're working to fix that now. > While granted IronRuby may appeal to less people than Rubinius or > JRuby, I still feel that the development process could benefit a lot > from incremental/daily commits, more transparency and a greater deal of > control handed to the community. Agreed - working on this too. > As Charlie mentioned somewhere else, JRuby is not Sun's, it belongs to > the community. That statement is entirely backed up by facts, but I'm > afraid that, at this stage, it isn' possible to claim the same for > IronRuby. We will make this happen. > This, coupled with the fact that ASP.NET and languages like > C# are clearly Microsoft's main interest, lead me to believe that > IronRuby is not living up to its full potential. Those are orthogonal issues. Microsoft isn't "one" entity - it's many, many teams. Those teams that create a product are naturally invested in its success. We have lots of 3rd party software that runs on our platforms - we're a platform company. We have lived in this co-opetition space for a long, long time. Thanks, -John From jflam at microsoft.com Tue Apr 29 10:37:20 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 07:37:20 -0700 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <002901c8a9fd$454eeec0$cfeccc40$@com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> <002901c8a9fd$454eeec0$cfeccc40$@com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4EE@NA-EXMSG-C115.redmond.corp.microsoft.com> Peter Bacon Darwin: > What about the "fast-tracking the external Ruby library loading", idea? > In other words, allowing external "IronRuby" library code to be > developed and compiled into a separate assembly so that it can be > loaded into the Ruby runtime via require "...". (Not to be confused > with "requiring" a straight .NET assembly, which of course we can do > already). Excellent idea. Will pop this to the top of the queue. This will also force us to initialize $: correctly at startup. > This will allow separate OSS projects to be set up that really can have > direct community interaction for those libraries that are not core to > the IronRuby runtime. Let me noodle on this idea this morning. I have some ideas but I wanted to run them past some folks around here first. > In the long run, surely, this is the model that you want to have > anyway. So why not push toward it now? Agreed. Thanks! -John From jflam at microsoft.com Tue Apr 29 10:38:23 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 07:38:23 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <372109E149E8084D8E6C7D9CFD82E0632D92D0B493@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4F0@NA-EXMSG-C115.redmond.corp.microsoft.com> Michael Letterle: > Is the internal bug list maintained on RubyForge? RubyForge has been > getting alot more love then before, but I would still like to see more > community members actively use it. We don't have an internal bug list (well we do for DLR bugs etc but those aren't important around here). All of our bugs live on Rubyforge. > "Check-in early and often", it doesn't matter if the changes are > interesting or there's new features, maybe something that isn't > interesting to you that seems mundane is something that causes another > developer to be able to create something new and interesting. OSS > development is all about collaboration, collaborating is hard when one > is left in the dark until something "interesting" happens :) Working on this now. Thanks, -John From jb at nurv.fr Tue Apr 29 10:44:16 2008 From: jb at nurv.fr (Jb Evain) Date: Tue, 29 Apr 2008 16:44:16 +0200 Subject: [Ironruby-core] How we will do better at community outreach In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B424@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <69f7d8470804290744k4f664972uacbe0e18b731aacd@mail.gmail.com> Hey, On 4/29/08, John Lam (IRONRUBY) wrote: > This is totally doable, and something we should have done for some time now. What I'm now proposing is this: all IronRuby code reviews will go out through the public mailing list. We will generate a TFS 'unified diff' (http://msdn2.microsoft.com/en-us/library/6fd7dc73.aspx) and attach that diff to the code review email that will be CC'd to ironruby-core. > > This way you'll have the context for the changes (the source code) along with a detailed email that describes what those changes are, along with some commentary. Note that complex changes are often reviewed face-to-face on our team (think pair-reviewing). But many changes are reviewed entirely by email, so those follow-on emails will be captured for all to see. What would be neat, on top of that, is simply having a ironruby-patches list, where automated mails are sent for each commit on the IR repo. Pretty much something like what mono-patches provide: http://lists.ximian.com/pipermail/mono-patches/ That would simply be great to get familiar with the code. -- Jb Evain From acangiano at gmail.com Tue Apr 29 10:44:45 2008 From: acangiano at gmail.com (Antonio Cangiano) Date: Tue, 29 Apr 2008 10:44:45 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4DC@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <4815F0F2.8090604@gmail.com> <372109E149E8084D8E6C7D9CFD82E0632D92D0B4DC@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <4817345D.9030706@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Lam (IRONRUBY) wrote: | [...] | We will make this happen. Great. |> This, coupled with the fact that ASP.NET and languages like |> C# are clearly Microsoft's main interest, lead me to believe that |> IronRuby is not living up to its full potential. | | Those are orthogonal issues. Microsoft isn't "one" entity - it's many, many teams. Those teams that create a product are naturally invested in its success. We have lots of 3rd party software that runs on our platforms - we're a platform company. We have lived in this co-opetition space for a long, long time. Agreed, it's the same in IBM, with many teams and many realities. I mentioned Microsoft's interest (in terms of resources allocated and overall strategy) even if it's orthogonal to the issue at hand because I think that, while not a deal breaker, this aspect can become an aggravating factor if the project is not able to attract sustainable contributions from the community. Cheers, Antonio - -- http://antoniocangiano.com - Zen and the Art of Programming http://stacktrace.it - Aperiodico di resistenza informatica http://math-blog.com - Math Blog: Mathematics is wonderful! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgXNF0ACgkQqCqsu0qUj9S2LACffcNXPSi7uNh944mMNU2aOyrS 4vkAoNtmO2RVLqvzKgf24OwfKGtMg26J =Oxop -----END PGP SIGNATURE----- From steve.eichert at gmail.com Tue Apr 29 11:07:06 2008 From: steve.eichert at gmail.com (Steve Eichert) Date: Tue, 29 Apr 2008 11:07:06 -0400 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4BF@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4BF@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: > > What did you work on since the last update > > What will you be working on until the next scheduled update > > What's getting in the way of progress > > This is an excellent idea - would folks prefer a Monday or a Friday > update? > I don't have a strong preference but I think I'd vote for a Monday update. > > > > > Conceptually a git like repo seems like it would offer some > > interesting advantages. I'm a git newbie, but from what I've heard > > and read it really encourages people to fork projects and play around > > with different ideas. Currently, I can't see what anyone else in the > > community is working on, let alone the IronRuby team itself. I think > > in order to foster a real community around IronRuby we need to not > > only make the ironRuby team itself more transparent, but increase the > > transparency of the community as a whole. Perhaps IronRuby should > > jump on the github bandwagon? :) > > > > The nice thing about GIT is that you can use they're GIT->SVN bridge and > work in a GIT repro on your own box while syncing changes to SVN. So there's > nothing stopping you from using GIT today if you want ... I've been thinking about this. One of the things that triggered this thought is some things I've seen going on in the Rails community. It seems like a lot of people are forking the master to work on ideas. Since they're using github, everyone can see the forks that are out there and see what people are working on, as well as checkout the actual code they're committing. It would be cool to be able to see what the various community members are working on, pull in their changes, and etc. Cheers, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdeville at microsoft.com Tue Apr 29 11:31:22 2008 From: jdeville at microsoft.com (Jim Deville) Date: Tue, 29 Apr 2008 08:31:22 -0700 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <48172D6F.50004@sun.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4BF@NA-EXMSG-C115.redmond.corp.microsoft.com> <48172D6F.50004@sun.com> Message-ID: Agreed. On my last project I was using git-svn for everything except for merging across SVN branches. Did that for months and loved it! Man I miss stash :) JD -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter Sent: Tuesday, April 29, 2008 7:15 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog John Lam (IRONRUBY) wrote: > The nice thing about GIT is that you can use they're GIT->SVN bridge and work in a GIT repro on your own box while syncing changes to SVN. So there's nothing stopping you from using GIT today if you want ... I've been using git-svn for a while now, and it's pretty nice. I'm not using the branching all that much (don't like having long periods of work live only on my machine) but the local committing is oddly satisfying. - Charlie _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From m.david at xmlhacker.com Tue Apr 29 17:16:05 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Tue, 29 Apr 2008 15:16:05 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4D4@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <4815F5D7.6010008@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92D0B4D4@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Tue, 29 Apr 2008 08:06:57 -0600, John Lam (IRONRUBY) wrote: > Is this the world that you really want to live in? Can I think about it? ;-) I kid. No, I do recognize your point. It seems a lot of good things are becoming of this overall conversation, so regardless of how things are structured it seems we're headed in the right direction. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Tue Apr 29 17:16:51 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Tue, 29 Apr 2008 15:16:51 -0600 Subject: [Ironruby-core] Regarding IronRuby... How true it sounds from this blog In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4BF@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B4BF@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: On Tue, 29 Apr 2008 07:53:29 -0600, John Lam (IRONRUBY) wrote: > Friday update? +1: Gives us something to hack on over the weekend. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From jflam at microsoft.com Tue Apr 29 19:24:18 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 16:24:18 -0700 Subject: [Ironruby-core] Code Review: contributions6 Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B9A6@NA-EXMSG-C115.redmond.corp.microsoft.com> tfpt review /shelveset:contributions6;REDMOND\jflam Ruby only This wraps up a number of community contributions into a single shelveset for expediency. This shelveset passed SNAP this morning. We are now passing 2011/2961 (67%) of community specs. Rakefile: - some case sensitivity changes to ensure that things continue to compile on case-sensitive filesystems (*nix) - using methods in fileutils instead of hand-rolled platform specific shell commands - adding a mono switch 'noconfig' to ensure that mono continues to compile ModuleOps: - Expanding patch #19745 from Wayne Kelly to add support for passing strings or objects that implement to_str to private, protected, and public MutableStringOps: - Added alias for String#intern implementation and some comments RegexpOps: - Added some constants - Expanded patch 19749 from Wayne Kelly (an implementation of ===) ExceptionOps: - Added to_str implementation to fix bug #19625 TimeOps: - Expanded patch #19230 from Eric Nicholson for Time methods. Added comments as well as fixing a number of conversion and interop-related bugs. This isn't complete yet, and the specs aren't very valuable for verifying the behavior of these methods until we get backtick or system() working. FileOps: - Expanded patch #19708 for File#exists? to handle directories correctly - Expanded patch #19004 for File#expand_path to handle corner cases correctly. Note that this still requires work to make our directory paths identical to Ruby. Right now the paths returned are Windows paths (Ruby on Windows returns *nix style paths). RubyScope: - Incorporated trivial bug fix on range check: #19754 Specs: - Enables specs for kernel, module, and matchdata. Thanks, -John -------------- next part -------------- A non-text attachment was scrubbed... Name: contributions6.diff Type: application/octet-stream Size: 214632 bytes Desc: contributions6.diff URL: From jflam at microsoft.com Tue Apr 29 19:30:34 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Tue, 29 Apr 2008 16:30:34 -0700 Subject: [Ironruby-core] Getting our code review mails out to the list In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B9A6@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B9A6@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0B9AF@NA-EXMSG-C115.redmond.corp.microsoft.com> This is a test of our new mechanism for getting our code review mails out to you. This is an existing change that's already in SVN, but this will give you an idea of what future mails will look like. Notice that there is an attached diff in the original mail - you can use whatever diff viewing tool that you want to see the changes. This gives you some context to the changes that you'll be seeing. The diff works - but is based on our internal source layout not the external layout. External folks - please just reply to this mail (NOT reply-all) as this will generate a bounce message back to the list if you have comments about the change. Thanks, -John -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Tuesday, April 29, 2008 4:24 PM To: IronRuby External Code Reviewers Cc: ironruby-core at rubyforge.org Subject: [Ironruby-core] Code Review: contributions6 tfpt review /shelveset:contributions6;REDMOND\jflam Ruby only This wraps up a number of community contributions into a single shelveset for expediency. This shelveset passed SNAP this morning. We are now passing 2011/2961 (67%) of community specs. Rakefile: - some case sensitivity changes to ensure that things continue to compile on case-sensitive filesystems (*nix) - using methods in fileutils instead of hand-rolled platform specific shell commands - adding a mono switch 'noconfig' to ensure that mono continues to compile ModuleOps: - Expanding patch #19745 from Wayne Kelly to add support for passing strings or objects that implement to_str to private, protected, and public MutableStringOps: - Added alias for String#intern implementation and some comments RegexpOps: - Added some constants - Expanded patch 19749 from Wayne Kelly (an implementation of ===) ExceptionOps: - Added to_str implementation to fix bug #19625 TimeOps: - Expanded patch #19230 from Eric Nicholson for Time methods. Added comments as well as fixing a number of conversion and interop-related bugs. This isn't complete yet, and the specs aren't very valuable for verifying the behavior of these methods until we get backtick or system() working. FileOps: - Expanded patch #19708 for File#exists? to handle directories correctly - Expanded patch #19004 for File#expand_path to handle corner cases correctly. Note that this still requires work to make our directory paths identical to Ruby. Right now the paths returned are Windows paths (Ruby on Windows returns *nix style paths). RubyScope: - Incorporated trivial bug fix on range check: #19754 Specs: - Enables specs for kernel, module, and matchdata. Thanks, -John From Tomas.Matousek at microsoft.com Tue Apr 29 19:35:19 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Tue, 29 Apr 2008 16:35:19 -0700 Subject: [Ironruby-core] Code Review: contributions6 In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0B9A6@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <372109E149E8084D8E6C7D9CFD82E0632D92D0B9A6@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: expandpath implementation: - GetFullPath, Path.Combine can throw various .NET exceptions. We might need to catch them and throw the exceptions Ruby throws. Other than that looks good. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Tuesday, April 29, 2008 4:24 PM To: IronRuby External Code Reviewers Cc: ironruby-core at rubyforge.org Subject: [Ironruby-core] Code Review: contributions6 tfpt review /shelveset:contributions6;REDMOND\jflam Ruby only This wraps up a number of community contributions into a single shelveset for expediency. This shelveset passed SNAP this morning. We are now passing 2011/2961 (67%) of community specs. Rakefile: - some case sensitivity changes to ensure that things continue to compile on case-sensitive filesystems (*nix) - using methods in fileutils instead of hand-rolled platform specific shell commands - adding a mono switch 'noconfig' to ensure that mono continues to compile ModuleOps: - Expanding patch #19745 from Wayne Kelly to add support for passing strings or objects that implement to_str to private, protected, and public MutableStringOps: - Added alias for String#intern implementation and some comments RegexpOps: - Added some constants - Expanded patch 19749 from Wayne Kelly (an implementation of ===) ExceptionOps: - Added to_str implementation to fix bug #19625 TimeOps: - Expanded patch #19230 from Eric Nicholson for Time methods. Added comments as well as fixing a number of conversion and interop-related bugs. This isn't complete yet, and the specs aren't very valuable for verifying the behavior of these methods until we get backtick or system() working. FileOps: - Expanded patch #19708 for File#exists? to handle directories correctly - Expanded patch #19004 for File#expand_path to handle corner cases correctly. Note that this still requires work to make our directory paths identical to Ruby. Right now the paths returned are Windows paths (Ruby on Windows returns *nix style paths). RubyScope: - Incorporated trivial bug fix on range check: #19754 Specs: - Enables specs for kernel, module, and matchdata. Thanks, -John From Tomas.Matousek at microsoft.com Tue Apr 29 23:16:00 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Tue, 29 Apr 2008 20:16:00 -0700 Subject: [Ironruby-core] Code Review: Procs5 Message-ID: tfpt review /shelveset:Procs5;REDMOND\tomat Refactors Ruby blocks and procs: - The compiled block has now signature (BlockParam, self, formal-args) - self argument was added. Previously it was passed thru BlockParam.Proc in a very hacky way. - Removed hacks from dynamic actions on blocks and methods created by define_method. Improved rules generated for these actions. - RubyBlockInfo no longer inherits from RubyMemberInfo. There is no reason to do so, blocks are not directly stored in method tables and cannot be invoked via InvokeMemberAction. Adds YieldAction - a custom Ruby action for yielding to a block that allows to pass BlockParam and self. Implements module_eval/class_eval - both Proc and string versions. Implements eval that takes Proc as a binding. Adds module_eval and proc related unit tests. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: Procs5.diff Type: application/octet-stream Size: 71068 bytes Desc: Procs5.diff URL: From lists at ruby-forum.com Wed Apr 30 01:42:13 2008 From: lists at ruby-forum.com (Softmind Technology) Date: Wed, 30 Apr 2008 07:42:13 +0200 Subject: [Ironruby-core] Status of SQL Server Support for IronRuby on Rails Message-ID: <9e8992ae49929456a4e72eda11b57a7b@ruby-forum.com> Hi, I would like to work with IronRuby on Rails with Active Record and DataMapper. I understand the adapter for SQL Server 2005/2008 is under preparation by the asp.net team. Can some one help me with the details of current status of the progress. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Wed Apr 30 08:04:15 2008 From: lists at ruby-forum.com (Web Reservoir) Date: Wed, 30 Apr 2008 14:04:15 +0200 Subject: [Ironruby-core] Status of SQL Server Support for IronRuby on Rails In-Reply-To: <9e8992ae49929456a4e72eda11b57a7b@ruby-forum.com> References: <9e8992ae49929456a4e72eda11b57a7b@ruby-forum.com> Message-ID: > I understand the adapter for SQL Server 2005/2008 is under preparation > by the asp.net team. ------------------------------ @ SoftMind I would suggest you to go for MySql only. It would help you with platform changing advantage if required in future, without suffering from Database problems later on. You can host your Rails website with Apache and MySql. You can host your Rails website with Windows and MySql with Fast CGI advantage You CANNOT easily host your Rails website with Apache and SQL SERVER. Under this scenario IronRuby on Rails with MySQL is a safe and best way to go. -- Posted via http://www.ruby-forum.com/. From jflam at microsoft.com Wed Apr 30 10:00:42 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Wed, 30 Apr 2008 07:00:42 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: <000901c8a948$518e7850$f4ab68f0$@com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> Peter Bacon Darwin: > It is not too late to implement something like this. If a bit of work > could be done on loading external IR libraries then projects could > begin to be setup independently. This would have the multiple benefit > of getting people to work on interesting and challenging projects, > potentially creating alternative options to the IR community but also > those people working on the projects are more likely to pickup bugs and > add in the smaller patches to the core that are not getting people > excited at the moment. I'm working on giving commit rights to contributors. We will open up parts of the repository to folks who want to work / collaborate on libraries like zlib, ironi, and your jvyaml port. Something like: src\ zlib ironi yaml ... We would have external folks own those directories and they would be responsible for reviewing contributions into those directories. Those directories would compile into stand-alone assemblies, but this gives folks a place to build and collaborate. I'm leaning towards treating those projects as living on a level above our current libraries + runtime: zlib ironi yaml ironruby.libraries ironruby The ironruby.libraries + ironruby are things that we are responsible for and have to get past our check-in troll. The zlib, ironi, and yaml libraries are things that we will periodically (on a schedule) integrate with our internal test infrastructure. This way, folks outside can continue to work without the overhead (on your end or our end) of having to run each check in past our troll. That said, this means that you're deferring pain until integration time. One of the things that you'll need to ensure happens is that your code compiles and runs using Silverlight. This is *painful* since running CoreCLR outside of the browser is something that we do not support today. Internally we have a tool that lets us do this, but we cannot redist that tool to external folks. Also, that tool is being phased out, and we're replacing it with a browser-based testing infrastructure for code that has to compile and run under Silverlight. We may be able to help with this longer term, but we don't have any short term cycles to make this happen today. I think that the natural owners of these libraries are: zlib: Michael Letterle ironi: Peter Bacon Darwin yaml: John Messerly There may be others - thoughts? Thanks, -John From Tomas.Matousek at microsoft.com Wed Apr 30 12:27:08 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Wed, 30 Apr 2008 09:27:08 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: I would name the assemblies (and maybe the directories for consistency) IronRuby.ZLib, IronRuby.Oniguruma, IronRuby.Yaml since they are dependent on IronRuby and are not general implementations of zlib, regex, yaml. And to be consistent with other assembly names. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Wednesday, April 30, 2008 7:01 AM To: ironruby-core at rubyforge.org Cc: Qing Ye Subject: [Ironruby-core] Opening up our tree to external committers Peter Bacon Darwin: > It is not too late to implement something like this. If a bit of work > could be done on loading external IR libraries then projects could > begin to be setup independently. This would have the multiple benefit > of getting people to work on interesting and challenging projects, > potentially creating alternative options to the IR community but also > those people working on the projects are more likely to pickup bugs and > add in the smaller patches to the core that are not getting people > excited at the moment. I'm working on giving commit rights to contributors. We will open up parts of the repository to folks who want to work / collaborate on libraries like zlib, ironi, and your jvyaml port. Something like: src\ zlib ironi yaml ... We would have external folks own those directories and they would be responsible for reviewing contributions into those directories. Those directories would compile into stand-alone assemblies, but this gives folks a place to build and collaborate. I'm leaning towards treating those projects as living on a level above our current libraries + runtime: zlib ironi yaml ironruby.libraries ironruby The ironruby.libraries + ironruby are things that we are responsible for and have to get past our check-in troll. The zlib, ironi, and yaml libraries are things that we will periodically (on a schedule) integrate with our internal test infrastructure. This way, folks outside can continue to work without the overhead (on your end or our end) of having to run each check in past our troll. That said, this means that you're deferring pain until integration time. One of the things that you'll need to ensure happens is that your code compiles and runs using Silverlight. This is *painful* since running CoreCLR outside of the browser is something that we do not support today. Internally we have a tool that lets us do this, but we cannot redist that tool to external folks. Also, that tool is being phased out, and we're replacing it with a browser-based testing infrastructure for code that has to compile and run under Silverlight. We may be able to help with this longer term, but we don't have any short term cycles to make this happen today. I think that the natural owners of these libraries are: zlib: Michael Letterle ironi: Peter Bacon Darwin yaml: John Messerly There may be others - thoughts? Thanks, -John _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From steve.eichert at gmail.com Wed Apr 30 13:10:22 2008 From: steve.eichert at gmail.com (Steve Eichert) Date: Wed, 30 Apr 2008 13:10:22 -0400 Subject: [Ironruby-core] using ruby libraries with IronRuby Message-ID: I have a bunch of things running around in my head that I'm curious about regarding IronRuby and I'm not sure where to find the answer. I figure my best bet is to drop my questions here. The first question I have is what the current status is regarding using existing Ruby libraries from IronRuby. One of the use cases where I could see a lot of .NET developers using IronRuby is for writing specificiations/unit tests for their code. I've been experimenting with testing some really simple classes written in C# with simple test and I'd like to see if/how IronRuby could get to the next level of testing which might include being able to mock/stub behavior. I've used mocha a bit on a couple Ruby projects and am wondering if someone could help me understand where IronRuby is in regards to being able to use a ruby library such as mocha. The second part of the question is what is the best method for determining what's needed (but not yet implemented in IronRuby) for a given ruby library to run. Now assuming it could run an external ruby library, how would you need to setup IronRuby to properly load it? I assume that's coming when we get gems + yaml support and will just be a require 'mocha'? Cheers, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.letterle at gmail.com Wed Apr 30 14:47:14 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Wed, 30 Apr 2008 14:47:14 -0400 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: The only issue with this is we'll have to have some mechanism for them to be referenced with require 'zlib', requrie 'yaml', et. al. in order to maintain compatibility. On Wed, Apr 30, 2008 at 12:27 PM, Tomas Matousek wrote: > I would name the assemblies (and maybe the directories for consistency) IronRuby.ZLib, IronRuby.Oniguruma, IronRuby.Yaml since they are dependent on IronRuby and are not general implementations of zlib, regex, yaml. And to be consistent with other assembly names. > > Tomas > > > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) > Sent: Wednesday, April 30, 2008 7:01 AM > To: ironruby-core at rubyforge.org > Cc: Qing Ye > Subject: [Ironruby-core] Opening up our tree to external committers > > Peter Bacon Darwin: > > > It is not too late to implement something like this. If a bit of work > > could be done on loading external IR libraries then projects could > > begin to be setup independently. This would have the multiple benefit > > of getting people to work on interesting and challenging projects, > > potentially creating alternative options to the IR community but also > > those people working on the projects are more likely to pickup bugs and > > add in the smaller patches to the core that are not getting people > > excited at the moment. > > I'm working on giving commit rights to contributors. We will open up parts of the repository to folks who want to work / collaborate on libraries like zlib, ironi, and your jvyaml port. > > Something like: > > src\ > zlib > ironi > yaml > ... > > We would have external folks own those directories and they would be responsible for reviewing contributions into those directories. > > Those directories would compile into stand-alone assemblies, but this gives folks a place to build and collaborate. I'm leaning towards treating those projects as living on a level above our current libraries + runtime: > > zlib ironi yaml > ironruby.libraries > ironruby > > The ironruby.libraries + ironruby are things that we are responsible for and have to get past our check-in troll. The zlib, ironi, and yaml libraries are things that we will periodically (on a schedule) integrate with our internal test infrastructure. This way, folks outside can continue to work without the overhead (on your end or our end) of having to run each check in past our troll. > > That said, this means that you're deferring pain until integration time. One of the things that you'll need to ensure happens is that your code compiles and runs using Silverlight. This is *painful* since running CoreCLR outside of the browser is something that we do not support today. > > Internally we have a tool that lets us do this, but we cannot redist that tool to external folks. Also, that tool is being phased out, and we're replacing it with a browser-based testing infrastructure for code that has to compile and run under Silverlight. We may be able to help with this longer term, but we don't have any short term cycles to make this happen today. > > I think that the natural owners of these libraries are: > > zlib: Michael Letterle > ironi: Peter Bacon Darwin > yaml: John Messerly > > There may be others - thoughts? > > Thanks, > -John > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From Tomas.Matousek at microsoft.com Wed Apr 30 14:57:42 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Wed, 30 Apr 2008 11:57:42 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: That could be easily fixed by including 'zlib.rb', 'yaml.rb' next to IronRuby.exe. These files would do require 'IronRuby.ZLib, version=1.0.0.0, ..." to load the .NET assemblies. I need to think about our loader story more, but this idea seems to provide a nice way how to configure where the extensions are located, which version should be used etc. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle Sent: Wednesday, April 30, 2008 11:47 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Opening up our tree to external committers The only issue with this is we'll have to have some mechanism for them to be referenced with require 'zlib', requrie 'yaml', et. al. in order to maintain compatibility. On Wed, Apr 30, 2008 at 12:27 PM, Tomas Matousek wrote: > I would name the assemblies (and maybe the directories for consistency) IronRuby.ZLib, IronRuby.Oniguruma, IronRuby.Yaml since they are dependent on IronRuby and are not general implementations of zlib, regex, yaml. And to be consistent with other assembly names. > > Tomas > > > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) > Sent: Wednesday, April 30, 2008 7:01 AM > To: ironruby-core at rubyforge.org > Cc: Qing Ye > Subject: [Ironruby-core] Opening up our tree to external committers > > Peter Bacon Darwin: > > > It is not too late to implement something like this. If a bit of work > > could be done on loading external IR libraries then projects could > > begin to be setup independently. This would have the multiple benefit > > of getting people to work on interesting and challenging projects, > > potentially creating alternative options to the IR community but also > > those people working on the projects are more likely to pickup bugs and > > add in the smaller patches to the core that are not getting people > > excited at the moment. > > I'm working on giving commit rights to contributors. We will open up parts of the repository to folks who want to work / collaborate on libraries like zlib, ironi, and your jvyaml port. > > Something like: > > src\ > zlib > ironi > yaml > ... > > We would have external folks own those directories and they would be responsible for reviewing contributions into those directories. > > Those directories would compile into stand-alone assemblies, but this gives folks a place to build and collaborate. I'm leaning towards treating those projects as living on a level above our current libraries + runtime: > > zlib ironi yaml > ironruby.libraries > ironruby > > The ironruby.libraries + ironruby are things that we are responsible for and have to get past our check-in troll. The zlib, ironi, and yaml libraries are things that we will periodically (on a schedule) integrate with our internal test infrastructure. This way, folks outside can continue to work without the overhead (on your end or our end) of having to run each check in past our troll. > > That said, this means that you're deferring pain until integration time. One of the things that you'll need to ensure happens is that your code compiles and runs using Silverlight. This is *painful* since running CoreCLR outside of the browser is something that we do not support today. > > Internally we have a tool that lets us do this, but we cannot redist that tool to external folks. Also, that tool is being phased out, and we're replacing it with a browser-based testing infrastructure for code that has to compile and run under Silverlight. We may be able to help with this longer term, but we don't have any short term cycles to make this happen today. > > I think that the natural owners of these libraries are: > > zlib: Michael Letterle > ironi: Peter Bacon Darwin > yaml: John Messerly > > There may be others - thoughts? > > Thanks, > -John > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From jflam at microsoft.com Wed Apr 30 15:09:21 2008 From: jflam at microsoft.com (John Lam (IRONRUBY)) Date: Wed, 30 Apr 2008 12:09:21 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <372109E149E8084D8E6C7D9CFD82E0632D92D0BE16@NA-EXMSG-C115.redmond.corp.microsoft.com> Michael Letterle: > The only issue with this is we'll have to have some mechanism for them > to be referenced with require 'zlib', requrie 'yaml', et. al. in order > to maintain compatibility. Agreed - we still have to build the require mechanism for libraries that are hosted in different assemblies or within the same assembly. Thanks, -John From michael.letterle at gmail.com Wed Apr 30 15:14:59 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Wed, 30 Apr 2008 15:14:59 -0400 Subject: [Ironruby-core] using ruby libraries with IronRuby In-Reply-To: References: Message-ID: You can try requiring any existing libraries out there, but you'll likely to run into issues where IronRuby simply hasn't implemented either syntax or built-in libraries yet. Check the archives of this list a bit, Wayne Kelly has been doing a fantastic job of testing ruby gem's setup.rb file (which is the first step to alot of things), the wiki page for his findings is here: http://ironruby.rubyforge.org/wiki/wiki.pl?TowardsRails Remember, the end goal of IronRuby is to run "real ruby programs", so yes it should just be "require mocha", with perhaps some bridging layer (written in ruby) being required. On Wed, Apr 30, 2008 at 1:10 PM, Steve Eichert wrote: > I have a bunch of things running around in my head that I'm curious about > regarding IronRuby and I'm not sure where to find the answer. I figure my > best bet is to drop my questions here. > > The first question I have is what the current status is regarding using > existing Ruby libraries from IronRuby. One of the use cases where I could > see a lot of .NET developers using IronRuby is for writing > specificiations/unit tests for their code. I've been experimenting with > testing some really simple classes written in C# with simple test and I'd > like to see if/how IronRuby could get to the next level of testing which > might include being able to mock/stub behavior. I've used mocha a bit on a > couple Ruby projects and am wondering if someone could help me understand > where IronRuby is in regards to being able to use a ruby library such as > mocha. The second part of the question is what is the best method for > determining what's needed (but not yet implemented in IronRuby) for a given > ruby library to run. > > Now assuming it could run an external ruby library, how would you need to > setup IronRuby to properly load it? I assume that's coming when we get gems > + yaml support and will just be a require 'mocha'? > > Cheers, > Steve > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From ksunair at yahoo.com Wed Apr 30 16:51:45 2008 From: ksunair at yahoo.com (Unnikrishnan Nair) Date: Wed, 30 Apr 2008 13:51:45 -0700 (PDT) Subject: [Ironruby-core] class question. Message-ID: <508795.93049.qm@web50608.mail.re2.yahoo.com> Please bear with me if it is already discussed; I am running the following code class Tester def sayHello hi puts "I am saying hello" end private def hi puts "Did I say hi?" end private :hi #doube checking private end p = Tester.new p.hi p.sayHello As per ruby, it should fail but Ironruby runs through without any error. I am going through the code to see where it is performed. Thanks. Unni -------------- next part -------------- An HTML attachment was scrubbed... URL: From ksunair at yahoo.com Wed Apr 30 16:53:14 2008 From: ksunair at yahoo.com (Unnikrishnan Nair) Date: Wed, 30 Apr 2008 13:53:14 -0700 (PDT) Subject: [Ironruby-core] Opening up our tree to external committers Message-ID: <824622.65687.qm@web50605.mail.re2.yahoo.com> I have been coding in C# for quite a while, I would love to chip in.... Thanks. ----- Original Message ---- From: Michael Letterle To: ironruby-core at rubyforge.org Sent: Wednesday, April 30, 2008 1:47:14 PM Subject: Re: [Ironruby-core] Opening up our tree to external committers The only issue with this is we'll have to have some mechanism for them to be referenced with require 'zlib', requrie 'yaml', et. al. in order to maintain compatibility. On Wed, Apr 30, 2008 at 12:27 PM, Tomas Matousek wrote: > I would name the assemblies (and maybe the directories for consistency) IronRuby.ZLib, IronRuby.Oniguruma, IronRuby.Yaml since they are dependent on IronRuby and are not general implementations of zlib, regex, yaml. And to be consistent with other assembly names. > > Tomas > > > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) > Sent: Wednesday, April 30, 2008 7:01 AM > To: ironruby-core at rubyforge.org > Cc: Qing Ye > Subject: [Ironruby-core] Opening up our tree to external committers > > Peter Bacon Darwin: > > > It is not too late to implement something like this. If a bit of work > > could be done on loading external IR libraries then projects could > > begin to be setup independently. This would have the multiple benefit > > of getting people to work on interesting and challenging projects, > > potentially creating alternative options to the IR community but also > > those people working on the projects are more likely to pickup bugs and > > add in the smaller patches to the core that are not getting people > > excited at the moment. > > I'm working on giving commit rights to contributors. We will open up parts of the repository to folks who want to work / collaborate on libraries like zlib, ironi, and your jvyaml port. > > Something like: > > src\ > zlib > ironi > yaml > ... > > We would have external folks own those directories and they would be responsible for reviewing contributions into those directories. > > Those directories would compile into stand-alone assemblies, but this gives folks a place to build and collaborate. I'm leaning towards treating those projects as living on a level above our current libraries + runtime: > > zlib ironi yaml > ironruby.libraries > ironruby > > The ironruby.libraries + ironruby are things that we are responsible for and have to get past our check-in troll. The zlib, ironi, and yaml libraries are things that we will periodically (on a schedule) integrate with our internal test infrastructure. This way, folks outside can continue to work without the overhead (on your end or our end) of having to run each check in past our troll. > > That said, this means that you're deferring pain until integration time. One of the things that you'll need to ensure happens is that your code compiles and runs using Silverlight. This is *painful* since running CoreCLR outside of the browser is something that we do not support today. > > Internally we have a tool that lets us do this, but we cannot redist that tool to external folks. Also, that tool is being phased out, and we're replacing it with a browser-based testing infrastructure for code that has to compile and run under Silverlight. We may be able to help with this longer term, but we don't have any short term cycles to make this happen today. > > I think that the natural owners of these libraries are: > > zlib: Michael Letterle > ironi: Peter Bacon Darwin > yaml: John Messerly > > There may be others - thoughts? > > Thanks, > -John > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com _______________________________________________ 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 w.kelly at qut.edu.au Wed Apr 30 19:39:59 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Thu, 1 May 2008 09:39:59 +1000 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> For consistency, can we also separate the other standard libraries such as digest, openssl, etc (that require explicit loading) into separate assemblies? This of course, first requires us to be able to load such assemblies. There will of course be an ever increasing set of such libraries, so it would be nice to have a relatively lightweight process to allow such new directories/libraries to be created. Note, some of these libraries might be implemented using a combination of Ruby and C# code. I hope this mechanism will enable people to upload prototypes of what they're working on, so that we don't need to wait until something is complete and polished before seeing it. Perhaps we could have a generic IronRuby.Misc that people could create directories beneath initially, which could then be moved to top level status once they've matured. Cheers, Wayne. From Tomas.Matousek at microsoft.com Wed Apr 30 21:38:02 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Wed, 30 Apr 2008 18:38:02 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: I don't think we should go crazy and create one dll per library. Loading dlls has some overhead. Since digest and openssl are just IronRuby stubs for functionality already implemented in BCL, it could be in one dll. I need to figure out how to do loading of Ruby libraries contained in an assembly, but I think it could be done. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly Sent: Wednesday, April 30, 2008 4:40 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Opening up our tree to external committers For consistency, can we also separate the other standard libraries such as digest, openssl, etc (that require explicit loading) into separate assemblies? This of course, first requires us to be able to load such assemblies. There will of course be an ever increasing set of such libraries, so it would be nice to have a relatively lightweight process to allow such new directories/libraries to be created. Note, some of these libraries might be implemented using a combination of Ruby and C# code. I hope this mechanism will enable people to upload prototypes of what they're working on, so that we don't need to wait until something is complete and polished before seeing it. Perhaps we could have a generic IronRuby.Misc that people could create directories beneath initially, which could then be moved to top level status once they've matured. Cheers, Wayne. _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core From w.kelly at qut.edu.au Wed Apr 30 22:55:26 2008 From: w.kelly at qut.edu.au (Wayne Kelly) Date: Thu, 1 May 2008 12:55:26 +1000 Subject: [Ironruby-core] Separating standard libraries from builtin In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: <6821FE23D98BAC41AC2A91E7970F31AF1E300AB333@QUTEXMBX02.qut.edu.au> Are you suggesting that long term - modules like digest and openssl remain in the IronRuby.Libraries and be automatically loaded at startup? I had assumed that this was just a temporary hack and I think long term it is the wrong way to go. There are both performance and compatibility arguments ... Firstly, the overhead of loading non-builtin modules such as digest should only be incurred for those applications that explicitly choose to require it. Secondly, by automatically loading such modules, we are poluting the global namespace and setting up possible collisions with programmer created classes. In general, loading a module can have side effects. At present there are only a handful of such modules, but long term there will be dozens, if not hundreds. Matz should be the one that decides which modules get loaded automatically and which require explicit loading. Cheers, Wayne. > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of > Tomas Matousek > Sent: Thursday, 1 May 2008 11:38 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Opening up our tree to external > committers > > I don't think we should go crazy and create one dll per > library. Loading dlls has some overhead. Since digest and > openssl are just IronRuby stubs for functionality already > implemented in BCL, it could be in one dll. I need to figure > out how to do loading of Ruby libraries contained in an > assembly, but I think it could be done. > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly > Sent: Wednesday, April 30, 2008 4:40 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Opening up our tree to external > committers > > > For consistency, can we also separate the other standard > libraries such as digest, openssl, etc (that require explicit > loading) into separate assemblies? > This of course, first requires us to be able to load such assemblies. > > There will of course be an ever increasing set of such > libraries, so it would be nice to have a relatively > lightweight process to allow such new directories/libraries > to be created. > > Note, some of these libraries might be implemented using a > combination of Ruby and C# code. > > I hope this mechanism will enable people to upload prototypes > of what they're working on, so that we don't need to wait > until something is complete and polished before seeing it. > > Perhaps we could have a generic IronRuby.Misc that people > could create directories beneath initially, which could then > be moved to top level status once they've matured. > > Cheers, Wayne. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > From michael.letterle at gmail.com Wed Apr 30 23:02:49 2008 From: michael.letterle at gmail.com (Michael Letterle) Date: Wed, 30 Apr 2008 23:02:49 -0400 Subject: [Ironruby-core] Separating standard libraries from builtin In-Reply-To: <6821FE23D98BAC41AC2A91E7970F31AF1E300AB333@QUTEXMBX02.qut.edu.au> References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> <6821FE23D98BAC41AC2A91E7970F31AF1E300AB333@QUTEXMBX02.qut.edu.au> Message-ID: It may not be /too/ bad if the intent is to load the CLR code, but not expose it to the ruby runtime until a "require" is called for that library.. though I agree, I'd rather have it implemented as separate dlls. This also becomes relevant when we start talking about IronRuby and silverlight, not all silverlight apps are going to need all libraries (or even most) keeping it small is important, but if a library is needed it shouldn't need to take a bunch of baggage with it. On Wed, Apr 30, 2008 at 10:55 PM, Wayne Kelly wrote: > > Are you suggesting that long term - modules like digest and openssl remain in the IronRuby.Libraries and be automatically loaded at startup? > > I had assumed that this was just a temporary hack and I think long term it is the wrong way to go. There are both performance and compatibility arguments ... Firstly, the overhead of loading non-builtin modules such as digest should only be incurred for those applications that explicitly choose to require it. Secondly, by automatically loading such modules, we are poluting the global namespace and setting up possible collisions with programmer created classes. > In general, loading a module can have side effects. At present there are only a handful of such modules, but long term there will be dozens, if not hundreds. Matz should be the one that decides which modules get loaded automatically and which require explicit loading. > > Cheers, Wayne. > > > -----Original Message----- > > From: ironruby-core-bounces at rubyforge.org > > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of > > Tomas Matousek > > Sent: Thursday, 1 May 2008 11:38 AM > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] Opening up our tree to external > > committers > > > > I don't think we should go crazy and create one dll per > > library. Loading dlls has some overhead. Since digest and > > openssl are just IronRuby stubs for functionality already > > implemented in BCL, it could be in one dll. I need to figure > > out how to do loading of Ruby libraries contained in an > > assembly, but I think it could be done. > > > > Tomas > > > > -----Original Message----- > > From: ironruby-core-bounces at rubyforge.org > > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly > > Sent: Wednesday, April 30, 2008 4:40 PM > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] Opening up our tree to external > > committers > > > > > > For consistency, can we also separate the other standard > > libraries such as digest, openssl, etc (that require explicit > > loading) into separate assemblies? > > This of course, first requires us to be able to load such assemblies. > > > > There will of course be an ever increasing set of such > > libraries, so it would be nice to have a relatively > > lightweight process to allow such new directories/libraries > > to be created. > > > > Note, some of these libraries might be implemented using a > > combination of Ruby and C# code. > > > > I hope this mechanism will enable people to upload prototypes > > of what they're working on, so that we don't need to wait > > until something is complete and polished before seeing it. > > > > Perhaps we could have a generic IronRuby.Misc that people > > could create directories beneath initially, which could then > > be moved to top level status once they've matured. > > > > Cheers, Wayne. > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com From curt at hagenlocher.org Wed Apr 30 23:14:23 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 30 Apr 2008 20:14:23 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: One advantage of having "one dll per library" is that you can make decisions about which DLL to load based solely on the library name. Once you have multiple libraries per DLL, you need a more complicated probing or mapping scheme to know which assembly to load. On Wed, Apr 30, 2008 at 6:38 PM, Tomas Matousek < Tomas.Matousek at microsoft.com> wrote: > I don't think we should go crazy and create one dll per library. Loading > dlls has some overhead. Since digest and openssl are just IronRuby stubs for > functionality already implemented in BCL, it could be in one dll. I need to > figure out how to do loading of Ruby libraries contained in an assembly, but > I think it could be done. > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly > Sent: Wednesday, April 30, 2008 4:40 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Opening up our tree to external committers > > > For consistency, can we also separate the other standard libraries such > as digest, openssl, etc (that require explicit loading) into separate > assemblies? > This of course, first requires us to be able to load such assemblies. > > There will of course be an ever increasing set of such libraries, so it > would be nice to have a relatively lightweight process to allow such new > directories/libraries to be created. > > Note, some of these libraries might be implemented using a combination of > Ruby and C# code. > > I hope this mechanism will enable people to upload prototypes of what > they're working on, so that we don't need to wait until something is > complete and polished before seeing it. > > Perhaps we could have a generic IronRuby.Misc that people could create > directories beneath initially, which could then be moved to top level > status once they've matured. > > Cheers, Wayne. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > 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 m.david at xmlhacker.com Wed Apr 30 23:36:34 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Wed, 30 Apr 2008 21:36:34 -0600 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: On Wed, 30 Apr 2008 21:14:23 -0600, Curt Hagenlocher wrote: > One advantage of having "one dll per library" is that you can make > decisions about which DLL to load based solely on the library name. > Once you have multiple libraries per DLL, you need a more complicated > probing or mapping scheme to know which assembly to load. Why not meet half way: Generate netmodules who's primary purpose, if I am remembering correctly, is the ability to be merged together into a final assembly. Again, if I remembering correctly, the original idea was that you could have one team writing code in VB.NET and another in C#, and they could both compile to netmodules which are then merged into a final assembly via a post compilation merging process. WARNING: My memory of the purpose of netmodules might be completely out of whack. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Wed Apr 30 23:40:19 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Wed, 30 Apr 2008 21:40:19 -0600 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: On Wed, 30 Apr 2008 19:38:02 -0600, Tomas Matousek wrote: > I need to figure out how to do loading of Ruby libraries contained in an > assembly, but I think it could be done. Didn't we have this (or a very similar) conversation a while back? -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From tomas at winterdom.com Wed Apr 30 23:43:09 2008 From: tomas at winterdom.com (Tomas Restrepo) Date: Wed, 30 Apr 2008 22:43:09 -0500 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: David, > Why not meet half way: Generate netmodules who's primary purpose, if I am > remembering correctly, is the ability to be merged together into a final > assembly. Again, if I remembering correctly, the original idea was that you > could have one team writing code in VB.NET and another in C#, and they could > both compile to netmodules which are then merged into a final assembly via a > post compilation merging process. > > WARNING: My memory of the purpose of netmodules might be completely out of > whack. You can certainly do that way. I've worked with fairly large code bases that do this, and you can certainly do the merging with link.exe even. That said, this doesn't really solve the loading issue Curt mentions, which is probably the bigger deal. -- Tomas Restrepo http://www.winterdom.com/weblog/ From Tomas.Matousek at microsoft.com Wed Apr 30 23:43:14 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Wed, 30 Apr 2008 20:43:14 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <5b0248170804272231g6dd74f75scd696d22d1829f20@mail.gmail.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: Each library (like digest, openssl) would have its own initialize method. Require would call that initializer. The initializer pollutes the global namespace by types contained in the library. Therefore there is no performance hit nor incompatibility if you don't do require. And loading of such library is a matter of running the initializer. No probing for assemblies on disk. Therefore grouping libraries to a single assembly is better performance-wise. The size of IL of libraries that are just thin wrappers on top of functionality that is already contained in Silverlight distribution is imo negligible. On the other hand, e.g. Oniguruma or Yaml libraries are huge. Therefore it's a good idea to have them in a separate assembly. The only issue that needs to be solved is how to efficiently discover libraries embedded in .NET assemblies. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Curt Hagenlocher Sent: Wednesday, April 30, 2008 8:14 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Opening up our tree to external committers One advantage of having "one dll per library" is that you can make decisions about which DLL to load based solely on the library name. Once you have multiple libraries per DLL, you need a more complicated probing or mapping scheme to know which assembly to load. On Wed, Apr 30, 2008 at 6:38 PM, Tomas Matousek > wrote: I don't think we should go crazy and create one dll per library. Loading dlls has some overhead. Since digest and openssl are just IronRuby stubs for functionality already implemented in BCL, it could be in one dll. I need to figure out how to do loading of Ruby libraries contained in an assembly, but I think it could be done. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly Sent: Wednesday, April 30, 2008 4:40 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Opening up our tree to external committers For consistency, can we also separate the other standard libraries such as digest, openssl, etc (that require explicit loading) into separate assemblies? This of course, first requires us to be able to load such assemblies. There will of course be an ever increasing set of such libraries, so it would be nice to have a relatively lightweight process to allow such new directories/libraries to be created. Note, some of these libraries might be implemented using a combination of Ruby and C# code. I hope this mechanism will enable people to upload prototypes of what they're working on, so that we don't need to wait until something is complete and polished before seeing it. Perhaps we could have a generic IronRuby.Misc that people could create directories beneath initially, which could then be moved to top level status once they've matured. Cheers, Wayne. _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ 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 curt at hagenlocher.org Wed Apr 30 23:49:46 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 30 Apr 2008 20:49:46 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: On Wed, Apr 30, 2008 at 8:36 PM, M. David Peterson wrote: > On Wed, 30 Apr 2008 21:14:23 -0600, Curt Hagenlocher > wrote: > > One advantage of having "one dll per library" is that you can make > > decisions about which DLL to load based solely on the library name. Once > > you have multiple libraries per DLL, you need a more complicated probing or > > mapping scheme to know which assembly to load. > > > > Why not meet half way: Generate netmodules who's primary purpose, if I am > remembering correctly, is the ability to be merged together into a final > assembly. This isn't dynamic, though. There has to be a single manifest for the assembly that lists all the netmodules. I imagine it would be desirable to be able to add a new library simply by copying it into the appropriate directory without having to register it or relink the assembly. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.david at xmlhacker.com Wed Apr 30 23:54:58 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Wed, 30 Apr 2008 21:54:58 -0600 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: On Wed, 30 Apr 2008 21:43:09 -0600, Tomas Restrepo wrote: > You can certainly do that way. I've worked with fairly large code > bases that do this, and you can certainly do the merging with link.exe > even. Cool :) Glad to see my memory hasn't completely failed me! ;-) > That said, this doesn't really solve the loading issue Curt > mentions, which is probably the bigger deal. Is this in reference to distributing a larger collection of Ruby libs inside of a DLL instead of distributing them as seperate .rb files? I'll read back through the thread to see if I can decipher, but if yes, it seems to me the easiest approach is to simply use embedded resources. In fact, now that I think about it, this is definitely a conversation we have had in the past, and if not mistaken the general consensus was to implement a 'resload' keyword to reference embedded resources such that the functionality of the load keyword could be left unmodified. Please disregard the above if this is not what the conversation is related to. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From m.david at xmlhacker.com Wed Apr 30 23:57:19 2008 From: m.david at xmlhacker.com (M. David Peterson) Date: Wed, 30 Apr 2008 21:57:19 -0600 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: On Wed, 30 Apr 2008 21:49:46 -0600, Curt Hagenlocher wrote: > This isn't dynamic, though. There has to be a single manifest for the > assembly that lists all the netmodules. I imagine it would be desirable > to be able to add a new library simply by copying it into the > appropriate directory without having to register it or relink the > assembly. I obviously need to catch up on this thread to better understand the topic at hand. /me is catching up... -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 From curt at hagenlocher.org Wed Apr 30 23:58:43 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 30 Apr 2008 20:58:43 -0700 Subject: [Ironruby-core] Opening up our tree to external committers In-Reply-To: References: <580a8fc4a55d2ecd24eb11f03dba39ee@ruby-forum.com> <4815E720.4000706@sun.com> <372109E149E8084D8E6C7D9CFD82E0632D92C66716@NA-EXMSG-C115.redmond.corp.microsoft.com> <000901c8a948$518e7850$f4ab68f0$@com> <372109E149E8084D8E6C7D9CFD82E0632D92D0BB65@NA-EXMSG-C115.redmond.corp.microsoft.com> <6821FE23D98BAC41AC2A91E7970F31AF1E300189DE@QUTEXMBX02.qut.edu.au> Message-ID: On Wed, Apr 30, 2008 at 8:43 PM, Tomas Matousek < Tomas.Matousek at microsoft.com> wrote: > The only issue that needs to be solved is how to efficiently discover > libraries embedded in .NET assemblies. > It's certainly the *primary* issue. :) -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: