Preparing 1.1.2 release

Preliminary binaries are here packaged as an .msi (hopefully, it’s
accessible):

http://alturl.com/3xnzm

Let me know if there were any problems with the installation. Especially
test various Gems - this release should fix the infamous “can’t convert
NilClass into String” bug (http://ironruby.codeplex.com/workitem/5728,
http://ironruby.codeplex.com/workitem/5695, etc.).

(an alternative link to the .msi is
http://9qodxw.blu.livefilestore.com/y1pvmLNcFco8fyb3ow2A7mrDtNZ8oXH-yz2sNbCiJhvamDaDSSo3-6u1kEd97ivI9sV82s0ImyhZmdPZV0pyzxM4WxhTkm1vNJN/IronRuby.msi?download&psid=2)

Thanks,
Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Shay F.
Sent: Tuesday, February 01, 2011 12:38 AM
To: [email protected]
Subject: Re: [Ironruby-core] [IronPython] Proposed Release Schedule for
2.7

I’d be happy to help. Let me know what needs to be done.

Shay.

On Tue, Feb 1, 2011 at 8:41 AM, Tomas M.
<[email protected]mailto:[email protected]>
wrote:
It’s easy to build the msi’s and I’ll run IronRuby tests. I could use
some help with IronRuby Tools testing.

Tomas

From:
[email protected]mailto:[email protected]
[mailto:[email protected]mailto:[email protected]]
On Behalf Of Jimmy S.
Sent: Monday, January 31, 2011 8:28 PM
To: Discussion of IronPython
Cc: [email protected]mailto:[email protected]
Subject: Re: [IronPython] Proposed Release Schedule for 2.7

That schedule looks good for me too, and I can help get the releases out
as well.
~Jimmy
On Sun, Jan 30, 2011 at 3:37 PM, Tomas M.
<[email protected]mailto:[email protected]>
wrote:
I propose we sync IronRuby releases with IronPython as follows:

IronRuby - IronPython - date
1.1.2 - Beta 2 - February 6
none - RC1 - February 20
none - RC2 - February 27
1.1.3 - RTM - March 6

Tomas

Unfortunately none of the links are accessible…
Regards
Eduardo

Tomas M. wrote in post #979978:

Preliminary binaries are here packaged as an .msi (hopefully, it’s
accessible):

http://alturl.com/3xnzm

Let me know if there were any problems with the installation. Especially
test various Gems - this release should fix the infamous “can’t convert
NilClass into String” bug (http://ironruby.codeplex.com/workitem/5728,
http://ironruby.codeplex.com/workitem/5695, etc.).

(an alternative link to the .msi is

http://9qodxw.blu.livefilestore.com/y1pvmLNcFco8fyb3ow2A7mrDtNZ8oXH-yz2sNbCiJhvamDaDSSo3-6u1kEd97ivI9sV82s0ImyhZmdPZV0pyzxM4WxhTkm1vNJN/IronRuby.msi?download&psid=2)

Thanks,
Tomas

Oops :frowning:

Let’s try again:
http://cid-b3ba7307194acfee.skydrive.live.com/self.aspx/IronRuby/IronRuby.msi

I have the binaries ready, will publish them in the evening unless there
is some major issue.

Tomas

Will this run on Mono or is .net 4.0 required?

Hi Tomas,

I’m willing to try 1.1.2 a bit on Mac OS X if you’d like.

How can I download it ? (the link you provided is a .msi only if I’m
right
?)

As well, I recall someone mentioning issues to ensure RVM would be able
to
automatically download it (maybe EULA agreement on codeplex that could
not
be skipped).

This would definitely help people on non Windows machine try it it, as
RVM
is pretty standard amongst rubyists these days (outside Windows I mean).

Let me know if I can help!

– Thibaut

IronRuby 1.1.2 runs on Mono, though there are some bugs in Mono that
might cause issues in certain scenarios. The best Mono version to try it
on would be 2.10. The .msi requires .NET 4.0, a separate zip package
with raw dlls will be available later today (you can always build from
sources as well).

I tested the binaries on Mono 2.10 RC2 on Windows. If you have
non-Windows systems, please, try 1.1.2 out, report bugs and/or submit
fixes!

Thanks,
Tomas

I’m cloning it right now (then I’ll look where is Ruby.sln, because I
have
no idea yet :-)). I’ll report back here after doing a few basic tests.

Having a script that takes dlls built by xbuild and packages them for Mac
would be great. Any volunteers?

I can try that out next week if all goes well with my current website
launch
:slight_smile: But yes, I think I’ll be able to help here.

– Thibaut

I’ll publish the binaries in the evening today. That said, there wasn’t
really any testing on non-Windows platform at all that I know of. So it
might be best to build a debug build from sources instead of using
release build. Error stack traces will be better.
Mono 2.10 RC2 is able to build Ruby.sln on Windows. It would be
interesting to see if it works well on MacOS. Would you be willing to
clone git repo and run “xbuild Ruby.sln”? You can then try to use the
built binaries from Bin\Debug directory.

Having a script that takes dlls built by xbuild and packages them for
Mac would be great. Any volunteers?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Thibaut Barrre
Sent: Monday, February 07, 2011 2:08 PM
To: [email protected]
Subject: Re: [Ironruby-core] Preparing 1.1.2 release

Hi Tomas,

I’m willing to try 1.1.2 a bit on Mac OS X if you’d like.

How can I download it ? (the link you provided is a .msi only if I’m
right ?)

As well, I recall someone mentioning issues to ensure RVM would be able
to automatically download it (maybe EULA agreement on codeplex that
could not be skipped).

This would definitely help people on non Windows machine try it it, as
RVM is pretty standard amongst rubyists these days (outside Windows I
mean).

Let me know if I can help!

– Thibaut

I’m cloning it right now (then I’ll look where is Ruby.sln, because I have
no idea yet :-)). I’ll report back here after doing a few basic tests.

I can report the compile went without any issue as long as I’m on Mono
2.10
RC2.

I was able to start “mono ir.exe” and do a couple of things. require
“rubygems” raised a SIGSEGV:

/tmp/mono-gdb-commands.2Rimy1:1: Error in sourced command file:
unable to debug self

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

Abort trap

But well - it already compiles out of the box, which is good!

– Thibaut

Great! I spent some time to make xbuild happy J, Im glad it works on
non-Windows boxes as well.

Thanks for that really :slight_smile:

I’ve got a question wrt the build script we could set up: are the
resulting
binaries different if I compile from Mac OS X, as compared with Ubuntu ?

If they are identical, I could work on provisioning a Vagrant box with
all
that is required to generate the builds on Ubuntu automatically.

This would let anyone with access to Vagrant (and I think it works on
Windows too for the host) with the ability to automate the builds and
tests
for IronRuby on *nix, and we could also push this to a VPS instance
later on
so that we keep fresh automated binaries for OS X / Ubuntu etc.

Are the resulting binaries identical ?

I filed a couple of Mono bugs (crashes) yesterday:

So this might be hitting one of them. Or another. I guess we can either
wait until these are fixed and try again or try to narrow the Rubygems crash
down to a simpler repro.

I’ll wait a bit, given my current free time, but I will definitely try
again
later on (feel free to ping me if you want to try things out later on,
by
email or gtalk [email protected]).

– Thibaut

Great! I spent some time to make xbuild happy :), I’m glad it works on
non-Windows boxes as well.

I filed a couple of Mono bugs (crashes) yesterday:

Access Deniedhttps://bugzilla.novell.com/show_bug.cgi?id=669808
(GetCustomAttributes crash)
Access Denied (non-deterministic
crash in /nointerpret)

So this might be hitting one of them. Or another. I guess we can either
wait until these are fixed and try again or try to narrow the Rubygems
crash down to a simpler repro.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Thibaut Barrre
Sent: Monday, February 07, 2011 2:54 PM
To: [email protected]
Subject: Re: [Ironruby-core] Preparing 1.1.2 release

I’m cloning it right now (then I’ll look where is Ruby.sln, because I
have no idea yet :-)). I’ll report back here after doing a few basic
tests.

