These are chat archives for opal/opal

20th
Apr 2017
Guyren Howe
@gisborne
Apr 20 2017 00:33
Many failings.
Guyren Howe
@gisborne
Apr 20 2017 00:39
I think the quoting is mucking up. Stand by.
Guyren Howe
@gisborne
Apr 20 2017 00:56
Trying now to define a function that returns Opal, by adding return Opal; at the end, I can define the function but when I try to run it, I get "Opal is not defined" on line 2063: Opal.loaded(["corelib/runtime"]);
Guyren Howe
@gisborne
Apr 20 2017 03:22
I don't think this is going to work. Let me put the idea into your heads, though. PLV8 already supports several transpiler options. It would be amazing if you brought this option to Postgres.
Ilya Bylich
@iliabylich
Apr 20 2017 13:01

@gisborne I've changed the code of plv8 a little bit locally and got a plopal PG language (just like plcoffee for coffeescript) that almost works. It looks like:

CREATE EXTENSION plopal;
DO LANGUAGE plopal $$
  foo = %w(f o o).join
  `plv8.elog(INFO, foo)`
$$;

But its performance is really bad. plv8 uses a compiler (coffee-script.js / opal-parser.js) internally when you declare a PG function. It assumes that produced JS has no dependencies, it's true for CoffeScript/LiveScript (plv8 has both of them embedded by default), but not for Opal. Opal is not just a transpiler, it has a runtime and a corelib, both of them must be included into the execution context. Maybe it's possible to optimize it by having 2 separated V8 contexts: one for compiling to js (must have a runtime + corelib + parser inside) and one for js evaluation (requires only runtime + corelib). But atm plv8 doesn't expect an external compiler to have any runtime dependencies. Rewritting seems possible, but it requires a lot of time.

Guyren Howe
@gisborne
Apr 20 2017 14:36
You, my friend, whoever you are, are amazing.