These are chat archives for opal/opal

2nd
Mar 2017
Mitch VanDuyn
@catmando
Mar 02 2017 05:34
help!
I can't get any opal-rspec stuff to run. used to work fine, but I suspect upgrading gems has broken something.
so I tried to start over, and went here: https://github.com/opal/opal-rspec-rails
and i believe I followed all instructions, but it can neither find the rake task no can it run from the browser via spec-opal
I'm on rails 5, does that matter?
i get routing (can't find route) from browser, and no such task when trying rake
Mitch VanDuyn
@catmando
Mar 02 2017 05:41
when I try to set the config I get this error:
... undefined method `opal_rspec' for #<Rails::Application::Configuration:0x007fc24e329520> (NoMethodError)
Mitch VanDuyn
@catmando
Mar 02 2017 12:35
okay - so that was dumb had opal rspec in test not development, but now i get this:
Uncaught SyntaxError: Invalid regular expression: /*/_spec/: Nothing to repeat
at new RegExp (<anonymous>)
at singleton_class_alloc.TMP_5 [as $new] (regexp.rb:76)
at $QueryStringConfig.$$pattern_regexp [as $pattern_regexp] (opal-rspec-rails-runner.rb:22)
at Opal.modules.opal-rspec-rails-runner (opal-rspec-rails-runner.rb:42)
at Object.Opal.load (runtime.self.js?body=1:1957)
at spec-opal:527
in the console
and the same kind of thing when I run in the console:
bundle exec rake opal:rspec
Object freezing is not supported by Opal
undefined: 5700:in `RegExp': SyntaxError: Invalid regular expression: nothing to repeat
        from undefined: 5700:in `TMP_5'
        from undefined: 128099:in `$$pattern_regexp'
        from undefined: 128131:in ~unknown~
        from undefined: 1957:in `load'
undefined: 54213:in ~unknown~: TypeError: null is not a valid argument for 'in' (evaluating ''textContent' in document.documentElement')
        from undefined: 52667:in `__webpack_require__'
        from undefined: 53143:in ~unknown~
        from undefined: 53253:in ~unknown~
        from undefined: 52667:in `__webpack_require__'
        from undefined: 53005:in ~unknown~
        from undefined: 53118:in ~unknown~
        from undefined: 52667:in `__webpack_require__'
        from undefined: 52777:in ~unknown~
        from undefined: 52853:in ~unknown~
        from undefined: 52667:in `__webpack_require__'
        from undefined: 52730:in ~unknown~
Mitch VanDuyn
@catmando
Mar 02 2017 13:23
same thing in rails 4
Forrest Chang
@fkchang
Mar 02 2017 17:21

@/all I'm thinking we need some "official Opal way of having toll free bridged JS objects as limited hashes" - I've been mulling the idea for a while, but my latest go at wrapping indexedDB in opal kind of puts me there -- thought hyper-react params (props), getting converted to opal Hashes shows some of the pain. Basically, nearly every interaction w/a JS API, will typically return (and take as parameters) JS objects, I know in various places we are smart about converting, say jquery's ajax functions where response.json gets converted, but there's too much manual doing that can get consistent, in response, you also need to remember to add to_n to Opal Hashes you pass in to JS apis too. I think there is a 90% solution out there where we don't have to convert, but pretty much treat a JS object as a limited hash in opal, w/o having to do conversions. My 2 day ago pain came from I was storing json data in an indexedb field, and I had to search that, I'm dealing with 1000's of entries, so I don't want to have a loop that has to convert things, so I wrote all the filtering stuff in JS, which as we all know is decidely less pleasurable than writing opal, and call that via x-strings.

Possibly native wrapping or .JS could address it (though I can't use .JS coz the app I'm doing it on is 0.8), but it still feels a bit piecemeal -- i.e. developers have to remember to do it. Ultimately I think this affects uptake of opal, where people will think, "Hey, if I have to remember to convert to and from (and sometimes that's rather complex, I get that problem with > 1 level deep nested objects in hyper-react all the time), then I may as well just do it all in JS". May we have a new class JsObject, maybe introduce a literal that thing we can use to define them? I dunno

On the implementation side, @elia @meh @iliabylich, @jeremyevans @jgaskins may have some ideas, I suspect I'm not alone in feeling this "impedance mismatch with the primary way of moving data in JS", @catmando and some of the other hyper-react folks might have some insights -- there are solutions, but they can be intricate and hard to debug, If I could just handle nested js objects as if they were Opal Hash (a likes) w/o converting, that would pretty much do it.

Sorry to ramble. Want to get this thought out while the pain is still fresh

meh.
@meh
Mar 02 2017 17:23
fkchang, the problem is they're plain objects, we can't add methods to them, so they can't behave like hashes in any way
Forrest Chang
@fkchang
Mar 02 2017 17:28
@meh we can't add to the proto? (or there is no proto)
meh.
@meh
Mar 02 2017 17:29
fkchang, it depends on how the code of the library deals with the object
Forrest Chang
@fkchang
Mar 02 2017 17:30
off the cuff, I think, the 80% need is to support [] and []= from the opal side on the js object w/o converting it. Is that possible, and what ramifications would it have on libs?
that and iteration, keys() and values()
meh.
@meh
Mar 02 2017 17:35
fkchang, if we add methods to the prototype then EVERY object will have that method, it would be the same as adding the method to BasicObject
the best solution is to just use .JS
fkchang, and even if it were, if for some reason the underlying code uses a for loop instead of Object.* the method will show up
Forrest Chang
@fkchang
Mar 02 2017 17:42
@meh what if we clone the proto and make a new one? Got a quick .JS alike functionality for older opal's?
meh.
@meh
Mar 02 2017 17:43
fkchang, it wouldn't be an object, if the underlying code checks the passed value is a raw object it won't work
there's just no way to work around that at runtime as far as I know
Forrest Chang
@fkchang
Mar 02 2017 17:46
hmm, so maybe we make something that takes a block, in the block, we wrap the js object with something that translates the hash funtionality and sets the values on the js object? A little weird, but it would meet the need to be able to manipulate like a Hash, but leave it a pure JS object
I'll have to play w/that idea
of course, this forces us to use, and remember to use blocks when dealing w/JS objects, but it might help, though .JS might meet most of that
too bad I can't use .JS on most of my stuff
meh.
@meh
Mar 02 2017 17:48
fkchang, that's effectively the same as calling #to_n at the end, you still have to change your code
and remember to do it
Forrest Chang
@fkchang
Mar 02 2017 18:40
u do have to remember, but to_n only works on creating, but not accessing
and I can't use .JS on the project that needs it right now
meh.
@meh
Mar 02 2017 18:40
fkchang, don't you just need to wrap the incoming object in another Hash?
I don't remember what stuff was in 0.8
Forrest Chang
@fkchang
Mar 02 2017 18:44
My case atm is that that I store an array of JS objects in an indexedDB column (or equivalent of such), I need to filter out by certain values in the js objects, so I realize as I'm describing this, that my block approach doesn't work for this very situation, mabye I can universally wrap recursively. Anyways, I had to write JS code to be able to filter out the stuff. JS makes me cry sometimes
Jamie Gaskins
@jgaskins
Mar 02 2017 20:47

@fkchang If you're storing Ruby objects in IDB, and you know the type of object it was in Ruby, for example a Person, you can do:

# people is the raw JS array pulled from IDB
people.map do |js_person|
  `Object.assign(#{Person.allocate}, js_person)`
end

This should give you the object exactly as it existed before you persisted it to IDB. This may also include the object_id, but you might be able to strip that out.

Forrest Chang
@fkchang
Mar 02 2017 21:14
@jgaskins that's an interesting piece of info, I had decided to store it as the native js array of objects I pulled over opal-jquery ajax request, instead of the converted response.json, so maybe this could be used instead of doing it all in js
Jamie Gaskins
@jgaskins
Mar 02 2017 21:19
I think I've got some code on my machine at home to wrap the basics of IDB in Ruby, but I stopped messing with it once I realized it stripped all the proto/constructor metadata from the objects. I suppose it's not the end of the world. I'll see if I can post a Bowser PR for it tonight.
Forrest Chang
@fkchang
Mar 02 2017 21:27
yeah, I figure it's still best to just store js objects in indexdb, i.e. json compatible data
but I'd be curious as to your indexedDB wrapper details
Mitch VanDuyn
@catmando
Mar 02 2017 23:38
@/all has anybody got opal-rspec-rails working??? I can't even get a basic thing to go... keeps saying Uncaught SyntaxError: Invalid regular expression: /*/_spec/: Nothing to repeat
at new RegExp (<anonymous>)
in the console.
have tried everything...