So, the tags are of 3 classes:
· Fails: delete and regenerate (below)
· Unstable and thread: leave these alone. They indicate ones that are
non-deterministic
· Critical: these indicate specs that cause hangs, process teardown, or
corrupt future tests (I don’t think we h
That did it. I'll have to be more careful with merging that particular file
in the future.
Now, how do I go about updating the tags? Is it the following, or do I need
to go through some specs manually?
C:\Users\Will\dev\ironruby\External.LCA_RESTRICTED\Languages\IronRuby\mspec>mspec
tag rubyspec
FYI, there ended up being no changes that were specific for Rack 1.1.0 -- just
bug-fixes to IronRuby.Rack in general.
From: ironruby-core-boun...@rubyforge.org [ironruby-core-boun...@rubyforge.org]
on behalf of Jimmy Schementi [jimmy.scheme...@microsoft.com]
Sent:
Inside of the MSpec in our tree, I have added a filtered method to
External.LCA_RESTRICTED/Languages/IronRuby/mspec/mspec/lib/mspec/utils/script.rb
(I believe). You’ll need to get that method merged into your branch to user
our config.
JD
From: ironruby-core-boun...@rubyforge.org
[mailto:iron
Databinding to Dynamic Objects in Silverlight 4 is not supported. However,
IronPython supports a feature that does enable databinding in Silverlight, but
it requires that you adorn your code with static-type information:
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-and-databinding.h
The public version of faster_rubygems on RubyGems.org is 0.9.2, which installs
fine with IronRuby. It looks like you’re trying to install 0.9.3 from a .gem
file, so there is most likely an issue with the new gem? Try installing 0.9.2
by just doing “igem install faster_rubygems” and see if that w
I said "#new" in some places where I shouldn't have ... so corrected below in
case there was some confusion ...
> -Original Message-
> From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-
> boun...@rubyforge.org] On Behalf Of Jimmy Schementi
> Sent: Tuesday, June 29, 2010 11:
Philippe Leybaert wrote:
> But I personally think this behavior is completely wrong. Calling .new from
> IronRuby should always call the constructor, not a static method named
> .New() that happens to exist somewhere in the class hierarchy. (if the
> .New() method is defined in a base class, you g
True, but I’m not seeing this reproduce (granted I’m trying on a 64-bit
machine, but that shouldn’t make a difference). Can you list what envvars you
have set?
C:\Program Files (x86)\IronRuby 1.0v4\bin>igem install faster_rubygems
Building native extensions. This could take a while...
faster_
>
> "C:/Program Files/IronRuby 1.0v4/bin/ir.exe" -rubygems C:/Program
> Files/IronRuby 1.0v4/lib/ironruby/gems/1.8/gems/rake-0.8.7/bin/rake
> RUBYARCHDIR="C:/Program Files/IronRuby
> 1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.3/lib"
> RUBYLIBDIR="C:/Program Files/IronRuby
> 1.0v4/lib/iron
Thanks, that does seem to work.
But I personally think this behavior is completely wrong. Calling .new from
IronRuby should always call the constructor, not a static method named .New()
that happens to exist somewhere in the class hierarchy. (if the .New() method
is defined in a base class, you
> D:\> ir -e "require 'rubygems'; puts Gem::VERSION"
> 1.3.5
Ok, tried it with "default" rubygems...
Seems to still have said problem...
C:\dev\ruby\faster_rubygems>ir -e "require 'rubygems'; puts
Gem::VERSION"
1.3.5
C:\dev\ruby\faster_rubygems>ir -S gem install faster_rubygems-0.9.3.gem
Buil
You can call CLR constructor using "clr_new" method:
Tester.clr_new
Tomas
-Original Message-
From: ironruby-core-boun...@rubyforge.org
[mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Philippe Leybaert
Sent: Tuesday, June 29, 2010 9:57 AM
To: ironruby-core@rubyforge.org
Subject
Shay Friedman suggested I'd post this to the mailing list, as it may be a bug
in IronRuby:
It seems impossible to call a constructor when there is a static .New() method
defined on a class.
This is a minimal test case demonstrating the problem:
.NET (C#) class:
public class Tester
{
On Tue, May 18, 2010 at 4:52 PM, Jimmy Schementi
wrote:
>> 2) have a checkbox for if we want to install with the i prefix or not on pre-
>> installed gems (I know I for one wouldn't).
>
> We don't preinstall any gems with IronRuby. So what you're asking is an
> option so we remove the "i" from "i
15 matches
Mail list logo
