These are chat archives for opal/opal

24th
Dec 2015
Jamie Gaskins
@jgaskins
Dec 24 2015 00:27
0 files, 10014 examples, 29309 expectations, 0 failures, 0 errors, 3481 tagged
10k RubySpecs now?
Elia Schito
@elia
Dec 24 2015 00:27
indeed :D
and I suspect a bunch more after the merge of the break fix
and possibly some more after the runtime cleanup…
Jamie Gaskins
@jgaskins
Dec 24 2015 00:29
Do you know how many RubySpecs there are in total?
I just remember it was a big deal when you guys reached 5k. :-)
Jamie Gaskins
@jgaskins
Dec 24 2015 00:38
@elia I just noticed what might be a regression in 0.9.0 related to the fix for #1244. Now, objects that don't respond to to_n are passed as null in Hash#to_n instead of simply being passed through. So { foo: MyObject.new }.to_n now returns the JS object { foo: null }. Is that intentional or should I file a PR?
Elia Schito
@elia
Dec 24 2015 00:40
Not sure tbh, I'd say fire the PR tho
Jamie Gaskins
@jgaskins
Dec 24 2015 00:41
:+1:
Vais Salikhov
@vais
Dec 24 2015 01:03
@wied03 don't worry about it, for what it's worth, I'm in the same boat :smile:
@elia @jgaskins really looking forward to @iliabylich's opal/opal#1206 getting merged as well. I will do another RubySpec cleanup after all these pending changes are in Opal.
Vais Salikhov
@vais
Dec 24 2015 01:11
@iliabylich doing the same for String would be awesome, but I understand you may want to wait on that until the Array stuff gets merged in first. @meh really just waiting on you to "sign off" on opal/opal#1206 since you are the :crown: when it comes to the inheritance stuff :wink: Any reason (other than time) keeping you from merging it?
Elia Schito
@elia
Dec 24 2015 01:12
@jgaskins re total number of specs I recall they're about 16k, which possibly makes 10k even more awesome:D
Jamie Gaskins
@jgaskins
Dec 24 2015 01:17
@elia Wow, that's impressive.
@vais Nice! Although tbh I've heard a lot of people over the years suggesting never to inherit from core types, even on MRI, because you run into a lot of similar annoying issues. I'm not sure if it's a real problem with MRI anymore, but I'm surprised to see people inheriting from Array instead of making their own Enumerable types.
Elia Schito
@elia
Dec 24 2015 01:18
Looks like they're 24k, not bad anyway
jiayp
@jiayp
Dec 24 2015 02:53
Is there a Opal debug guid?
How to see the value of global variable $tmp in browser?
Jamie Gaskins
@jgaskins
Dec 24 2015 03:11
@jiayp Opal.gvars.tmp
jiayp
@jiayp
Dec 24 2015 03:20
@jgaskins Thanks
Ilya Bylich
@iliabylich
Dec 24 2015 12:35
@elia Do you plan to update opal to 0.9 on http://opalrb.org/try ?
Vais Salikhov
@vais
Dec 24 2015 12:38
@jgaskins amen brother :smile: You're preaching to the quire - I don't think I've ever made a class that inherits from String or Array, and having worked with some that do, it's just so weird that it's not worth it. That said, we need it to work so we can pass RubySpec :wink:
Ilya Bylich
@iliabylich
Dec 24 2015 12:47
@jgaskins @vais Sometimes people just create their own classes like MyCollection < Array to simplify the logic (inside this class self is pretty much like your inner @collection, so you can remove some initialization code from this collection) :smile: . You are right, nobody uses it. But it's required as a part of the work on marshalling for opal (https://github.com/opal/opal/pull/1191)
Ilya Bylich
@iliabylich
Dec 24 2015 13:00
@vais It seems that String can't be fixed. For both Array and String all the core methods are defined directly on Array.prototype/String.prototype. For Array it's fine, you can change an instance of array, it's mutable, so attributes like $$class and $$proto can be modified on the instance. But String is immutable, that's impossible.
You can have only one value of "string".$$proto/"string".$$class for all instances of String and its subclasses (which comes from String.prototype)
Vais Salikhov
@vais
Dec 24 2015 14:02
I see, makes sense...
Elia Schito
@elia
Dec 24 2015 15:07
@/all anyone have some with the "appraisals" gem?
Ilya Bylich
@iliabylich
Dec 24 2015 16:20
@elia Looks like you didn't specify gemfiles that you want to use in the build matrix: https://github.com/thoughtbot/appraisal#travis-ci-integration
The gem 'opal-jquery' wasn't installed in your build because travis used a default gemfile. As I understand, appraisal should merge a default gemfile with a custom one (for a current build)
Ilya Bylich
@iliabylich
Dec 24 2015 16:26
(You can actually remove appraisal and specify a matrix directly through BUNDLE_GEMFILE=gemfiles/rails_x.x.x.gemfile, your default gemfile doesn't look too big, so there shouldn't be so much duplication)
Ilya Bylich
@iliabylich
Dec 24 2015 16:48
@elia What is a $$base_module field for modules? Is it something similar to a memoized Module.nesting? Like the namespace where the module was actually defined? Can't find any docs or related issues about it :smile:
Elia Schito
@elia
Dec 24 2015 16:53
@iliabylich thanks for the appraisal tips
base_module if I understood correctly is the module in which it has been defined initially, but this info needs to be checked against the runtime
Ilya Bylich
@iliabylich
Dec 24 2015 16:55
I see, thanks
Elia Schito
@elia
Dec 24 2015 16:55
as of docs my intention is to document all the $$ properties once I have a firm grasp on them
please send even tiny doc PRs if you notice anything that can be improved (wording, missing docs, inconsistencies, etc.) while/if you peruse the runtime