Forum: IronRuby Did Something Changed Again in Spec...

I am trying to unit test my .NET CLR assembly using IronRuby spec
framework. First, the following command does not work anymore

igem install spec

Now, I have to type the following:

igem install rspec

Anyway, when I run the following script:


require 'rubygems'
require 'spec'

require File.dirname(__FILE__) + '/bin/Debug/EStudy.Domain.Model.dll'

include EStudy.Domain.Model.Model

user = User.new

describe User, "when user is created" do

  it "should not be null" do

    user.should == null

  end

  end

I get the following error:


C:\Projects\EStudyVS2008\EStudySoltution\EStudy\ConsoleApplication2>spec
test_us
er.rb --format nested
./bin/Debug/EStudy.Domain.Model.dll: 127: The specified procedure could
not be f
ound.   - Init_EStudy (LoadError)
./bin/Debug/EStudy.Domain.Model.dll     from
c:/ruby/lib/ruby/site_ruby/1.8/ruby
gems/custom_require.rb:31:in `require'
        from ./test_user.rb:5
        from
c:/ruby/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/example_
group_runner.rb:15:in `load'
        from
c:/ruby/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/example_
group_runner.rb:15:in `load_files'
        from
c:/ruby/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/example_
group_runner.rb:14:in `each'
        from
c:/ruby/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/example_
group_runner.rb:14:in `load_files'
        from
c:/ruby/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/options.
rb:133:in `run_examples'
        from
c:/ruby/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/command_
line.rb:9:in `run'
        from c:/ruby/lib/ruby/gems/1.8/gems/rspec-1.3.0/bin/spec:5
        from c:/ruby/bin/spec:19:in `load'
        from c:/ruby/bin/spec:19

Any ideas! I am using the exactly the same code I used before. Before I
used it on IronRuby 0.9 version and now I am using IronRuby RC.

Igem install spec never worked. It's always been igem install rspec. And 
before you complain about the confusion, that is the RSpec project's 
(rspec.info) choice, not ours.

It also looks like when you run spec, you are running the Ruby version, 
not the IronRuby version.

JD

I did ran igem install spec and it worked fine in IR 0.9. Anyway, how 
should I make it work with IronRuby and not Ruby. Does this mean I have 
to alter the ENV path AGAIN!

the command you want is ispec

or you're mixing the gems from your MRI install in which case I'd say 
don't
do that nastiness follows.


---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

There is mspec, spec, rspec...

In order to run IronRuby specification framework do I have to use rspec. 
Also, I think I have to set the ENVIRONMENT variables again for this to 
work right??

man! changing the PATH variable isn't needed

it never worked the way  you say.
http://flanders.co.nz/2009/10/26/creating-launcher-scripts-for-ironruby/
follow that for the spec and spec.bat file



---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

The problem is that my command line does not recognize ispec or rspec or 
mspec. it only recognize spec which is basically ruby framework and not 
ironruby.

Previously with IronRuby 0.9 I used the following command:

spec test_prime.rb --format nested

and it worked.

Now, when I use spec it executes the ruby framework spec and not 
ironruby.

In 0.9 I had to adjust environment variables so that IronRuby spec 
command can be executed from anywhere.

Here is my article on that:

http://www.highoncoding.com/Articles/585_Unit_Testing_CLR_Assembly_Using_IronRuby_with_Spec.aspx

there is mspec, rspec, bacon, .....

Ironruby uses mspec

The rest of the world (that means just about anything that isn't a ruby
implementation) uses rspec, shoulda, bacon, test-unit, test-spec, ....

All you need to do to run the specs for ironruby is that you have to 
execute
dev.bat but I thought we worked out last time that this is probably not 
the
best idea, because it's confusing if you're not used to working in the
console and with the environment variables.
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

For gems:
Mspec is a simplified version of rspec for testing Ruby implementations. 
You shouldn't be using it unless you are testing a Ruby implementation.
Spec does not exist. I don't know how you installed it before, but it 
doesn't exist. It is the name of the library that rspec installs
Rspec is the BDD framework for Ruby that you appear to be looking for.

JD

I don't like to execute dev.bat each time I need to work with IronRuby. 
Why can't it just work out of the box like PowerShell.

This is a big defect in the IronRuby. Too many configurations will scare 
developers away. People are not interested in setting paths in ENV 
variables, performing configuration settings in App.config to make sure 
that IronRuby is pointing to correct lib paths.

Not many people are willing to try out IronRuby because of configuration 
issues.

Does that mean I have to go to the following folder:

C:\DevTools\ironruby-1.0-rc1\lib\ironruby\gems\1.8\gems\rspec-1.3.0\bin

and copy the files into the

C:\DevTools\ironruby-1.0-rc1\bin

folder?

Mohammed listen,

If you just extract the ironruby.zip to c:\ironruby and add 
C:\ironruby\bin
to your PATH you're good to go. always, everywhere.

You're making it out to be harder than it is.

I wrote this earlier but will do it again:
You do igem install rspec
when that completes

copy C:\ironruby\lib\ironruby\gems\bin\spec C:\ironruby\bin\ispec
copy C:\ironruby\lib\ironruby\gems\bin\spec.bat 
C:\ironruby\bin\ispec.bat

now you're good to go.
That wasn't hard was it.

Now my advice to you is:
* read a book on shell/batch scripting
* first check if the problem isn't PEBKAC/user error/...
* use google
* learn properly about ruby and it's ecosystem and more importantly the 
way
it works (the secret it's file based). As it so happens we sell training 
so
feel free to hire us (http://whiterabbitconsulting.eu).
* do stuff in piecemeal. start with the most simple thing you can think 
off
* build your own gem so you know how it works
* ....


Did I mention don't badmouth stuff if the real problem is ignorance.

---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

I guess there is no point doing all of this since IronRuby does not 
support rCov for code coverage for the .NET CLR assemblies.

OKay let's do this step by step. I am failing on step ONE!


C:\Projects\EStudyVS2008\EStudySoltution\EStudy\ConsoleApplication2>igem 
install
 rspec
ERROR:  While executing gem ... (RangeError)
    bignum too big to convert into Fixnum

As we've talked about before, you only need dev.bat if you are 
developing IronRuby. If you are developing with IronRuby, you only need 
to use the installer. If you are embedding IronRuby, then there are 
app.config issues that need to be worked out, some of those can be 
handled by better tooling down the road, some of those can't be helped. 
Even those that can't be helped have alternate API's.

JD

Feel free to port rCov to IronRuby to support a) the subset of rCov 
written in C. b) adding integration for .NET profiling.

JD

What version of IronRuby?

Okay that worked out but I am still not comfortable copying files and 
renaming them to batch files and putting them in the bin directory of 
the IronRuby folder. Also switching back and forth between the dev.bat 
and console. Also, cmd console is not able to find dev.bat from anywhere 
so I have to manually execute it from the folder that contains dev.bat.

I am willing to learn IronRuby and spend countless hours using this cool 
dynamic language. But I am afraid people are just going to GIVE UP 
trying to solve these configuration issues. Setting paths, copying and 
renaming their batch files to ispec whatever...

I am not trying to put down IronRuby but sorry this is not going to work 
in the real world.

Why are you using dev.bat? Are you developing IronRuby? If not, don't 
use
it. It's unnecessary unless you are working on or debugging IronRuby.


Ryan Riley

Email: ryan.riley@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

this will change soon when you can do

ir -S spec spec/**/*_spec.rb
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

When the -S support gets checked in, we shouldn't need copying files and 
so on. Again dev.bat IS NOT NEEDED for anyone who doesn't develop 
IronRuby itself, it is only needed to use the IronRuby sources to build 
IronRuby.

It is expected that dev.bat won't be found unless you add dev.bat to the 
path. We don't plan on changing that since we don't want to mess with 
peoples' paths from the git repo.

JD

This is just basic Ruby. If you want to use Ruby, you have to learn 
Ruby's
nuances. :)


Ryan Riley

Email: ryan.riley@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

Currently in order to run spec I did the following:

1) Set the environment variable for IronRuby (This is done to use 
IronRuby on the machine)

2) Copying the files and renaming them.

3) Add IronRuby configs in App.config if I need to invoke spec command 
from C#.

Sorry to say but 90% of the people will bail out and NOT use IronRuby. I 
have experienced the same feedback from people who were in my IronRuby 
presentation.

>> This is just basic Ruby. If you want to use Ruby, you have to learn 
>> Ruby's
>> nuances. :)

Disagree! You don't have to perform configurations in Ruby. It just 
works :)

interesting you are not opposed to having an installer mess up your 
system
which involves several clicks, registry entries but are opposed to 
adding an
entry to PATH and copying 2 files to make an app, which is still in
development, work.

But good to know what we can do to make it even easier for people to get 
on
board.

would running a small script or installing a gem be better for you?  Can 
I
change the path permanently through the registry or something?
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

The problem is that every person has their own IronRuby folder. It has 
to work same for everyone. Kind of like libraries in GAC.

You are NOT thinking throughly about the problem!

This is not regarding putting the path in ENV variables and copying 
couple of files. This is about doing the same thing for 10 servers. I 
don't think you will be comfortable doing the same for 10 servers.

This also adds extra work for writing build scripts that will do this 
work.

Maybe the IronRuby installation should add the IronRuby folder to a 
common path which is same for all the machines. Kind of like when 
installing the .NET framework which is usually on a common place.

1) what environment variable do you need to set?
2)will be changed soone
3) why are you invoking the spec command from C#?????? It makes sense to 
use other ruby libraries, but it's odd (to me) to use the spec command 
from within C#. We've also mentioned that yes, this could be easier, but 
we don't have the resources at current. Most .NET dev's have had to deal 
with config files, so I don't think your presentation experience is 
typical of most developers.

JD

If you want to deploy easily, then you can include the needed files in 
the same directory as the DLL. Every programming system I have ever used 
requires setup, it's not hard to script setting up ENV variables and 
copying files. We do this kind of thing on 20+ machines for testing for 
IronRuby and IronPython. Using the installer does install to a common 
location, %ProgramFiles%.

JD

I'm sorry if I offended you that wasn't my intention. Don't tell me I'm 
not
thinking.

1. Do you know what gems are and how they work? It's like the GAC
2. It's easy to find out the location of a certain file from script and 
go
from there (killing the need for the PATH variable)
3. exactly it's about a repeatable and scriptable process. so I don't 
think
an installer will do the trick you know, but invoking an included script
does.
4. I fully realise what a build server is, how you do automated 
deployments
and how you provision many machines fast and quite frankly script the 
lot so
I don't have to do it twice.

So my advice stands
Buy a book on batch scripting
learn how ruby works.

if you're provisioning a server the idea is that you're in control of 
where
you download and extract the zip.
so you know and it will probably be the same on another server you 
create
and provision with your script (rocket science, I think not) killing the
need for a preordained location which probably isn't where I want it.
You don't even need to set the path and if you're running a script it's 
easy
to do so in the script.



---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

On Tue, Jan 26, 2010 at 7:50 AM, Mohammad Azam <lists@ruby-forum.com> 
wrote:

> The problem is that every person has their own IronRuby folder. It has
> to work same for everyone. Kind of like libraries in GAC.
>
> You are NOT thinking throughly about the problem!
>
> This is not regarding putting the path in ENV variables and copying
> couple of files. This is about doing the same thing for 10 servers. I
> don't think you will be comfortable doing the same for 10 servers.
>

Seriously? If a developer isn't comfortable with setting ENV variables 
what
hope do they have to actually write decent code? Even visual studio has 
it's
own special command prompt runner (guess what, it's a bat file, just 
like
dev.bat)

Regarding 10 servers, why not? You can write a setup script once and 
execute
it on those 10 servers.


> This also adds extra work for writing build scripts that will do this
> work.
>
> Maybe the IronRuby installation should add the IronRuby folder to a
> common path which is same for all the machines. Kind of like when
> installing the .NET framework which is usually on a common place.
>

The .NET framework does not add it's folder to the common path. Try run
regasm on a clean windows 7 machine from the command prompt and watch it
fail.

This does however raise a small question - does the IronRuby MSI 
installer
drop a registry entry that others can use to determine the installation
path? That seems to be common practice amongst windows apps, and might 
be
handy

You are completely missing my point!!!!

gems are like GAC but IronRuby is not using them as GAC. It is using it 
like a simple zip file extraction and folder path mechanism. Since, it 
is not an installable every developer can download the IronRuby 
framework in a different folder. Which means that on all the machines 
the ENV variable is different and now gems are downloaded also in the 
different folders. If we install IronRuby like "Ruby" using one click 
installer then chances are high that it will reside in a common 
directory. Using the method about I have to announce to all developers 
that please keep your files in C:\IronRuby folder.

>>Seriously? If a developer isn't comfortable with setting ENV variables 
>>what
>>hope do they have to actually write decent code? Even visual studio has 
>>it's
>>own special command prompt runner (guess what, it's a bat file, just 
>>like
>>dev.bat)

Can we move forward to solve the problem instead of mocking?

First, can you please join the mailing list so that we don't have to 
figure out your context. The forum doesn't include the thread.

Gems are not like the GAC. The location of the GAC is hard to change, 
yes you can do it via hint paths, but you will probably break something. 
Gems are easy to move. Simply set your GEM_PATH environment variable. 
You can also redirect the binary location at install time. Some of the 
tools out there change the location of these things on purpose to allow 
you to setup different "environments". Gems are better compared to *nix 
packaging systems than to the GAC. They handle dependency loading, 
installation, versioning, etc.

 If you need the IronRuby folder in the "right" location, then require 
your users to use the installer with default options. However, even 
then, you are requiring your users to go through the greater issue of 
installing IronRuby and all of your required gems. You are also 
requiring them to keep up with your versions if you choose to update. I 
would expect people to include the IronRuby dll's and the required ruby 
libraries with their application, just like they would do with .NET 
libraries. Then the setup isn't a problem since it is only setting up 
the app.

Have you used the IronRuby installer? When I used it, it asked me for a
directory and defaulted to Program Files. How is that different than the
one-click Ruby installer?


Ryan Riley

Email: ryan.riley@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

Most people will use Program files then  c"\IronRuby or 
c:\devtools\Ironruby.

Consider this thread closed!

rofl seriously?  You don't know when to call it quits do you.

If you want to duplicate environments you just zip up your installation,
copy it around, extract and add the location to the path (the last isn't
mandatory, because you can still use absolute paths, after all if you
announce to developers where it needs to be then that's where they need 
to
extract it to). In this case everybody has the same gems and config. How 
is
that worse than running an installer and requiring clicks?


By the way your problem will go a way with the next version of the 
ironruby
installer (remember that this is still in development).
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

On Mon, Jan 25, 2010 at 1:55 PM, Jim Deville <jdeville@microsoft.com> 
wrote:

> If you need the IronRuby folder in the "right" location, then require your
> users to use the installer with default options. However, even then, you are
> requiring your users to go through the greater issue of installing IronRuby
> and all of your required gems. You are also requiring them to keep up with
> your versions if you choose to update. I would expect people to include the
> IronRuby dll's and the required ruby libraries with their application, just
> like they would do with .NET libraries. Then the setup isn't a problem since
> it is only setting up the app.


Right. This isn't .NET, so it shouldn't behave like .NET. If developers 
are
going to use Ruby, then they need to learn to use Ruby. You want to 
solve a
problem, but I'm not seeing that a problem exists. The gem issue seems 
to be
sorted soon with the dash_s addition. Other problems, such as C 
extensions,
are problems for any non-MRI / Ruby 1.9 implementation, and everyone is
working on how to sort that out. IronRuby is still in development, and 
the
team is doing a terrific job getting it there.

You're going to have to help people shift their expectations to get them
onto IronRuby. I don't expect (and don't want) IronRuby to work like C# 
or
VB.NET in Visual Studio. It's a totally different animal altogether, 
which
is what makes it so fun to use!

So, what exactly is the problem you want to solve? And please don't 
mention
config settings (already an issue for other .NET libraries), ENV 
variables
(already optional in MRI), or gem naming issues, as these aren't related 
to
IronRuby.

Regards,
Ryan

I was trying to make ironruby to perform code coverage for a .NET 
assembly using rcov but it seems like it is not currently supported 
yet..

Disagree. Try installing Ruby without the one click installer from 
source. Try using ruby without gem and rake installed.

JD

nope that's right.
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

RCov is partially written in C, so of course it is not supported yet.

I asked about that earlier, as well, and got the response that it is not
covered. I believe one of the goals post-1.0 is to get Ruby FFI working. 
If
you'd like to see RCov working, you might write a patch to move RCov to 
Ruby
FFI so that it will work on IronRuby once FFI support is working. And if 
you
get that done, you might even be able to pitch in with the FFI
implementation. I, for one, would appreciate it. :) Of course, I could 
do
those, too, but I'm working on a few other things, atm. :)


