Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Elia Schito
@elia
that's how the property is set, and for good reason, so it's a no go I think
Julian Scheid
@jscheid
what is a no go?
Elia Schito
@elia
switching it to proto[jsid] = body
Julian Scheid
@jscheid
ah no that's not necessary
it's effectively the same
Elia Schito
@elia
GCC can see trhu that?
Julian Scheid
@jscheid
good question... I'm not sure now, but it doesn't really have to. the way it works is this:
let's say proto is foo and jsid is bar
when it sees foo['bar'] it leaves bar alone, and the expression will work regardless of how foo.bar was set (with foo[bar] or with defineProperty)
but when it sees foo.bar, it will mangle bar into something short, maybe into foo.y
and then it won't match anymore
does that make sense?
so at least in a first step, we don't have to change anything in how Opal.defn works
only in how the rest of the code accesses properties
Elia Schito
@elia
oh I see, it's the reverse of what I thought, I was believing that you wanted to allow GCC to optimize method names, but really you want to prevent them from being touched, right?
Julian Scheid
@jscheid
long term I think it would be great if we could let GCC optimize that stuff
the methods names would be nice if they were a little shorter, but the killer features of course is dead code elimination
I just think that's quite a bit of work, and so in the short term I'm suggesting to do it the other way around, as a quick fix that lets people use GCC with ADVANCED_OPTIMIZATIONS
Elia Schito
@elia
question: is there a way to tell GCC not to touch some names?
Julian Scheid
@jscheid
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
obviously
Elia Schito
@elia
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
@jscheid
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
@elia
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
@jscheid
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
:wave:
Elia Schito
@elia
👍👍👍 great stuff, see ya
Barrie Hadfield
@barriehadfield
@jscheid @elia :clap: :thumbsup:
Bernhard Weichel
@bwl21

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

Document.ready.then do |ready|
  uicontroller = Controller.new
  %x{
     window.zupfnoter=#{uicontroller};
  }
end

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}')"}
      %x{
          #{@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
@bwl21

I found out that if I use

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

I can subsequently find my controller instance by

Opal.top.uicontroller

but it still depends on internal knowlege. ...

Elia Schito
@elia
@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
@bwl21
@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
@bwl21
@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
@elia
@bwl21 great to hear that! 👍👍👍