These are chat archives for opal/opal

May 2015
Vais Salikhov
May 19 2015 13:54
@elia got it
didn't know @jeremyevans 's face would be such a good marketing draw ;)
Forrest Chang
May 19 2015 18:01
@ylluminate I'd love to hear more details on your successes, you've made references to them in irc, here and some other places (or so I believe seeing them). A blog post or 3 would make good material for the opalist (hope @jaredcwhite doesn't mind me pimping that) for the greater opal publicity
related @AstonJ suggested something about a publicity committee or similar? We should definitely do that since I think we have enough "highly enthused" ppl here. Maybe merging w/volt's committee is the thing to do?
Elia Schito
May 19 2015 18:04
@ylluminate any way to see it without logging into fb?
Jared White
May 19 2015 18:28
@jeremyevans What about hash syntax with the proposed .JS syntax? Aka some object.JS.somemethod({foo: "bar"}) -- I'm wondering if that passes on a regular JS hash-style object to the method or an Opal hash which wouldn't be compatible.
Jeremy Evans
May 19 2015 18:32
@jaredcwhite I assume that would pass the ruby/opal hash, you'd have to use some object.JS.somemethod({foo: "bar"}.to_n) to pass the javascript object
May 19 2015 18:32
jeremyevans, you should probably insert a Native.try_convert
when calling a method with JS
Jeremy Evans
May 19 2015 18:33
@meh doesn't that require loading native from the stdlib, which the runtime can't depend on?
May 19 2015 18:34
jeremyevans, becomes simple when it's an option
jeremyevans, that's also why I'd go with the disable by default
I'd rather keep the standard semantics with the default options, and not everyone needs that kind of stuff in their code
but we do need at least per-gem options
per-file would be good too
basically I'm all for this thing if it seamlessly uses Native as well, and it's disabled by default
it's a nice ergonomic thing when you're dealing with native stuff, i.e. porting something or writing a wrapper
but when writing Opal code you should never, ever, access JS
it should all be hidden behind wrappers
if you're writing js in your application you're doing something wrong unless it's for optimization
Jeremy Evans
May 19 2015 18:40
The main reason for adding this is so I can easily write ruby instead of javascript, with minimal invasion. I would like to be able to incrementally replace javascript with ruby, which is really ugly if you have to manually wrap and unwrap javascript objects everywhere.
I think per-file options would be possible using magic comments, but I can't think of another good way to do so
Really, if you should never, ever, access JS, opal should be implicitly converting all function arguments to ruby objects, and converting all function return values to javascript objects if they weren't called by ruby code. That would probably slow things down quite a bit, though.
Jeremy Evans
May 19 2015 18:46
I have a more pragmatic viewpoint. If you are running on a javascript runtime, you'll eventually need to deal with javascript objects, so you might as well make that as easy as possible.
Elia Schito
May 19 2015 18:53
I had a hard time too trying to deal with native libs
May 19 2015 19:02
jeremyevans, the point is JS is treated like FFI
we're running on it, but that doesn't mean it should be seamless, and it doesn't work
when you need to go down to raw JS is to use APIs written in it
and that's where writing a Ruby-esque wrapper comes in
you do it, release it, and everyone's happier
Christian Käser
May 19 2015 20:11
Just some experiment to get opal running with electron:
require 'opal'
require 'opal-electron/app'
require 'opal-electron/browser_window'
require 'opal-electron/crash_reporter'
require 'opal-electron/process'


App::on 'window-all-closed' do
  App::quit if Process::platform != 'darwin'

App::on 'ready' do
  main_window = 800, height: 600)
  main_window.load_url_relative 'index.html'
All those requires are pretty simple
(I just wrapped everything I needed in ruby classes)
AstonJ @AstonJ Want to join the strategies team?
May 19 2015 23:07

Hey @/all We have just started a new team for anyone interested in helping out with the some of the behind-the-scenes stuff, marketing and promotion of the Opal and Volt projects (in fact any Opal related project).

Some of the things we'll cover are screencasts, blog posts, docs and demo apps!

If you fancy being on the team, please let me know and I'll add you to the room! :-)