Ryan Riley

Email: ryan.riley@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

How does implementing FFI provide code coverage for the CLR, isn't that
mutually exclusive?  Shouldn't FFI provide us with a way to use C-based
extensions? But C-based extensions won't know about the ironruby 
internals
etc. Just thinking out loud so feel free to correct me :)

Also aren't the stacks produced by IronRuby a little different from the
stacks produced by MRI for example.

To get code coverage for the CLR is that again the CLR profiling API you
would leverage? could somebody point me in the right direction?
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

You’re correct Ivan. Today RCov isn’t even supported on IronRuby because 
it uses a small c-extension. As Shri said previously, it’d be great if 
someone could remove the dependency on the C-extension (easiest way is 
to write the equivalent Ruby code … what Ryan is suggesting is a better 
way-long-term goal for IronRuby to be compatible with FFI-based 
extensions), and then RCov would work for code coverage of only ruby 
code. Now, imagine that was done, and it was called ironruby-rcov … this 
wouldn’t work for code coverage of your .NET code, so you’ll have to use 
the CLR code coverage tools. Only at that point could you think about 
add CLR support to ironruby-rcov.

Make sense now?

~Jimmy

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ivan Porto 
Carrero
Sent: Tuesday, January 26, 2010 1:08 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] Did Something Changed Again in Spec...

How does implementing FFI provide code coverage for the CLR, isn't that 
mutually exclusive?  Shouldn't FFI provide us with a way to use C-based 
extensions? But C-based extensions won't know about the ironruby 
internals etc. Just thinking out loud so feel free to correct me :)

Also aren't the stacks produced by IronRuby a little different from the 
stacks produced by MRI for example.

To get code coverage for the CLR is that again the CLR profiling API you 
would leverage? could somebody point me in the right direction?
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)


On Tue, Jan 26, 2010 at 6:02 AM, Ryan Riley 
<ryan.riley@panesofglass.org<mailto:ryan.riley@panesofglass.org>> wrote:
I asked about that earlier, as well, and got the response that it is not 
covered. I believe one of the goals post-1.0 is to get Ruby FFI working. 
If you'd like to see RCov working, you might write a patch to move RCov 
to Ruby FFI so that it will work on IronRuby once FFI support is 
working. And if you get that done, you might even be able to pitch in 
with the FFI implementation. I, for one, would appreciate it. :) Of 
course, I could do those, too, but I'm working on a few other things, 
atm. :)


Ryan Riley

Email: ryan.riley@panesofglass.org<mailto:ryan.riley@panesofglass.org>
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

On Mon, Jan 25, 2010 at 2:15 PM, Mohammad Azam 
<lists@ruby-forum.com<mailto:lists@ruby-forum.com>> wrote:
I was trying to make ironruby to perform code coverage for a .NET
assembly using rcov but it seems like it is not currently supported
yet..

--
Posted via http://www.ruby-forum.com/.
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core


_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core

rcov has a pure ruby variant too IIRC. And for the sake of this 
discussion
let's just say that that works as is with IronRuby.

Then I'd be looking at the CLR profiling api again isn't it.
And to enable that profiling API don't I have to instrument my dll with 
some
constants so it knows it's going to be profiled?
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)



On Tue, Jan 26, 2010 at 10:17 AM, Jimmy Schementi <

What Jimmy said. :D

Ryan Riley

Email: ryan.riley@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/


On Tue, Jan 26, 2010 at 3:17 AM, Jimmy Schementi <

Also, I think Ruby's FFI is relatively new and not in great use, atm, so
even adding FFI to IronRuby wouldn't do a whole lot to enable the C
extensions of most Ruby libraries until those are ported to use FFI. Is 
that
right?


Ryan Riley

Email: ryan.riley@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/


On Tue, Jan 26, 2010 at 3:17 AM, Jimmy Schementi <

On Tue, Jan 26, 2010 at 3:36 AM, Ivan Porto Carrero 
<ivan@flanders.co.nz>wrote:

> rcov has a pure ruby variant too IIRC. And for the sake of this discussion
> let's just say that that works as is with IronRuby.
>
> Then I'd be looking at the CLR profiling api again isn't it.
> And to enable that profiling API don't I have to instrument my dll with
> some constants so it knows it's going to be profiled?
>

If that's true, then we could start looking into making it work with 
.dlls.
What we may find is something similar to the mocking story: writing a 
new
one is just easier and makes more sense, e.g. caricature. RCov may turn 
out
to be useful only for Ruby apps and too difficult to make work with 
anything
else.

Here's an InfoQ link on some of the progress made by JRuby (and 
Rubinius'
FFI): http://www.infoq.com/news/2008/07/jruby113-rcov-rubinius-ffi-mvm 
This
might be helpful if we decide to attempt a straight port with C# 
extensions.

Ryan Riley

Email: ryan.riley@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

Any particular reason you aren't using NCover or Clover? I'm not sure
generating coverage reports via rcov (even if it existed for the CLR)
for dlls written in C# would actually produce anything usable.

Cheers,
Sidu.
http://blog.sidu.in
http://twitter.com/ponnappa

Ivan, no, you do not need to instrument your dll to use the profiling 
APIs. Instead, you have to set an environment variable called 
COR_PROFILER. http://msdn.microsoft.com/en-us/library/bb384689.aspx has 
more info.

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ryan Riley
Sent: Tuesday, January 26, 2010 5:51 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] Did Something Changed Again in Spec...

On Tue, Jan 26, 2010 at 3:36 AM, Ivan Porto Carrero 
<ivan@flanders.co.nz<mailto:ivan@flanders.co.nz>> wrote:
rcov has a pure ruby variant too IIRC. And for the sake of this 
discussion let's just say that that works as is with IronRuby.

Then I'd be looking at the CLR profiling api again isn't it.
And to enable that profiling API don't I have to instrument my dll with 
some constants so it knows it's going to be profiled?

If that's true, then we could start looking into making it work with 
.dlls. What we may find is something similar to the mocking story: 
writing a new one is just easier and makes more sense, e.g. caricature. 
RCov may turn out to be useful only for Ruby apps and too difficult to 
make work with anything else.

Here's an InfoQ link on some of the progress made by JRuby (and 
Rubinius' FFI): 
http://www.infoq.com/news/2008/07/jruby113-rcov-rubinius-ffi-mvm This 
might be helpful if we decide to attempt a straight port with C# 
extensions.

Ryan Riley

Email: ryan.riley@panesofglass.org<mailto:ryan.riley@panesofglass.org>
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

>
>
> Can we move forward to solve the problem instead of mocking?
> --
>

I would expect you would have better success moving forward if you did 
not
make inflammatory statements such as these:

"This is a big defect in the IronRuby. Too many configurations will
scare developers away."

"Not many people are willing to try out IronRuby because of 
configuration
issues. "

"You are NOT thinking throughly about the problem!"

"I am not trying to put down IronRuby but sorry this is not going to 
work in
the real world."

It is clear that you believe IronRuby is too hard to configure, and I've 
no
doubt that you are feeling some pain. Please try not to make exaggerated
statements saying things are universally broken and unacceptable just
because you are not able to solve something.

Thanks, Orion

I've worked with the COR_PROFILER a little bit before... I'll look if
it's possible from IronRuby :)

> copy C:\ironruby\lib\ironruby\gems\bin\spec C:\ironruby\bin\ispec
> copy C:\ironruby\lib\ironruby\gems\bin\spec.bat C:\ironruby\bin\ispec.bat
>
>
On my machine (in case it's useful to someone else), here are the paths 
and
instructions for rspec

http://gist.github.com/291624

-- Thibaut

you don't need to do that anymore :)

At least not for the ironruby that is on github and built from source

there the instructions become:

ir -S gem install rspec

run specs:
ir -S spec spec/**/*_spec.rb

---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)



On Mon, Feb 1, 2010 at 12:39 PM, Thibaut Barrère

> you don't need to do that anymore :)

>
> At least not for the ironruby that is on github and built from source
>
> there the instructions become:
>
> ir -S gem install rspec
>
> run specs:
> ir -S spec spec/**/*_spec.rb
>

thanks for the trick, that's good to hear (although I mostly use MSI
releases these days, doing client work).

-- Thibaut