Reminder: Should have a /try section powered by opal-rspec

[elia]

@dchelimsky @elia @adambeynon @opalrb Amazing. Would be cool to include something like that on the new rspec site /cc @mootpointer

– @myronmarston

Demo:

http://opal.github.io/opal-playground/rspec/

Code:

https://github.com/opal/opal-playground/blob/master/source/rspec.html.haml
https://github.com/opal/opal-playground/blob/master/source/javascripts/playground-rspec.js.rb

[myronmarston]

I had forgotten about that discussion and the opal site! I'd definitely still like to see something like this on our site. Thoughts, @JonRowe?

[myronmarston]

I noticed that the opal-rspec Repo is vendoring RSpec and is pinned to 3.0.0.beta1 (which is 15 months old!). Why is it necessary to vendor RSpec? And can it be updated to RSpec 3.2?

[elia]

The only issue I know about was with the custom require system from rspec-support.

It's vendored to let people use a different version in CRuby world.

That said probably @adambeynon knows better

[myronmarston]

The only issue I know about was with the custom require system from rspec-support.

Ah, I didn't realize that caused you problems. It's done in order to use require-relative on ruby versions that support that, since that is always O(1) regardless of how many entries you have on your load path, compared to O(N) for require. Maybe we can find a way to solve the problems for you so you don't have to vendor anymore?

[elia]

Would be great!

The other usual pain point with gems is the use of mutable strings, currently some monkey patching is in place for them:

https://github.com/opal/opal-rspec/blob/master/opal/opal/rspec/fixes.rb

[myronmarston]

What specifically is the problem with the custom require in rspec-support? Assume I know nothing about opal (since I practically do).

[elia]

All files in opal must be precompiled to js before they're required. Currently the compiler catches method calls to require and require_relative and tries to get the path (eg a static string is easy). With the list of requires from a given file we can go and precompiled them too so they're available at runtime.

The problem is with dynamic requires (eg passing a local var or method call to require) wich can't be inferred automatically. That is the case with rspec requires.

Just for the record all precompiled files go in a js object literal (Opal.modules) with the "logical path" as the key and the compiled file wrapped in an anonymous function as the value.

Hope the explanation was clear :)

Btw I did an experiment with 3.2 and requiring everything manually seems to work, the tricky part being getting the require order right. I still see some issues with autoload tho.

[JonRowe]

I'm onboard with having this provided we can embed it into our site and it works reliably! Would be nicer to have console looking output rather than the html output, maybe we can feed it into ascii cinema somehow to have that faux "it's doing something" look :)

[elia]

Status update: @wied03 is in the process of running rspec specs in opal-rspec and the upgrade to the latest version opal/opal-rspec#30

Bringing this to attention in case he needs any help or has questions specific to rspec

[wied03]

Hi guys.

Just in case it wasn't clear before, it's vendored (now using git submodules at RSpec 3.1) for the reason @ella mentioned (versioning) and also to avoid monkey patching someone who is using RSpec with MRI. I suppose if we can get current and be more robust with how we do things, we could eventually get rid of that and just work w/ whatever version of RSpec GEM the user has (and only monkey patch it when they use it inside Opal).

As to more recent work, I'm slowly but surely going through the rspec-core specs and making fixes or filtering specs that I don't expect to pass.

Anyways, the idea is to get through the specs for core, expectations, and mocks. Then hopefully we have a better baseline and it will be easier to stay more current.

In the meantime, I've also broken out the monkey patch fixes, mirroring the original directory structure, so that it's easier to see what's being patched: https://github.com/wied03/opal-rspec/tree/features/rspec_specs/opal/opal/rspec/fixes

[wied03]

An update, we got through the expectations, core, support, and mock specs and the code at the master branch of https://github.com/opal/opal-rspec has been updated. A new beta will be coming soon. There are a decent amount of filters in place for what's not working with more documentation in the README about that.

Most of the failed specs/features are due to the following:

• Mutable string use - we monkey patched rspec implementations for these uses, some mutable string use in specs means those examples are ignored
• Mocking strings/numbers - Opal can't create singleton classes on string instances since they are immutable JS objects (can only mock string methods for the entire class). Any specs that mock strings fail.
• Any_instance - unknown as to what's going on there
• Underlying Opal issues - there are still Opal issues with tricky constant resolution and complex inheritance/include chains with modules. Opal is improving in this area but some of this likely has ripple effects and is responsible for some of the above issues.

[benoittgt]

Do we still want to make this @JonRowe ?

[pirj]

That would be insanely cool, but I doubt very often used :D

[JonRowe]

If someone where to make it work I'd be happy to see it on the website, but equally I'm not stressed about it.