<e_dub>
hey elia, wanted to ask you a ? . Do you think it would be possible to wrap enough of node to implement the full ruby standard lib, etc ? Or, really, just enough of it to get most gems working or something
<elia>
e_dub, I think mostly yes, maybe not the full stdlib/corelib but enough to get most gem to work
<elia>
The one thing I'd really like to on opal-node is rubygems
<e_dub>
me 2
<elia>
only problem is that ruby corelib is all sync, so it kinda defeats node paradigm…
<elia>
readSync, execSync, etc. are not the best sol on node
<e_dub>
yeah, then you just have a singlethreaded runtime
<e_dub>
but still, if you could use either, depending on need, that would be cool
<e_dub>
i need to head in to office, be back on later
e_dub has quit [Quit: It's a hard knock life]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #opal
DouweM has joined #opal
elia has quit [Read error: Connection reset by peer]
elia has joined #opal
DrShoggoth has joined #opal
kludge` has quit [Disconnected by services]
kludge` has joined #opal
DrShoggoth has quit [Quit: Leaving]
DrShoggoth has joined #opal
skofo has joined #opal
ryanstout has joined #opal
<ryanstout>
are there any docs on the promises in opal?
tils has quit [Ping timeout: 246 seconds]
<ryanstout>
so if I wanted to use opal's promises in MRI as well, any suggestions on the best way to go about that?
vasilyes has joined #opal
fkchang has joined #opal
elia has quit [Ping timeout: 264 seconds]
<fkchang>
ryanstout: I think all promises docs are either the specs, or gists that meh' has put up
<fkchang>
one of my hopes is that as opal grows, we'll create eventd safe gems that can run on MRI
vasilyes has quit [K-Lined]
<ryanstout>
but it's require conflicts
<ryanstout>
but I'm not sure if anyone else will have issues
<ryanstout>
I just switched to meh's for now and require it on the mri side
<ryanstout>
yea
<ryanstout>
seems like promises makes more since as a gem for opal, but thats just me
homkins has joined #opal
homkins has quit [Remote host closed the connection]
sergebublik has joined #opal
meh` has joined #opal
<adambeynon>
ryanstout: I have been requiring it manually on the mri side, but only for playing around
<adambeynon>
I want to use it eventually for some model code that runs on both client and server
<adambeynon>
a gem is probably a good idea..
<adambeynon>
and just improve the way we import existing gems into the opal workflow
<ryanstout>
adambeynon: yea, thats what I'm using it for
e_dub has joined #opal
<adambeynon>
ryanstout: one thought I had was a hook into our current require system. If a require cannot be found, then search the ruby load path, and use that one
<ryanstout>
would it make since to just merge the two load paths into one somehow?
<ryanstout>
so opal works with rubygems out of the box
sergebublik has quit [K-Lined]
<ryanstout>
just throwing that out, you know the details way better
<adambeynon>
ryanstout: Im not sure if they would still apply - but I remeber a couple of issues
<adambeynon>
one was that our stdlib isnt quite a clone of mri
<adambeynon>
a few subtle differences
<adambeynon>
like no mutexes
<adambeynon>
also, opal specific code was getting autloaded by bundler
<adambeynon>
which contains lots of x-strings
<adambeynon>
which ended up getting evaled
<adambeynon>
we could overcome this by having some if check
<ryanstout>
humm, yea that is an issue
<ryanstout>
yea, you could do :platform in bundler
<ryanstout>
maybe
<ryanstout>
it gets ugly though
<adambeynon>
infact, a vienna fork im using now is actually running alongside rails on the server, and i do some platform checks to only require specific files on the server
<ryanstout>
interesting
<adambeynon>
ryanstout: what we could actully do, is to wrap all require lines in the main file under a "if RUBY_ENGINE == 'opal'" check
<adambeynon>
so even if it is loaded, nothing actually gets required after it
<ryanstout>
that sounds like a good solution
<ryanstout>
I think as time goes on, requiring real gems from opal is going to get more common
<adambeynon>
yeah, true. although, that promises lib you linked to isnt as nice as the one meh wrote, so sometimes opal specific libs might also be a good idea
<adambeynon>
but, yes, we need a better intergration to real ruby libs
<adambeynon>
I suppose we could have a whiltelist of custom files, e.g. take these files as a priority, otherwise go back to the mri load path
<adambeynon>
just to ensure our version of racc/parser.rb gets loaded instead of the mri one, for example
<ryanstout>
yea
DrShoggoth has quit [Quit: Leaving]
<ryanstout>
is there a bunch of files that have custom opal versions?
<adambeynon>
ryanstout: I cant remeber of the top of my head. from the stdlib maybe 1 or 2
<adambeynon>
one used mutex stuff, and racc/parse.rb uses a try/catch loop which wasnt supported
<adambeynon>
well, it still isnt, but it could be
<adambeynon>
oh yeah, and strscn.rb - that is mostly implemented in C, so ours is all javascript
<adambeynon>
just another thought, it would introduce a breaking change: require 'opal' for getting the corelib/runtime would need a new require name
<ryanstout>
yea
<ryanstout>
at least for me thats not a big deal
<adambeynon>
ryanstout: we haven't hit 1.0.0 yet, so breaking changes aren't a huge deal
<adambeynon>
maybe I should open a github issue for this - seems like it would need a lot of discussion and will affect lots of gems
<adambeynon>
ryanstout: one thing that is really ugly now, is that we have to maintain an opal/ and lib/ dir for every ruby gem
<adambeynon>
kinda ugly
<ryanstout>
yea, that really threw me when I first started
<ryanstout>
seems like just moving stuff into gems and then doing the conditional requires could simplify it all and make it work with ruby gems out of the box
<adambeynon>
ryanstout: yep. just tried it on a git checkout, and this is all that I needed: