I thought I’d see how far I could get trying to execute gems setup.rb
The following lists the issues that I came across and how I fixed or
worked around them:
- Encountered assertion error in MergeLocations method when parsing
- changed code to cope with case where start location > end location
- fixed a subsequent bug where _currentLineIndex wasn’t restored after
encountering a HEREDOC
- Encountered unimplemented exception for NTH_REF.TransformRead
- quick hack: provide a dummy implementation that simply returns Null
- Undefined constant ENV
- created a new global constant of type ENV and implemented  and
delete methods in EnvOps.cs
- note, this should really have be done by adding singleton methods
rather than creating a new type
- Uninitialized constant Config
- this is meant to come from rbconfig.rb which gets loaded when gems
are loaded via -rubygems command line option
- so I added a -r command line option to automatically preload said
- we may also want to support getting command line arguments from
RUBYOPT environment variable.
- Now using rbx.exe
- Now using rbx.exe
- Loads ubygems.rb but then can’t load thread.so
- quick hack: change thread.rb so that it doesn’t require thread.so
- Runtime error: version 1.8.6 doesn’t match executable version
188.8.131.52 in rbconfig.rb
- change rbconfig.rb to expect 184.108.40.206.
- Note this is going to be a problem in general as many ruby apps
access RUBY_VERSION at runtime and expect it to be 1.8.x
The question is, should the version represent the version of the
language supported or the version of the platform implementation?
- Versions still don’t match as RUBY_VERSION constant is a CLR string
rather than a MutableString.
- change RUBY_VERSION and RUBY_RELEASE_DATE to be MutableString
- Uninitialized constant DESTDIR in rbconfig.rb
- this is due to bug in defined?, so I extended
AstNodeDescriptionExpression.TransformRead to deal correctly with
- Scoping bug for nested blocks in rbconfig.rb as discussed in a
- create new CodeContext constructor to initialize parent property for
nested code contexts
- Note: these changes are entirely within the DLR, not IronRuby! - is
it really a DLR bug or is IronRuby
using these constructs incorrectly?
- undefined method gsub! in rbconfig.rb
- this method is not yet implemented. Is it waiting for port of the
JRuby regular expression library?
Are we sure we can’t get by with built-in .NET regular expressions
(with some workarounds)?
Does anyone have an example of a Ruby regular expression that we
can’t deal with using .NET regular expressions?
Some of the patches that I’ve provided are quick and dirty hacks, so I
don’t necessarily expect them to find their way into the official
version in their current form, but they should at least give some idea
about some of the fixes that will be required to get gems and hence