Littl' question about the build process

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.

Is it already done somewhat ? What do you think ?

regards,

– Thibaut

Thibaut Barrère:

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 :slight_smile:

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.

-John

Thibaut Barrère:

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?

  • John

John M.:

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?

Thanks,
-John

John,

I am using VS2005 still. I do have VS2008 installed, is there a
technical
reason to move to VS2008 for IronRuby hacking?

-Rob B.

Hey,

On 1/15/08, John M. [email protected] wrote:

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 :slight_smile:

Hi,

I’m using VS 2005 so far (and my readers will use it next month when
they read their article), I’ve not yet switched to 2008 express.

It seems reasonable to switch to 2008 in a couple of months though
(and maintain only 2008).

– Thibaut

Has the goal of IronRuby to require .NET 3.5 all this time? If so, I
guess
I missed it but it makes sense and makes the technology better.

-Rob

Hey John,

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));

DynamicSite<object, object, object> greaterThanSharedSite = DynamicSite<object, object, object>.Create(InstanceCallAction(">", ArgumentKind.Simple));

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.

Jb Evain:

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 :slight_smile:

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));

DynamicSite<object, object, object> greaterThanSharedSite =
DynamicSite<object, object, object>.Create(InstanceCallAction(">",
ArgumentKind.Simple));

But we can’t move to the new compiler until we get enough folks agreeing
to switch over …

-John

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.

+1 on this.

– Thibaut

Tomas R.:

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).

-John

Hey John,

On 1/16/08, John L. (DLR) [email protected] wrote:

It’s not VS that we’re concerned about, it’s C#. It would be so nice to be able to type:

It wasn’t clear to me that this discussion was about the language
version, and not about the VS version.

var greaterThanSharedSite = DynamicSite<object, object, object>.Create(InstanceCallAction(">", ArgumentKind.Simple));

DynamicSite<object, object, object> greaterThanSharedSite = DynamicSite<object, object, object>.Create(InstanceCallAction(">", ArgumentKind.Simple));

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
«relatively» new.

Jb Evain:

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 :slight_smile:

-John

+1 for C# 3.0

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.)

C# 3.0 doesn’t require new features from the CLR, just some new libraries (System.Core and friends).

Thanks for the clarification. Then yes, I’ll vote for the switch to C#
3.0. Like Jb said, it’s a new project, let’s move on!

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.

-Rob

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)

– Thibaut

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

cheers

– Thibaut

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs