<meh`>
adambeynon, anyway, I fixed event delegation
<meh`>
it should be a lot faster now
<meh`>
and easier to handle
<meh`>
and easier to make it work with IE
<meh`>
adambeynon, https://github.com/meh/gwentoo also if you want to look around a more complex lissio codebase than shekels
fkchang has joined #opal
<adambeynon>
meh`: with the promises you were showing before, do you then wait until the model/page/whatever resolves before you render the new view?
<meh`>
adambeynon, if the page needs to, yes
<meh`>
some pages, like the introduction, are just markdown
<meh`>
so they don't need to wait
<meh`>
in the case of the guild page, it has to wait for remote models and for the images to load
wmnnd has joined #opal
<wmnnd>
Hey there, say I am new to Opal but I want to use it and I'm looking for some best-practice advice, would this be the right place to ask?
<adambeynon>
wmnnd: hi there! yes it is
<adambeynon>
how are you getting on with it?
<wmnnd>
adambeynon: Not very far, actually ;) First I wanted to ask someone with some Opal experience about what I had in mind.
<meh`>
wmnnd, go ahead
<wmnnd>
I am developing a little Sinatra-based application and I was wondering whether I could use Opal's erb capabilities in order to use the same templates that I use for rendering sites on the server for rendering them on the client's machine.
<wmnnd>
I just haven't figured out how to deal with file-based erb templates in Opal.
<meh`>
I think adambeynon does just that in his production stuff
<adambeynon>
wmnnd: yes, I render erb on both sides (using rails as the backend)
<adambeynon>
you can also use haml
<adambeynon>
the todos app uses erb, for an example
<adambeynon>
wmnnd: then to get the erb into opal, you can just require() it
<adambeynon>
All I do is add the rails views path into my sprockets environment, and then I just require() the ones I need
<wmnnd>
adambeynon: Awesome, thank you :-)
ryanstout has joined #opal
marcandre has joined #opal
<wmnnd>
Another thing that I've been wondering is how to best pass data from the server application to Opal. Is there some magical way that Opal provides or do I just use good old JSON?
<meh`>
wmnnd, that depends on what you want to use
<meh`>
bashing from people saying coffeescript is good and cljs is a toy is as much as an ant whining about rain drops, no point in answering back
<meh`>
they just have a warped perspective
<meh`>
but I personally feel the Rails community is pure cancer, so whatever
<fkchang>
ryanstout: u can't make everyone happy. My premise for the rubyconf talk was "if ruby makes you happy, then opal will" which I think is true. Ruby doesn't make eveyryone happy. Ulitmately I think some good public examples would go far to winning over people. Things I'd like to do, write a chat server in opal-sinatra (doesn't exist yet, was going to do that), to address the "I made a node.js process that my Rails app talks to coz I
<fkchang>
wanted to do chat/async io, etc.". I think something like lissio w/reactive, or your framework would be a good "build something that you'd normally have to use ember for, but with a much nicer DSL, and cleaner code (on the cleaner code example, we did an overview of some code over here wher I thought to myself, that would really hard to have such clean code reuse in JS or CS)", and lastly when I get an opal-inspector that is a simple
<fkchang>
plugin to your app, I think that would be a good stuff -- I'm hoping to lift some lisp machine stuff into that most ppl will never have seen before (more ppl have seen smalltalk browser stuff, IMO)
<fkchang>
oh, one more thing, I'm interested in, a really high level way to write apps w/little code. RubyTk is my mental mode, while RubyTk and and TclTk in general shows their age, the clarity and conciseness of the code is tough to match, and it meets my mental notion that the beauty of ruby is that you clearly express your intention and it runs as code quite well
<ryanstout>
fkchang: I've never used Tk, what is it?
<wmnnd>
fkchang: Have you taken a look at Qt? I haven't used it with Ruby (but there seem to be bindings for it) but Qt is certainly as good as it gets when it comes to OOP GUI frameworks.
<fkchang>
Tk was the windowing system originally for Tcl, to TclTk was original binding. I got huge mileage out of Perl/Tk and RubyTk
<fkchang>
wmnnd: I've seen Qt, and have pretty much coded in most of the big gui frameworks, Gtk, Qt, Swing, raw Xwindows, Xtk, Motif, etc... The point with TK is it was simple and clear (so naturally it's not as flexible or capable as the other ones I mentioned) but it did 80% of what you liked super easy.
<fkchang>
ryanstout: I dont' have access to the code I've written before, so I'm trying to find a an example I like that shows what I mean, in lieu of that I could just write a gist with sort of the idea I'm going for
<ryanstout>
no worries
<ryanstout>
I can just google
<fkchang>
I think I'll do that, as my notion is RubyTk inspired, rather than RubyTk
<ryanstout>
I haven't done much desktop programming though
<fkchang>
ryanstout: thx, very RubyTk inspired. The point is at this leve, not html, no css, just what, and what it does, sane defaults w/reasonable amount of customization. That's the level you think at for apps dev, you should stay at the level, rather than constantlly dive into html, css, rabit holes, IMO
<meh`>
fkchang, changed your mind about lissio?
<fkchang>
meh`: no, I was going to build that on top of lissio, I think
adambeynon has quit [Ping timeout: 240 seconds]
<ryanstout>
yea
<ryanstout>
so you're talking about using something like that for web app development?
<fkchang>
meh`: or so I think
<fkchang>
ryanst
<fkchang>
ryanstout: yeah
<meh`>
a Lissio::Component::Layout
<meh`>
sounds fun
<ryanstout>
I think thats a good idea, but it seems like every framework that takes over the rendering completely like that doesn't get very far for some reason. Like sprout core never took off, but once ember switched to handlebars, it did
<ryanstout>
its interesting though
<fkchang>
it kind of counts on have set of components that is useable. ExtJS is basically that but way uglier and more complex. I'm thinking the 80/20 -- do 80% of what everyone needs, but super simply w/sane defaults. ExtJS is every possibility, every capability, and all that ugliness exposed to the user, reminds me of J2EE in that way "makes impossible tasks possible, makes easy tasks really hard" -- u can quote me on that
<ryanstout>
looks like you're making good progress
<ryanstout>
any docs on lissio?
<meh`>
other than the readme, not yet
<meh`>
still working out on some APIs
<fkchang>
ryanstout: I think sproutcore's issue was 2 fold 1) different paradigm 2) too much to learn. I remember when it came out, and I completely ate up the description. Then I looked at the code, and realized I'd have to learn a lot, and dropped it after monkeying around w/some examples. the point of "opal-tk" is raw simplicity
<meh`>
ryanstout, but there's a lot of example code
<meh`>
with shekels and gwentoo
<ryanstout>
fkchang: yea, I think frameworks are weird, because you can't introduce too much at once or it won't take off
<ryanstout>
but you have to introduce enough to "wow" people somehow
<ryanstout>
so its weird, hehe
<meh`>
it's still under heavy development, so no point in adding outdated docs :P
<ryanstout>
meh`: yea.. I was just trying to get a feel for it. I'll check out the code
<meh`>
also more standard components are coming
<meh`>
a friend is working on autocomplete like typeahead
<meh`>
there are already a few useful ones
<meh`>
and now that we have browserstack
<meh`>
stability should get a lot better in the next few months
<meh`>
for opal-browser that is
<meh`>
and every time I read jQuery's source code I get nightmares
<fkchang>
ryanstout: Re: taking over rendering, it's what ExtJs does. The key thing is that ExtJS does pretty everything you need it to do. All the other non "complete gui system on top of js/html" don't, and you have to mix and match stuff or write it your self. The idea for opal-tk is that you get 80% out of the box, and the 20% you don't you could make yourself fairly easily. See how elia: easily subclassed elements in his rubyTk example.
<meh`>
and I just endup doing my own thing
<adambeynon_>
with sproutcore, it seemed to me as too much at once. emberjs on the otherhand - they kept the html as views thing going, and its a lot more usable + popular
<ryanstout>
adambeynon_: yea, I could be wrong, but I think html as views is something a lot of people want
<meh`>
eww html
<meh`>
eww css
<meh`>
I can never live without paggio again
<adambeynon_>
ryanstout: absolutely - there is room for templating in there, be that paggio/haml.erb
<adambeynon_>
or even string interpolation
<adambeynon_>
ryanstout: did you figure out that parsing issue?
<ryanstout>
adambeynon_: no, but I just put it on the back burner
<ryanstout>
adambeynon_: it might be related to that rltk gem I was using
<meh`>
fkchang, that's exactly my plan for lissio
<ryanstout>
so I might try in another tool
<meh`>
but it's a long way
<meh`>
especially when I'm alone doing it
<fkchang>
adambeynon_: on the web u'r always going to have to deal w/markup at some level, my hope is to be done with it at the app level, where possible. I'd prefer to deal with it at lower level via components, which is one of the reasons why lissio appeals to me. The key to success is to have enough, and good enough std components that you can do 80% of what you want out of the box
<meh`>
fkchang, if you want to work on a layout component, you have all my support
<fkchang>
meh`: well, at this rate, maybe "opal-tk" is just a light wrapper on lissio
<adambeynon_>
fkchang: true, but my concern is on the size of the target audience
<adambeynon_>
e.g. ember.js users vs. sproutcore users
<meh`>
fkchang, yeah, I'd rather that and have standard components worked inside lissio
<ryanstout>
fkchang: a lot of web app's the roles of designer and dev are separated and designers already know css/html and aren't as likely to learn something new, imho
<fkchang>
adambeynon_: For the mass adoption of web users, using the std tools (html, css, js) has it's appeals. I think if "opal-tk" actually works out where you can write reasonable apps in a fraction of the code, and all in ruby, would drive adoption on it's own.
<meh`>
yeah, I'm working on all of this because it makes my life easier
<fkchang>
Something I was thinking about down the road was say taking sample ember apps and rewriting themin lissio w/reactive, or vienna w/bindings, etc.. as a comparison- my assumption is that it will be clearer and cleaner. The idea is the "opal-tk" would be even less code. Stats like LOC: ember: 100, lission/viena 50, opal-tk 23 is sort of the goal
<meh`>
it took some time to get to this maturity, but it was well spent time when I'll make everything else in a fraction of that time
<fkchang>
ryanstout: that's an issue, esp. if u need to make things that don't exist, or look totally different than the std toolset. But w/my notion that opal-tk is built on top of lissio, it's still html, and css, and haml, jade etc. seems to have some uptake w/designers
<ryanstout>
fkchang: yea, personally I love ruby, but I don't see enough of a win with doing something like css in ruby. sass meets my need.
<ryanstout>
mostly because I'm not doing anything too dynamic with my css, but maybe other people are
<fkchang>
the other thing is then opal-tk development inside of opal-inspect could be really slick, coz you have to write so little code to make lots of stuff happen, then maybe drill down into the lissio component and change html/css real time, etc.
DrShoggoth has joined #opal
<fkchang>
ryanstout: I think that's mindset and familiarity. As someone who once upon a time did lots of desktop gui work, to include helping implement a cross platform GUI lib, It drives me crazy the "accepted limitations" the browser has put upon us.
<meh`>
ryanstout, think different
<fkchang>
but you can hide those limitations via abstraction
<meh`>
ryanstout, you can implement extensions to the CSS DSL, in Ruby
<ryanstout>
I guess I'm saying with sass I don't feel the limitations
<meh`>
but in general I find the CSS syntax absolutely disgusting
<meh`>
and generates the various browser specifix prefixes itself
<ryanstout>
I understand it more with html
<meh`>
ryanstout, the point is
<meh`>
with the DSLs
<meh`>
you can have everything relating to a component, in the component itself
<meh`>
instead of having a thousand different files
<meh`>
or two huge files
<ryanstout>
meh`: so full disclosure, the first thing I thought when I opened app.rb in gwentoo was "woa, there's a lot of stuff going on in this one file", hehe
<meh`>
ryanstout, it's the main file, it creates the foundation of the rest
<ryanstout>
I mean more that it had all of the layers in one file
<meh`>
what layers?
<ryanstout>
like its nice imho to be able to go into a "views" layer for example and change content without needing to search through code
<adambeynon_>
meh`: quick question, what does the 'bang' mean in this (from gwentoo): `div.footer!`
<ryanstout>
same with styles
<fkchang>
ryanstout: part of the reason sass exists is due the limitations of the browser system, i.e. you want to be able to write css as a programming language, which you can say is an oversimplification of sass, to be able to deal with the fact that "components" (pre web components) are not objects, don't inherit, etc. but separate bunches of html, css, and js. With lissio, you put it together in an object, and you can inherit. I have a
<fkchang>
theory that down the rood w/lissio, you would use very little of sass, because you do your inheritance and reuse at the component object level, instead of via dynamically generated complex css via sass
<meh`>
adambeynon_, <div id="footer">
<meh`>
tag.id!.class.class2
<adambeynon_>
ah, ok
<ryanstout>
fkchang: so does lissio do inheritance with css right now?
<fkchang>
ryanstout: I don't know, but it seems to be a natural next step if it doesn't
<meh`>
ryanstout, right now it requires internal plumbing
<adambeynon_>
regarding ruby vs css/sass - aslong as it *could* be written in either, it seems a case of the developer picking their favourite tool
<meh`>
but it's in my TODO list to fix
<adambeynon_>
lissio components could just use sass rules..
<ryanstout>
yea, if you could get that working, that could be valuable. Right now it just seems like css generated via a ruby dsl
<meh`>
adambeynon_, yes, nothing stops you from using css
<fkchang>
btw, the cascading part of CSS, is kind of like "monkey patching gone nuts" -- you never know what things will look like until you render it in the browser and everything has cascaded from myriad many cases
<ryanstout>
if you were able to leverage ruby to make it less work, then I would be all for it
<meh`>
ryanstout, that's the plan
<meh`>
I just have to figure out a good way to do it
<ryanstout>
but right now I have inheritance in sass, and its easy for non-ruby people to understand
<ryanstout>
meh`: ok, I could see the value in that
<adambeynon_>
meh`: how easy would it be to override a lissio component to use a string of html, instead of paggio?
<meh`>
html '<hello></bye>'
<fkchang>
meh`: what do think css inheritance to look like, you just override the rules you want, and automatically inherit from parent? I think u do either that, or maybe optionally include the parents css, i.e. you intentionally call super(), if you want the parent's css, or you have the option of not including anything. That said you could mix in "css modules"
<meh`>
instead of passing it a block
<fkchang>
ryanstout: re: your "go to a views direct to look for markup". I think it's even easier w/lissio, Oh, I want to change the markup for alerts, where do I go? alert.rb
<fkchang>
and the css and behavior is there too
<fkchang>
meh`: have you looked at web components yet? Wonder if lissio components should compile down to those at some point
<meh`>
fkchang, only looked at the shadow dom
<meh`>
fkchang, what I have in mind is
<meh`>
no css { } requires you start the rule
<meh`>
css { rule(".my-component") { } }
<meh`>
next step is removing that shit
<meh`>
it infers the selector from either the #element or #tag
<meh`>
and one irritation is gone
<meh`>
the second
<meh`>
is that when you inherit
<meh`>
the child class generates a random class name
<meh`>
so you don't pollute the parent CSS
<meh`>
this behaviour is implemented by hand by Tooltip and Alert right now
<meh`>
basically I'm working on stuff
<meh`>
and seeing how much boilerplate I repeat
<meh`>
and transform it into a standard component or API change
<meh`>
the main boilerplate now is the page behaviour
<meh`>
I have it *EVERYWHERE*
<meh`>
that will be standardized into a Page component
<meh`>
it's all a matter of time
<meh`>
time to use lissio more, time to see what's good and what could be better, and make it better
DrShoggoth has quit [*.net *.split]
Kilo`byte has quit [*.net *.split]
DrShoggoth has joined #opal
Kilo`byte has joined #opal
DrShoggoth has quit [Ping timeout: 240 seconds]
DrShoggoth has joined #opal
barry_ has quit [Remote host closed the connection]
barry_ has joined #opal
barry_ has quit [Ping timeout: 240 seconds]
dfranciosi has quit [Remote host closed the connection]
<wmnnd>
I have another question, if you don't mind. I'm not really keen on using Sprockets/another server application. What is the recommended way to statically compile Opal files? Do I just use Opal.compile and write that to a js file? Because when I try that, I get a »ReferenceError: Opal is not defined«
<meh`>
wmnnd, you have to include opal.js
<meh`>
wmnnd, and there are plans to have opal-cdn
<meh`>
I just haven't had the time to start working on it yet
<wmnnd>
Ah, I figured another javascript was missing.
<wmnnd>
But it doesn't really mention opal.js in the docs.
<meh`>
wmnnd, because that's not the common way to deploy opal
<meh`>
and we lack generating and providing external already compiled gems/stdlibs/things
<meh`>
that's what opal-cdn will do
<wmnnd>
So you would advise against using Opal without Sprockets?
<meh`>
wmnnd, it could be a problem
<wmnnd>
Because, honestly, if you're off the rails, this seems like a major catch to this wonderful idea.
<meh`>
wmnnd, keep in mind stdlibs are separated from opal.js
<meh`>
wmnnd, you really don't need rails
<meh`>
just rack
<meh`>
there's a simple rack example to run opal
<meh`>
wait
<meh`>
I have something even better in your case
<meh`>
you said you were going to use sinatra, right?
<wmnnd>
Mhm … but I still don't feel that I really understand what the advantage of all this is.
<meh`>
of which one of the two?
<meh`>
sprockets is needed to handle requires
<meh`>
sprockets IS the require system in opal
<wmnnd>
Ah, okay.
<wmnnd>
Then it makes sense now.
<meh`>
that said, I hate sprockets, but it fits in many pipelines
<meh`>
it wasn't my choice, it is better than what we had at the beginning
<wmnnd>
it is really kind of you to answer all my questions :)
<meh`>
we're part of the nice side of the Ruby community I guess :)
<wmnnd>
I saw the recorded Rubyconf talk on Opal (»Opal, a new hope«) and was happy there was finally something sensible that I could use to develop web applications.
barry_ has joined #opal
<AndrzejKrzywda>
btw, I created the 'rails' hackpad where opal is bashed
<meh`>
we've gone a long way since I joined the development (2 years ago?), it's ready for production stuff to me
<AndrzejKrzywda>
no need to worry about it too much, rails community enjoys little dramas ;)
<meh`>
AndrzejKrzywda, yeah, I avoid Rails like the plague because of that
<AndrzejKrzywda>
today, I showed Opal to my students at University
<AndrzejKrzywda>
meh`: I can understand that :)
<meh`>
AndrzejKrzywda, what was the reaction?
<AndrzejKrzywda>
btw, anyone would be interested in submitting an 'opal talk proposal' to our Ruby conference - http://cfp.wrocloverb.com/ ?
<AndrzejKrzywda>
we've got some Opal proposals already, so hopefully we'll choose at least one of them
<AndrzejKrzywda>
meh`: good reaction, I think. It sounded exotic to them. I put it in a bigger context of some reusability, etc.
<meh`>
AndrzejKrzywda, oh yeah, I think the guys bashing Opal because "you can't use other javascript libraries" miss the fact that you can use Ruby gems
<AndrzejKrzywda>
meh`: many people in the rails community can't think that far ;)
<AndrzejKrzywda>
rails got huge. it brought good people and idiots, that's what happens when a technology is too mainstream
<meh`>
indeed
<meh`>
that's also my worry for opal
<AndrzejKrzywda>
you can't do anything
<AndrzejKrzywda>
just the way it is
<wmnnd>
And while idiots might come with it, nice people will come too.
<AndrzejKrzywda>
yep
DouweM has quit [Ping timeout: 260 seconds]
<AndrzejKrzywda>
we've got one talk submitted that is going to show code reuse across ruby backend, rubymotion and opal. sounds good :)
<adambeynon_>
AndrzejKrzywda: the app I've just rewritten does something similar. A compiled opal web app running inside a ruby motion container speaking to a rails back end, and all sharing some models. :) feels good
<meh`>
adambeynon_, did you answer about the opal/parser opal/mini proposal?
<meh`>
I don't remember
<AndrzejKrzywda>
adambeynon_: sounds awesome!
<wmnnd>
I really don't want to sound dumb, but is there any proper documentation available for the Opal classes? I.e. what parameters Opal::Server takes and what they do?
<adambeynon_>
wmnnd: not really. documentation is (and has been for ages) really lacking
<meh`>
sadly
<meh`>
no time for doc
<wmnnd>
Mhm, that seems to be the case in many Ruby projects.
<meh`>
wmnnd, I think there is some doc inline tho
<adambeynon_>
wmnnd: Opal::Server is just a simple pre-built rack app - mainly used for the spec/test runners
<meh`>
nope
DrShoggoth has quit [Quit: Leaving]
<adambeynon_>
meh`: problem with opal/parser is that it is already the opal/parser.rb in the lib/ dir
<adambeynon_>
(I saw you mentioned sinatra before)
<wmnnd>
Ah, this looks more promising!
<meh`>
I wonder why I went the cascade way with opal-browser
<wmnnd>
Okay, which parameters does Opal::Environment take now? /assets will be the logical path here and Opal will compile all .rb files from ./app?
<adambeynon_>
meh`: Im no sinatra expert - it just seemed a really light way to mirror the rails way of capturing everythign under /assets
<meh`>
adambeynon_, it is
<meh`>
ah right, I use Opal::Server in there
<meh`>
not Opal::Environment directly
<meh`>
again no clue why, meh
<adambeynon_>
wmnnd: Opal::Environment is a subclass of Sprockets::Environment, so if you have any link pointing into /assets/foo.js then it will be compiled
<adambeynon_>
wmnnd: the nice thing about Opal::Environemtn is that you can precompile it to a file, ready for production mode
<adambeynon_>
Opal::Environment.new['application.rb'].to_s # this will be your entire app
<adambeynon_>
so you could wrap that map('/assets') in an if-block to only run in development mode
<wmnnd>
Thanks the two of you :)
<wmnnd>
Alrighty, next question: Is it not possible to require files that are not within the opal directory?
<adambeynon_>
wmnnd: opal works with a load path
<adambeynon_>
see that append_path() call?
<adambeynon_>
you need to add a directory using that method to the load path
<meh`>
adambeynon_, is #use_gem on Opal::Environment?
<adambeynon_>
meh`: yeap
<meh`>
wmnnd, if you want to use a gem that isn't an opal gem, you need to use #use_gem
<wmnnd>
Actually, for now I just want to include my erb files.
<wmnnd>
Because they're shared with the server-application, they can't be in the Opal directory.
<adambeynon_>
wmnnd: yeh, so just add that directory and then you can require() them individually
<adambeynon_>
and each erb template is then available inside the Template constant
<adambeynon_>
each template file gets a Template instance
<adambeynon_>
so with your login view:
<adambeynon_>
Template['login'].render self
<adambeynon_>
not sure why sprockets cant find your file though..
<adambeynon_>
you are restarting sprockets, yeh?
<wmnnd>
Yes.
<wmnnd>
Mhm, this is not working either. I suppose, I have to require "template"? Because otherwise I don't get anything. But if I do use it, the Firefox console tells me »undefined method« "render" for nil. I suppose this is because it still can't find the template.
<adambeynon_>
wmnnd: if it finds a template, then the Template file is included for you
<adambeynon_>
has it stopped saying it cant find that template?
<wmnnd>
Nope.
<wmnnd>
I've tried calling it login.js.erb, login.opal.erb, to no avail.
<adambeynon_>
the reason for the opalerb extension is a awkwardness with sprockets
<adambeynon_>
it already handles erb files specially :/
<wmnnd>
Ah, okay that is working now :)
<adambeynon_>
wmnnd: if you want to use haml instead, then you can use the .haml extension ;)
<wmnnd>
But of course, renaming it to opalerb breaks the compatibility with the rest of the application, that is, mainly Sinatra's way of using templates.
<adambeynon_>
wmnnd: thats the problem
<adambeynon_>
wmnnd: when I used erb templates, I didnt share them with rails
<adambeynon_>
I have only starte sharing since I switched to haml
<adambeynon_>
you could precompile the erb templates, but that does add an extra step which is annoying
<wmnnd>
I would use haml if I would enjoy using Python, but I don't^^
<adambeynon_>
fair enough :)
e_dub has quit [Quit: It's a hard knock life]
<wmnnd>
Mhm, this is all a little clumsy. I guess I'll just use filesystem links or something like that for now.
<adambeynon_>
wmnnd: yes, the extension was really awkward to deal with
<adambeynon_>
are you using all the templates client side?
<adambeynon_>
or just some?
e_dub has joined #opal
<wmnnd>
Just some.
<wmnnd>
I guess I could also make rake create the links or copy the files.
<adambeynon_>
wmnnd: the reason you cant use .erb is because sprockets uses it for evaling ruby code into your assets
<adambeynon_>
so you could do something like create a templates.js.erb file
<adambeynon_>
which your opal app requires
<adambeynon_>
which would then compile your templates for you
<wmnnd>
Thank you for that idea :)
<wmnnd>
I'm probably just really really spoiled by the Qt documentation.
<adambeynon_>
wmnnd: I think I was the only one using erb with opal, so it was all left to me and I get lazy around documentation :/
<adambeynon_>
wmnnd: if you did want to use that compiling solution:
<wmnnd>
adambeynon_ Of course, that is probably the hardest kind of documentation to write :-)
<wmnnd>
Oh, one more thing, my Opal file makes Firefox complain about the deprecated source mapping pragma indicator "//@" when "//#" should be used. I guess this is the fault of Sprockets?
<adambeynon_>
wmnnd: no, opal needs to update it to "//#"
<adambeynon_>
will be ready for next release
<adambeynon_>
(couple days away)
<wmnnd>
Yay! You guys are awesome.
<e_dub>
adambeynon_, what I think could use work is better / more documentation on javascript interop . How to interact with javascript libs, how to wrap them, call functions, use Native, etc
<e_dub>
now that that isnt automatic
<meh`>
and that would be on me since I wrote it all ◕ ◡ ◔
<e_dub>
lol
<e_dub>
i've been looking at opal-browser to figure it out, but some docs would be greatly appreciated
<meh`>
e_dub, I will find the time, sooner or later
<meh`>
hopefully sooner
<e_dub>
awesome, ping me when you do if you think of it
<meh`>
but the baseline is, Native(`whatever`), then it's a Ruby object, treat it as one
<meh`>
unless you want to write wrappers yourself
<e_dub>
ok, that's pretty much what I had deduced
<meh`>
that's why I haven't written documentation
<meh`>
you don't even need to call Native if you're calling functions
<meh`>
$$.alert("whatever")
<meh`>
every argument is converted to a JS native, every return value is converted to a Native
<meh`>
$$.MyAwesomeJavaScriptLibrary.whatever
<meh`>
that is all you need
<e_dub>
thats sweet , didnt know that one
<meh`>
$$ = Native(`window`) :)
marcandre has quit [Read error: Connection reset by peer]
marcandre has joined #opal
ryanstewart2 has quit [Ping timeout: 272 seconds]
ryanstewart has joined #opal
<fkchang>
wmnnd: glad you liked my talk
<fkchang>
adambeynon_: We should consider using yard in the opal code and generating doc from there
<fkchang>
adambeynon_: maybe rocco docs on the code the way coffescript does it too
e_dub has quit [Ping timeout: 240 seconds]
<meh`>
adambeynon_, can opal-parser.js be required before opal.js?