I can report the compile went without any issue as long as I’m on Mono
2.10 RC2.

I was able to start “mono ir.exe” and do a couple of things. require
“rubygems” raised a SIGSEGV:

/tmp/mono-gdb-commands.2Rimy1:1: Error in sourced command file:
unable to debug self

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

Abort trap

But well - it already compiles out of the box, which is good!

– Thibaut

Re binaries - 3 flavors are currently built:

  1.  Desktop CLR 4.0 (.NET FW 4.0, Mono 2.10)
    
  2.  Core CLR 4.0 (Silverlight 4.0, Moonlight)
    
  3.  Core CLR 3.0 (Windows Phone 7)
    

So yes, the binaries should be equivalent. They won’t be byte-for-byte
equal, but should functionally be the same. So should be binaries built
on Windows using Microsoft C# compiler or Mono C# compiler.

Re packaging and build automation: Sync with Jeff H. who maintains
IronPython. We should have one solution for both languages.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Thibaut Barrre
Sent: Monday, February 07, 2011 3:33 PM
To: [email protected]
Subject: Re: [Ironruby-core] Preparing 1.1.2 release

Great! I spent some time to make xbuild happy :), I’m glad it works on
non-Windows boxes as well.

Thanks for that really :slight_smile:

I’ve got a question wrt the build script we could set up: are the
resulting binaries different if I compile from Mac OS X, as compared
with Ubuntu ?

If they are identical, I could work on provisioning a Vagrant box with
all that is required to generate the builds on Ubuntu automatically.

This would let anyone with access to Vagrant (and I think it works on
Windows too for the host) with the ability to automate the builds and
tests for IronRuby on *nix, and we could also push this to a VPS
instance later on so that we keep fresh automated binaries for OS X /
Ubuntu etc.

Are the resulting binaries identical ?

I filed a couple of Mono bugs (crashes) yesterday:
So this might be hitting one of them. Or another. I guess we can either
wait until these are fixed and try again or try to narrow the Rubygems
crash down to a simpler repro.

I’ll wait a bit, given my current free time, but I will definitely try
again later on (feel free to ping me if you want to try things out later
on, by email or gtalk
[email protected]mailto:[email protected]).

– Thibaut