These are chat archives for opal/opal

5th
Jan 2016
Yann Stepienik
@azukaar
Jan 05 2016 15:02
Hello ! okay so I have a question that might seems "dumb" but I'm really not sure about it. Basically, when it comes about using tiers libs, I see some people using inline JS files, or Opal.Builder. But, is there a clean "standard" way of using some ? I mean, something like, directly lookup in the directory where "gem" insall my lib when I do something like "gem install opal-juqery"
Ilya Bylich
@iliabylich
Jan 05 2016 15:04
@azukaar Opal.use_gem 'gem_name'?
But I'm pretty sure that opal-jquery does it manually when you require it in MRI-world
Yann Stepienik
@azukaar
Jan 05 2016 15:06
Strange because basically I have 'requiered' it, but when I compile the file it tells me it can't find the file under gems/opal/lib/blablabal which is true because the files are located in gem/
Ilya Bylich
@iliabylich
Jan 05 2016 15:09
How do you compile it? Are you using sprockets or opal -c your_file.rb?
Yann Stepienik
@azukaar
Jan 05 2016 15:09
opal myfile.rb
It seems to work when I use use_gem (if I add the -c option to the command)
But still nothing with require
Ilya Bylich
@iliabylich
Jan 05 2016 15:12
Take a look at opal -h :smile: There's an option --gem GEM_NAME for adding a gem to Opal's load path
Yann Stepienik
@azukaar
Jan 05 2016 15:12
So if i use --gem **, i'll be able to require ?
There's also a -I option I might try it out
Ilya Bylich
@iliabylich
Jan 05 2016 16:44
@elia Are you around?
Elia Schito
@elia
Jan 05 2016 16:44
am now :), what's up?
elia @elia is catching up
Ilya Bylich
@iliabylich
Jan 05 2016 16:45
Could you please check #1271?
I don't understand what's going on. There's a spec that can't pass, but it's green on CI
Elia Schito
@elia
Jan 05 2016 16:47
which one?
Elia Schito
@elia
Jan 05 2016 16:49
Fails here too
Ilya Bylich
@iliabylich
Jan 05 2016 16:49
I remember there was a similar situation with a spec that was modifying Kernel and test suite was randomly passing (depending on the test order). But in this case everything is simple
Alexandr Smirnov
@JelF
Jan 05 2016 16:50
ci configuration is not perfect, for reasons i can't understand it optimizes speed, not coverage
Elia Schito
@elia
Jan 05 2016 16:50
yeah, also the running of spec/opal has been separated from that of spec/rubyspec
Ilya Bylich
@iliabylich
Jan 05 2016 16:51
@JelF It's not really about coverage, it's about build status. Current build seems to be broken :smile:
Elia Schito
@elia
Jan 05 2016 16:52
@JelF the attempt is to optimize for both, having faster feedback is valuable, but correctness is more important of course
Alexandr Smirnov
@JelF
Jan 05 2016 16:52
@iliabylich can you run it locally with 1.9.3?
Elia Schito
@elia
Jan 05 2016 16:53
brb
Ilya Bylich
@iliabylich
Jan 05 2016 16:53
@JelF need to install 1.9.3. I can do it, but what should I see?
Alexandr Smirnov
@JelF
Jan 05 2016 16:54
@elia i think it should run pure rake for any ruby version, and platform-depended specs for each platform and important ruby versions
it could prevent any possible misconfiguration, which is valuable too
but you can have your own reasons
as far as i see, there is zero coverage for OSX cli, for example
Ilya Bylich
@iliabylich
Jan 05 2016 16:56
@JelF Can't even run specs on 1.9.3
Elia Schito
@elia
Jan 05 2016 16:56
the travis config is older than their OSX support
Ilya Bylich
@iliabylich
Jan 05 2016 16:57
But 1.9.3 is deprecated, that's expected
Alexandr Smirnov
@JelF
Jan 05 2016 16:57
rejecting PR without coverage in travis is good
:)
travis marks 1.9.3 check as green
Elia Schito
@elia
Jan 05 2016 16:58
1.9.3 support needs to be fixed and I'll add to add OSX to the matrix
    - rvm: 1.9.3
      env: RUN=rspec
