I need some clarifications for my readers: I believe we have three
ways of compiling IronRuby today:
through the rake compile task (is it the preferred way ?)
through IronRuby.sln (for 2005)
through Ruby.sln (for 2008 ?)
Are both the .sln files maintained ? Is my guess correct about 2005/2008
?
In the long run, are all these intented to be maintained ?
ps: John I wrote you an email a while back but I’m not sure you got it
actually. I was suggesting we could (in a couple of weeks maybe,
unless it’s already done internally at ms ?) grab a couple of the most
widely used ruby gems, focus on those with unit tests or specs (or
write a couple of integration tests ourselves), and setup a continuous
integration server to run those gems tests through rbx.
I need some clarifications for my readers: I believe we have three
ways of compiling IronRuby today:
through the rake compile task (is it the preferred way ?)
through IronRuby.sln (for 2005)
through Ruby.sln (for 2008 ?)
Are both the .sln files maintained ? Is my guess correct about
2005/2008 ?
The IronRuby.sln file is for external folks to use. Ruby.sln is one that
reflects the legacy source code layout in our internal tree.
In the long run, are all these intented to be maintained ?
For the forseeable future, yes.
ps: John I wrote you an email a while back but I’m not sure you got it
actually. I was suggesting we could (in a couple of weeks maybe,
unless it’s already done internally at ms ?) grab a couple of the most
widely used ruby gems, focus on those with unit tests or specs (or
write a couple of integration tests ourselves), and setup a continuous
integration server to run those gems tests through rbx.
I’m going to forward my reply to you - I sent a reply out yesterday, but
to myself
But for the benefit of the list, we’re focusing on doing gap analysis-
there’s a new task that I’ve added to the rakefile that uses
set_trace_func to trace all calls that a target application makes. It
also reflects over the IronRuby libraries and diffs the output for
standard library types. This way we have a complete list of all of the
library methods that need to be implemented to run that app. I’ve
completed the analysis for gem install, which is the first ‘real app’
milestone that we want to get working. We’re about 140 methods short
today, with the bulk of those mapping to regex and YAML and socket-based
IO.
I need some clarifications for my readers: I believe we have three ways
of compiling IronRuby today:
through the rake compile task (is it the preferred way ?)
through IronRuby.sln (for 2005)
through Ruby.sln (for 2008 ?)
Are both the .sln files maintained ? Is my guess correct about
2005/2008 ?
In the long run, are all these intented to be maintained ?
As John said, IronRuby.sln is the one that is correctly transformed to
SVN folder layout. Ruby.sln is against our TFS folder layer. Maybe we
could rename them to make it more obvious which is which.
Also, I’m wondering what VS version we should target with IronRuby.sln.
Are enough people using 2008 to justify upgrading it? Or should we have
one for 2005 and one for 2008? Or keep it 2005 for now?
As John said, IronRuby.sln is the one that is correctly transformed to
SVN folder layout. Ruby.sln is against our TFS folder layer. Maybe we
could rename them to make it more obvious which is which.
Also, I’m wondering what VS version we should target with IronRuby.sln.
Are enough people using 2008 to justify upgrading it? Or should we have
one for 2005 and one for 2008? Or keep it 2005 for now?
To amplify this a bit more:
Is there anyone out there still using VS 2005 to hack on IronRuby?
Also, I’m wondering what VS version we should target with IronRuby.sln. Are enough people using 2008 to justify upgrading it? Or should we have one for 2005 and one for 2008? Or keep it 2005 for now?
That’s probably the best way to reach and ease most people. I tend to
simply suffix the filename with the VS version it targets, ex:
IronRuby-2008.csproj.
Along with a script to update the csprojs to keep them in sync
But we can’t move to the new compiler until we get enough folks agreeing to switch over …
Personally, I’m building with VS2008 for now, and wouldn’t mind being
forced to use VS2008 to develop. The more interesting question is
whether .NET 3.5 would become the minimum requirement for the DLR and
IronRuby at runtime. If the idea is to still be targeting plain .NET
2.0 for runtime, I think that would be a lot better and more palatable
for many people.
That’s probably the best way to reach and ease most people. I tend to
simply suffix the filename with the VS version it targets, ex:
IronRuby-2008.csproj.
Along with a script to update the csprojs to keep them in sync
It’s not VS that we’re concerned about, it’s C#. It would be so nice to
be able to type:
var greaterThanSharedSite = DynamicSite<object, object,
object>.Create(InstanceCallAction(">", ArgumentKind.Simple));
Personally, I’m building with VS2008 for now, and wouldn’t mind being
forced to use VS2008 to develop. The more interesting question is
whether .NET 3.5 would become the minimum requirement for the DLR and
IronRuby at runtime. If the idea is to still be targeting plain .NET
2.0 for runtime, I think that would be a lot better and more palatable
for many people.
We’re targeting CLR v2.0 which is the version of the CLR that ships in
.NET 3.5 (confusing, yes :)).
C# 3.0 doesn’t require new features from the CLR, just some new
libraries (System.Core and friends).
That would be nice indeed. And if we’re talking about C#, I would not
mind seeing IronRuby focusing on C#3, as the project itself is
new.
Me too. But we don’t want to slow down folks who are working on
libraries as well. There are plenty on our team that want to switch, but
we haven’t made a call on that yet. But if y’all make enough noise it
will help us advance our cause inside
I’m assuming you’d update the Rakefile? This would involve a little
work since it currently uses a single constant for both the location
of Framework libraries and the compiler (csc). We’d have to split
those but that’s not too much work. (The alternative to changing the
Rakefile is to instruct everyone to run it from the VS or SDK command
prompt, which seems less desirable to me.)
If the target is going to be CLR 2.0 anyway, why not just do it now?
Does the RakeFile even work for us externally? I have tried it a few
times
and it always blows up. Apparently there needs to be something fed to
it I
am not doing.
Does the RakeFile even work for us externally? I have tried it a few times and it always blows up.
Apparently there needs to be something fed to it I am not doing.
Did you try running the “rake happy” task to see if your environment
is ok ? (PATH must include folders with csc.exe and resgen.exe)
Note the ruby version. If you use the Windows installer then the latest
one
(Ruby-186-26) crashes inside Pathname2. Drop back to Ruby-186-25 and
you
should be fine.
Pete
Does the RakeFile even work for us externally? I have tried it a few times
and it always blows up. Apparently there needs to be something fed to it I
am not doing.
“rake compile” works for me. In case you want to compare, here’s my
configuration:
ruby 1.8.5 (2006-12-25 patchlevel 12) [i386-mswin32]
rake, version 0.8.1
