On Mon, 12 May 2008 23:23:32 -0600, Web Reservoir <[EMAIL PROTECTED]> wrote:
> (1) Visual Studio .net (2001)
+= Visual Studio 2003 (the original was Visual Studio 2002, if not mistaken)
> (2) Visual Studio 2005 -(2005)
Released in November of 2005, so really should have been called Visual
Whoops ... some files didn't actually get committed on the last checkin.
Strange. You'll need to update to r107 to compile successfully.
Thanks,
-John
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Lam
(IRONRUBY)
Sent: Wednesday, May 14, 2008 8:44 AM
To: ironruby-core@rubyf
This fixes the DLR Tuple bug #19971. This, along with Tomas' shelveset later
today should fix most of the reported blocking issues. We should be able to
check in the latest Ruby specs later today as well.
Thanks,
-John
___
Ironruby-core mailing list
I
Unnikrishnan Nair:
> I wrote down the test and display the result on the console with puts.
A meta-level note: beware of running things via irb. Things like __FILE__ don't
behave the way you would expect them to because irb is a Ruby program. If in
doubt, write your code in a file and run it vi
Peter Bacon Darwin:
> By the way, I had this idea of creating a small program that would help
> with regression testing against MRI. Instead of writing full RSpecs,
> we should write snippets of Ruby that work the classes. The program
> would then run the snippets against MRI and IronRuby (and a
Michael Letterle:
> Aren't we running (or going to be running) the official spec suite
> (http://rubyspec.org) ?
We are going to be checking in the rubyspec suite later this week. I just got
the fix for the DLR tuple bug last night and I'll push it out later this
morning. That was the major thi
Aren't we running (or going to be running) the official spec suite (
http://rubyspec.org) ?
These specs are already written on the assumption that MRI /is/ THE
implementation of Ruby.
On Wed, May 14, 2008 at 9:55 AM, Unnikrishnan Nair <[EMAIL PROTECTED]>
wrote:
> Hi Pete,
>
> I was kind of doing
Hi Pete,
I was kind of doing what you are saying but manually though. But after seeing
the specs, I stopped doing it altogether.
I wrote down the test and display the result on the console with puts. Now run
the script with 'ruby' on console and redirect the output to a file (not MRI, I
need
You are right, when I ran against MRI I got the "". In my case I always use
_why's web page to test the results and unfortunatly the result was ".bashrc",
you see I trust _why :)
So if this has to match MRI, yes, then I need to change the code. Let me know.
Thanks.
- Original Message
My understanding is that when IronRuby is officially released it /will/ be
signed, going through and removing the "SIGNED" variable from the other
projects should allow it to build correctly. The hard coded dependence
below is in an #if.
It's always been like this, in fact I had to reference remo
I am really sorry about that. I will make sure it does not happen. it is just
to get the group e-mail id. I better add the email to my contact and start new
thread when required.
Thanks.
- Original Message
From: Web Reservoir <[EMAIL PROTECTED]>
To: ironruby-core@rubyforge.org
Sent: W
Ironically, I haven't noticed since GMail has continued to thread the posts
properly...
Out of curiosity what reader are you using?
On Wed, May 14, 2008 at 2:08 AM, Web Reservoir <[EMAIL PROTECTED]> wrote:
> Hi Unni.
>
> I do not understand, why do you always want to start a new thread for an
>
I have been working on the basis that MRI is the reference implementation
and so the specs should reflect that. If, on writing a spec, an obvious bug
is exposed then we should be sending this on to the RubyLang lot and getting
them to fix it.
Otherwise if it's good enough for MRI its good enough
Unnikrishnan Nair wrote:
One more spec change. Could you please review line 8 of this spec, it
should read
File.extname(".bashrc").should == ".bashrc"
instead of
File.extname(".bashrc").should == ""
Quick question: are the specs supposed to ensure that IronRuby matches
MRI's behavio
14 matches
Mail list logo
