Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
Elia Schito
question: is there a way to tell GCC not to touch some names?
Julian Scheid
yes, with an externs file
that's how I have my test case working
it has lots of lines that look like this:
Opal.modules["corelib/module"].$class_variable_get = function() {};
it works -- it's just a PITA
and it only works for my case, I have lines like that for the code I'm compiling as well
Elia Schito
hmm, asking because we have the list of method calls for each file, and maybe an externs file can be generated
elia @elia is looking up the docs
Julian Scheid
hmm interesting thought... but why are you opposed to changing . to [] instead? the way I see it: people who care about file size will run the result through a compressor anyway, and that will turn it back into .s (or do something even smarter when it's GCC)
or is there another reason besides file size why you're not keen to make that change?
and it'll be a simpler system with fewer moving parts that way
Elia Schito
Not opposed on principle, except for readability of the generated code (which is of course not a strong argument), I just need to be sure there's no hidden reason not to that I'm forgetting
right now I'm experimenting with uglily to see how it would handle it
Julian Scheid
okie dokie
I gotta run but I'll pop back in tomorrow after doing some experiments with mid_to_jsid
but just to whet your appetite...
the lib I'm compiling with opal ends up as a 2 MB JS file
uglify gets it down to 1.6 MB
closure compiler down to 1 MB ... and that's without any DCE
maybe I'll have some performance benchmarks tomorrow as well
Elia Schito
πŸ‘πŸ‘πŸ‘ great stuff, see ya
Barrie Hadfield
@jscheid @elia :clap: :thumbsup:
Bernhard Weichel

Hi I need an advice: I initialize the contoller of my app with

Document.ready.then do |ready|
  uicontroller = Controller.new

In order to have a global access to the Controller -instance I assign it to window.zupfnoter. The Controller produces SVG code in a worker which returns the SVG as a string. I would like to declare handlers in this string. I figured out the JS source code requird in the SVG code to access a method of an object stored in an instance variable of my controller:

      onclick = %Q{onclick="zupfnoter.tune_preview_printer.$_clickabcnote(evt, '#{id}')"}
          #{@root}.out_svg('<rect ' + #{onclick}' ...);

which eventually produces

<rect onclick="zupfnoter.tune_preview_printer.$_clickabcnote(evt, '_note_436_438_')"></rect>

even if if works, I am not sure if this is the most elegant and robust approach:

  1. It depends on the global variable (zupfnoter). I would prefer to access the instance of the controller via something like Opal.top.uicontrollersuch that I do not need the global variable.

  2. It depends on the internals of the opal compiler. I would like to get the javascript name of the handler without knowledge of the internals how Ruby code is converted to javascript.

it should be something like

 onclick = %Q{onclick="#{JS.methodcall(uicontroller.tune_preview_printer._clickabcnote)}(evt, '#{id}')"}
Bernhard Weichel

I found out that if I use

Document.ready.then do |ready|
  @uicontroller = Controller.new

I can subsequently find my controller instance by


but it still depends on internal knowlege. ...

Elia Schito
@bwl21 have you tried attaching the event via DOM after the SVG has been attached to the document? I'm very familiar with events inside SVGs though, so I'm not really sure if it requires some special stuff.
Anyway I don't think you can avoid using globals easliy otherwise, Opal.top.… is still a global as you pointed out, so it would be any Opal class.
Bernhard Weichel
@elia attaching the events via DOM seems to be the common approach. So this is what I am currently doing. But I have several hundred events to attach. As it blocks the UI thread, it is a performance issue. Attaching all events takes about 300 msec. I also think that it creates lots of closures consuming memory. Performance is the main reason that I want to attach the events in the SVG string. So I created a constant for the string "Opal.top.uicontroller".
Bernhard Weichel
@elia you made me think twice ... I now attach the events via DOM again, but only the ones user moves the mouse on ( in a mouseover event). So I can reuse all of my code, SVG is smaller and performance is ok. I do not have to attach multiple events (mousdown, mouseup, mousemove) in the SVG string. Thanks. I was on the wrong way (like driving from Berlin to Brusses via New York :-) And I can still use the svg.draggable.js (https://github.com/wout/svg.draggable.js) library without inventing it new.
Elia Schito
@bwl21 great to hear that! πŸ‘πŸ‘πŸ‘
Elia Schito

@/all I'd like to thank @catmando for providing stickers for the codemotion conference that's being held in milan this week :tada: :tada: :tada: :tada: :tada: Thanks Mitch!!!

If you're participating to a conference and want some stickers to promote Opal ping me and we'll try to provide you some

Frederic ZINGG
Guillaume Grossetie
Tobias Sandelius
I've been programming in multiple languages for many, many, years and Ruby have always been my go to cause I really love both the syntax and community. I've looked at Opal from a distance for some time but recently gave it a try and I must say, GOOD JOB everyone involved!
Elia Schito
Mitch VanDuyn
@sandelius these guys are great. We have a large production app (www.catprint.com) that thanks to opal is 100% RUBY. The UI part is about 17K of opal code, using the hyperstack (www.hyperstack.org) framework.
In practice Opal == MRI Ruby, very reliable and solid.
Marko Kauzlaric
Good afternoon gents!
With do you think about Opal and building Client side with it? And what do you recommend.
I think Opal missed the momentum.
Mitch VanDuyn
@MarkoKauzlaric as noted directly above its great. Rock solid, and increases developer productivity in several ways. 1) Ruby is simply easier to read, and more expressive. In general we find it take about 4 times as much JS code to achieve the same functionality. 2) If you are using Ruby server side, the not having to context switch saves more brain power than people think. 3) It allows my developers to think about the whole system (i.e. how does the whole function work from user experience, to server side issues) rather isolate programmers into backend and frontend.
Adrian Madrid
@MarkoKauzlaric you should definitely check out https://hyperstack.org/
there are a lot of other opal frameworks out there but I don’t believe any is as actively developed as HS
ryanprior I used Opal for a project where I already had a software library in Ruby, and wanted to create a web app to make it easier to consume directly. It would not have been a huge effort to reimplement the library in Javascript, or to put up a Ruby backend server and have the front-end written in Javascript to consume it, but completing the project with Opal and the Inesita framework only took a couple days, including learning time having never used either before (but lots of Ruby otherwise.) If I were in a similar situation again, I would not hesitate to give Inesita another crack.
ryanprior The completed web app in question is here: https://cyberark.github.io/conjur-policy-generator/
The source code for the web app is here: https://github.com/cyberark/conjur-policy-generator/blob/master/web
I chose Inesita in particular because it's lightweight, includes its own tools, doesn't assume you're using Rails, and has nice approachable documentation.
Forrest Chang
@MarkoKauzlaric the apps we have in production with opal use opal-jquery, and lissio - I've played around a lot with previous versions of hyperstack, just no production apps, so next big opal app I'll write I'll use that --- if not for the huge brain/code share behind react, I'd probably use @jgaskins 's clearwater
for similar reasons to @matrixbot in that it's lean and doesn't require rails and I respect @jgaskins tech approaches that project (and in general)