indeed 1.9.3 is still supposed to be covered
Alexandr Smirnov
@JelF
Jan 05 2016 16:59
if travis marks ruby-version green, it equals that this ruby version is supported
i'll try 1.9.3
Elia Schito
@elia
Jan 05 2016 17:00
@JelF would be great to see a PR with what you think it's missing in travis
Alexandr Smirnov
@JelF
Jan 05 2016 17:00
@elia it would greatly increase testing time :)
Elia Schito
@elia
Jan 05 2016 17:00
@iliabylich as of that spec seems to be passing when the whole suite is ran
@JelF it's ok to increase it as long as it's the minimum increase required ;)
Alexandr Smirnov
@JelF
Jan 05 2016 17:01
my idea is not about the minimum
it is about the maximum
Elia Schito
@elia
Jan 05 2016 17:04
as long as it maximises coverage and not time that's ok, but of course discussing an actual diff would be much better
Alexandr Smirnov
@JelF
Jan 05 2016 17:05
i think there is no reason to make PR for this, because it would be rejected
i understand your position
it is ok to have your position
Elia Schito
@elia
Jan 05 2016 17:08
I'm still interested in improving reliability and I see value in what you say, my intention is to pick some parts (e.g. that's what I did adding coveralls to the project)
Alexandr Smirnov
@JelF
Jan 05 2016 17:10
i started some work on coverage improvment and somewhere i'll finish it
Elia Schito
@elia
Jan 05 2016 17:10
:)
:+1:
Alexandr Smirnov
@JelF
Jan 05 2016 17:13
coverage improvement seems to be enough in most cases, but sometimes (i met this only once, when in 2.2 ruby changed ** semantics) the failure could be anywhere and you could not catch it without checking everything
in case i descripted there should be full <2.2 and full >=2.2 runs to detect it anywhere
it could be managed manualy, by reading changelogs and whriting travis rules, but test are for automating
Alexandr Smirnov
@JelF
Jan 05 2016 17:21
i really don't understand, why ruby does not use merge { raise } pattern in cases like [foo: bar, **{ foo: baz }]
Elia Schito
@elia
Jan 05 2016 17:23
@iliabylich ok, the bug was introduced in f1c7e73e77346b282416c7ea9ada0373d4917375
which is master now
I'll try to fix it, but if I fail to to it promptly I'll just revert it
Martin Becker
@Thermatix
Jan 05 2016 17:32
@JelF ehhhhh, that looks super ugly
@JelF why would you want to do that?
Ilya Bylich
@iliabylich
Jan 05 2016 17:36
@elia How did you find that? (I thought it's related to Opal.add_stubs) In the example that I've pasted in the issue, array doesn't have a method coerce (while there was an explicit call Opal.add_stubs(['$coerce']) in numeric.rb
Alexandr Smirnov
@JelF
Jan 05 2016 17:39
@Thermatix remove moste of RUN= statements from matrix
Elia Schito
@elia
Jan 05 2016 17:47
@iliabylich I see now!
@iliabylich what happens is that method missing stubs are added when the AST contains calls to methods
apparently somewhere there's a call to #coerce done from x-strings
Ilya Bylich
@iliabylich
Jan 05 2016 17:58
Elia Schito
@elia
Jan 05 2016 18:07
:\
Ilya Bylich
@iliabylich
Jan 05 2016 18:35
@elia I think I've found an issue. When new subscriber comes to Opal.stub_subscribers, there's no code that populates it with existing stubs. When Array comes to that subscribers array, there are already some stub methods from previously loaded code (like from Class or Module). And these methods don't come to the Array. I think I'll send a PR soon :smile:
Elia Schito
@elia
Jan 05 2016 18:37
w00t great finding!
Elia Schito
@elia
Jan 05 2016 19:00
@azukaar --gem GEM will do -I on your behalf for all the lib dirs defined in the gemspec of GEM
the same is true for Opal.use_gem of course
Elia Schito
@elia
Jan 05 2016 23:49
@iliabylich @JelF 1.9.3 works fine, the only issue was that tasks/testing.rake uses __dir__