meh` changed the topic of #opal to: http://opalrb.org - Ruby runtime and library on top of Javascript | 1.0.0 is near | This channel is logged at https://botbot.me/freenode/opal/
e_dub has joined #opal
e_dub has quit [Quit: e_dub]
Noldorin has quit [Read error: Connection reset by peer]
Noldorin has joined #opal
Noldorin has quit []
Noldorin has joined #opal
dleedev has quit [Quit: dleedev]
RoxasShadowRS has quit [Quit: Leaving]
e_dub has joined #opal
e_dub has quit [Quit: e_dub]
e_dub has joined #opal
ylluminate has joined #opal
meh`_ has joined #opal
e_dub has quit [Quit: e_dub]
e_dub has joined #opal
meh` has quit [Remote host closed the connection]
Noldorin has quit []
e_dub has quit [Quit: e_dub]
e_dub has joined #opal
ryanstout has quit [Quit: ryanstout]
dimaursu16 has joined #opal
dleedev has joined #opal
<meh`_> adambeynon, ping
GitHub162 has joined #opal
<GitHub162> [opal] meh pushed 6 new commits to master: http://git.io/FL31Sg
<GitHub162> opal/master a210fca meh: Add an Opal.respond_to? helper
<GitHub162> opal/master 0cfce9b meh: Cleanup Array#first
<GitHub162> opal/master 230f862 meh: Cleanup Array#last
GitHub162 has left #opal [#opal]
<adambeynon> hi meh`_
<meh`_> adambeynon, do you agree that Array methods should work even if the array contains native objects?
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal#1727 (master - e76b716 : meh): The build passed.
travis-ci has left #opal [#opal]
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal/builds/18066439
<adambeynon> meh`_: nope. I dont think arrays should contain native objects
<meh`_> oh
<adambeynon> shouldnt they be wrapped?
<adambeynon> in Native::Ojbect ?
<meh`_> adambeynon, the problem is
<meh`_> for example, if I want to #flatten and then convert them
<meh`_> I can't
<meh`_> well, I couldn't, I pushed a change that makes it meaningful, I think array methods should work even if the array contains natives, to a certain extent
<meh`_> the array should work regardless of what it contains
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal#1727 (master - e76b716 : meh): The build passed.
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal/builds/18066439
travis-ci has left #opal [#opal]
<meh`_> adambeynon, let me rephrase the previous question
<meh`_> adambeynon, do you agree that operations on the Array which have basically nothing to do with the items should work on arrays with native objects?
<meh`_> adambeynon, for instance, #push, #pop, #flatten, etc
<meh`_> I'm not saying stuff like #sort or #join should automatically work with natives
<meh`_> but operations on the shape of the Array should
<adambeynon> meh`_: what would you expect #push to do?
<adambeynon> wrap it in a Native() ?
<meh`_> no
<meh`_> just push the native
<meh`_> nothing gets wrapped
<meh`_> it just pushes the item
<meh`_> this comes from the fact previous #flatten would raise a weird exception if you tried to flatten an array that contained a native
GitHub107 has joined #opal
<GitHub107> [opal] meh pushed 3 new commits to master: http://git.io/JdszTw
<GitHub107> opal/master 48e3451 meh: Use Opal.inspect in Array#join
GitHub107 has left #opal [#opal]
<GitHub107> opal/master 6dbba1f meh: Add Opal.inspect helper
<GitHub107> opal/master bdaca2f meh: Fix Opal.respond_to? helper
GitHub76 has joined #opal
<GitHub76> opal-browser/master ecc07d2 meh: dom/element: no need to #map in #css anymore
GitHub76 has left #opal [#opal]
<GitHub76> [opal-browser] meh pushed 1 new commit to master: http://git.io/Lk0VVg
travis-ci has joined #opal
travis-ci has left #opal [#opal]
<travis-ci> [travis-ci] opal/opal#1728 (master - 48e3451 : meh): The build passed.
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal/builds/18066999
meh`_ has quit [Quit: Reconnecting]
meh` has joined #opal
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal#1728 (master - 48e3451 : meh): The build passed.
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal/builds/18066999
travis-ci has left #opal [#opal]
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal-browser#140 (master - ecc07d2 : meh): The build passed.
travis-ci has left #opal [#opal]
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal-browser/builds/18067029
GitHub23 has joined #opal
<GitHub23> opal-browser/master e4cee2a meh: dom/node: use Native.convert in #== instead of Native.try_convert
<GitHub23> [opal-browser] meh pushed 5 new commits to master: http://git.io/xI1XCg
GitHub23 has left #opal [#opal]
<GitHub23> opal-browser/master a5e9421 meh: dom/element: #id should return nil when the id is empty
<GitHub23> opal-browser/master d551aa1 meh: dom/node: use Native.convert in #replace instead of Native.try_convert
GitHub87 has joined #opal
<GitHub87> opal-browser/master 8144d58 meh: dom/element: fix #id=
<GitHub87> [opal-browser] meh pushed 1 new commit to master: http://git.io/D7eEKg
GitHub87 has left #opal [#opal]
<adambeynon> meh`: whats the inspect helper for?
<meh`> adambeynon, better error in some cases
<meh`> *errors
<meh`> adambeynon, for instance, in Array#join
<meh`> I know you shouldn't deal with native values, but when it happens by mistake it's very hard to understand what is actually happening
<meh`> don't underestimate the power of meaningful errors
<adambeynon> but hiding them surely ant be helpful either
<adambeynon> cant*
<meh`> they're not being hidden
<meh`> adambeynon, js and ruby have two different inspect styles
<meh`> [shit] #<shit>
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal-browser#141 (master - 7fd893a : meh): The build has errored.
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal-browser/builds/18067406
travis-ci has left #opal [#opal]
dleedev has quit [Quit: dleedev]
travis-ci has joined #opal
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal-browser/builds/18067540
<travis-ci> [travis-ci] opal/opal-browser#142 (master - 8144d58 : meh): The build passed.
travis-ci has left #opal [#opal]
<meh`> adambeynon, I can consistently recreate the block passing issue
GitHub19 has joined #opal
GitHub19 has left #opal [#opal]
<GitHub19> opal-browser/master a4bd2f3 meh: dom/element: improve #inner_dom and add specs
<GitHub19> [opal-browser] meh pushed 1 new commit to master: http://git.io/GieSNA
<meh`> adambeynon, https://github.com/opal/opal-browser/blob/master/opal/browser/dom/element.rb#L233-L235 pass the document call instead of the doc variable
<meh`> and it happens
<adambeynon> meh`: http://opalrb.org/try/#code:def%20document%0A%20%20nil%0Aend%0A%0Aclass%20Builder%0A%20%20def%20initialize(a%2C%20b%2C%20%26c)%0A%20%20%20%20p%20%5Ba%2C%20b%2C%20c%5D%0A%20%20end%0Aend%0A%0Adoc%20%3D%20document%0Ablock%20%3D%20proc%20%7B%7D%0ABuilder.new(doc%2C%20self%2C%20%26block)
<adambeynon> swapping it out still works
<meh`> adambeynon, yes, I know
<meh`> it can't be reduced, I already tried
<meh`> it's something around it
<adambeynon> meh`: is the block passed in?
<meh`> yes
<meh`> just add a `debugger` there and have tons of fun!
<meh`> I can try, but I don't know the runtime as well as you do
<adambeynon> meh`: is document a Native::Object ?
<meh`> nope
<meh`> it's a DOM::Document
<meh`> _p is null
travis-ci has joined #opal
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal-browser/builds/18068019
<travis-ci> [travis-ci] opal/opal-browser#143 (master - a4bd2f3 : meh): The build was broken.
travis-ci has left #opal [#opal]
<meh`> it isn't null up to $a._p = block.$to_proc()
<meh`> it becomes null after it gets inside #document
<meh`> adambeynon, actually no
<meh`> it still seems to be null
<meh`> after block.$to_proc
<meh`> it's not getting set
<meh`> for whatever reason
DavidEGrayson has quit [Read error: Connection reset by peer]
e_dub has quit [Quit: e_dub]
<adambeynon> meh`: that bug has thrown me right off
<meh`> yeah, it's weird
<meh`> I think I found an even weirder bug tho
<meh`> with paggio and IE6..8
<meh`> yep
<meh`> it's not setting the id
<meh`> mh
<meh`> lol
<meh`> there's something broken with end_with
<meh`> and I think I know what
<meh`> and I don't know
<meh`> but #end_with? is definitely broken in IE6..8
<meh`> yeah
<meh`> substr doesn't handle negative indices in IE6..8
GitHub112 has joined #opal
<GitHub112> opal/master 5f0ed8b meh: Properly coerce to String in String#start_with?
<GitHub112> [opal] meh pushed 3 new commits to master: http://git.io/FExFow
GitHub112 has left #opal [#opal]
<GitHub112> opal/master aea44e7 meh: Properly coerce to String in String#end_with?
<GitHub112> opal/master b80fcc5 meh: Fix String#end_with? in IE6..8...
travis-ci has joined #opal
travis-ci has left #opal [#opal]
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal/builds/18069580
<travis-ci> [travis-ci] opal/opal#1729 (master - b80fcc5 : meh): The build passed.
GitHub141 has joined #opal
<GitHub141> [opal] meh pushed 1 new commit to master: http://git.io/NJIB7A
GitHub141 has left #opal [#opal]
<GitHub141> opal/master 8462178 meh: Fix String#chomp to work in IE6..8
GitHub150 has joined #opal
<GitHub150> opal-browser/master fc768cd meh: spec/dom/builder: add spec for tag.id!
GitHub150 has left #opal [#opal]
<GitHub150> [opal-browser] meh pushed 1 new commit to master: http://git.io/qP8VYw
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal#1730 (master - 8462178 : meh): The build passed.
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal/builds/18069645
travis-ci has left #opal [#opal]
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal#1730 (master - 8462178 : meh): The build passed.
travis-ci has left #opal [#opal]
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal/builds/18069645
kludge` has quit [Ping timeout: 252 seconds]
kludge` has joined #opal
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal-browser#144 (master - fc768cd : meh): The build was fixed.
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal-browser/builds/18069677
travis-ci has left #opal [#opal]
<meh`> adambeynon, ping
<adambeynon> hi meh`
<meh`> adambeynon, I'm having some weird issue with array inheritance
<meh`> I can't implement my own self.allocate, self.new or self.[]
<meh`> see anything that could prevent that?
<adambeynon> meh`: do other class methods work ok?
<meh`> yes
<meh`> they are special cased there
<meh`> but they should be overridable
<adambeynon> meh`: ahhh. classes are just instances of their class constructor. so by setting them directly on the class, any overrides in the prototype chain dont override the instance properties you are defining there
<meh`> oh
<meh`> any way to fix it?
<adambeynon> klass._klass._proto.$allocate = replace.$allocate
<adambeynon> (untested, but that should work)
<meh`> yeah, running mspec
<meh`> nope, doesn't seem to work
<meh`> maximum call stack size exceeded
<adambeynon> meh`: are you calling super() back into the originals?
<meh`> adambeynon, how do you mean?
RoxasShadowRS has joined #opal
<meh`> adambeynon, and the error is from mspec
<adambeynon> meh`: what error does it give?
<meh`> maximum call stack exceeded
<meh`> some infinite recursion
<meh`> it works in the repl tho
<meh`> adambeynon, oh yes, I am
<meh`> allocate calls super
<meh`> yeah, it's allocate that breaks
<adambeynon> meh`: probably some edge case in the super() lookups
<adambeynon> that is all very ugly
<adambeynon> infact I remeber class level super was slightly broken somewhere
<adambeynon> remeber*
<adambeynon> remember*****
<meh`> adambeynon, yeah, not a problem
<meh`> I can just reimplement it in those two cases
<meh`> mh
<meh`> seems like it breaks like this
<meh`> yeah, the created class is wrong
<meh`> adambeynon, are you sure I'm not overwriting the Array proto?
<meh`> because self in there seems to be the wrong class
<meh`> mh
<meh`> what the hell
<meh`> only .[] seems to return the wrong class
<meh`> no, foo as well
<meh`> only allocate returns the right class
<meh`> the other functions call allocate
<meh`> might that be the problem?
<meh`> nope
<meh`> that doesn't fix it
<meh`> self._alloc is still wrong in new and []
<meh`> but not in allocate
<meh`> yeah, new and [] are directly from Array
<meh`> probably because Array doesn't implement allocate itself
<meh`> adambeynon, any clue?
<adambeynon> meh`: trying to read though the runtime
<adambeynon> it really needs a rewrite
<meh`> adambeynon, it's fine, I can leave NodeSet as not an Array for now
<adambeynon> meh`: (Y)
<adambeynon> I will try and work through it later today too
<adambeynon> meh`: Im working on Opalscript today - trying different ideas on how to get ruby + js a bit nicer
<adambeynon> I think there is room for opal and opalscript
<meh`> what would opalscript be?
<adambeynon> meh`: middle ground. nil == null, call native methods
<adambeynon> classes as functions/prototype
<adambeynon> so method_missing on objects
<adambeynon> but not on classes
<adambeynon> basically, enough of ruby but still able to call document.getElementById() without any wrappers or dispatchers
<adambeynon> meh`: ruby syntax, but sacrifice some semantics
<adambeynon> but not many...
<adambeynon> most importantly, obj.foo(1, 2, 3) compiles to obj.foo(1, 2, 3)
<adambeynon> meh`: also, the opalscript name is just a temp name whilst i think up a better name
<adambeynon> it will be completely separate to opal
<adambeynon> but with the aim that 99% of ruby code will work under both
<adambeynon> meh`: it will intercept most calls to arrays, and pipe them through a special object
<adambeynon> #each for example
<adambeynon> will be similar to underscore
<adambeynon> if its an array, handle it, otherwise dispatch it back to the real object
<adambeynon> so Array.prototype.each will never exist
<adambeynon> but, [1, 2, 3].each do .. end
<adambeynon> will work just fine
<adambeynon> meh`: anyway, I am working on a markdown document covering it
<adambeynon> the aim is to be able to run mspec + some rubyspecs on it
<adambeynon> I doubt rspec would work, but thats rspecs fault for being so temperamental
<meh`> adambeynon, I see
<meh`> yeah opalscript doesn't sound like a good idea
<meh`> could cause more confusion than not
<meh`> as in, the name
dimaursu16 has quit [Ping timeout: 240 seconds]
<adambeynon> meh`: yeah. Opalscript is just the dir name ATM. Was thinking about "malt" or something
<adambeynon> meh`: can you gist your array subclass
<adambeynon> So I can dig through it
<meh`> adambeynon, even class Foo < Array; def self.[]; 42; end; end
<meh`> Foo[] will return array instead of 42
<meh`> adambeynon, what worries me about an opalscript is dividing the efforts and interests tho
<meh`> I mean, if it's just like opal but not as much, what's the point? can't that effort be somehow integrated in opal?
<adambeynon> meh`: I am working on a fork from opal, so I'm hoping it could be as simple as having an alternative runtime
<meh`> for instance, I'd be less worried about having a require 'opal/mini' than having a completely different project
<meh`> we're already low on attention, splitting up sounds scary
dimaursu16 has joined #opal
dimaursu16 has quit [Ping timeout: 252 seconds]
dimaursu16 has joined #opal
Noldorin has joined #opal
elia has joined #opal
<adambeynon> meh`: low on attention because we can't interact with JavaScript? ;)
<meh`> adambeynon, I don't think that's the case
<adambeynon> meh`: it is the biggest thing which puts people off when I show them. "Just create a ruby wrapper" doesn't usually go down too well
<meh`> but you don't have to
<meh`> you can just use native
<meh`> adambeynon, it's just you don't use nor know about native, admit it
<adambeynon> meh`: i do. I use it quite a lot. Didn't use to. But I do now
<meh`> ok, good
<adambeynon> But it's still a wrapper
<adambeynon> meh`: it depends on the type of apps I guess. I have to write apps that opal is only a top layer. Having to interact with lots of js libs feels very awkward
<adambeynon> meh`: atleast this way, im less likely to be against adding more edge case ruby features as opal will be more of a full ruby runtime ;)
<meh`> and more likely to give less attention to opal? ( ≖‿≖)
<adambeynon> meh`: I actually think it could be more of a stepping-stone
<adambeynon> easy to integrate with existing projects
<adambeynon> updating an app to opal is a huge task
<adambeynon> writing/replacing small parts could be a decent middleground
<adambeynon> meh`: Im not going to start rewriting any opal apps using opalscript
<adambeynon> new ones, perhaps
<adambeynon> meh`: I think people being able to write Backbone apps using opalscript could be a very nice grabbing point
<adambeynon> meh`: infact, I've got method_missing working for classes in opalscript now as well
<adambeynon> getting closer ^_-
<meh`> adambeynon, is the markdown anywhere to read?
e_dub has joined #opal
dimaursu16 has quit [Quit: Leaving]
GitHub104 has joined #opal
<GitHub104> opal-browser/master e24aab5 meh: dom/node: use Native.convert instead of Native.try_convert in #parent=
GitHub104 has left #opal [#opal]
<GitHub104> [opal-browser] meh pushed 7 new commits to master: http://git.io/gc31YA
<GitHub104> opal-browser/master 623dec5 meh: dom/builder: remove element support
<GitHub104> opal-browser/master 3a46c48 meh: dom/node: simplify #clear
<adambeynon> meh`: yeah, some initial thoughts I had with a colleague
<adambeynon> some of that has changed/irrelevant
<adambeynon> but gives the general idea
e_dub has quit [Quit: e_dub]
travis-ci has joined #opal
<travis-ci> [travis-ci] Build details : http://travis-ci.org/opal/opal-browser/builds/18081240
<travis-ci> [travis-ci] opal/opal-browser#145 (master - d859b81 : meh): The build passed.
travis-ci has left #opal [#opal]
GitHub48 has joined #opal
<GitHub48> [lissio] meh created gh-pages (+2 new commits): http://git.io/Pv6S_g
<GitHub48> lissio/gh-pages 70a7526 meh: Initial commit
<GitHub48> lissio/gh-pages 231d5e0 meh: Add CNAME
GitHub48 has left #opal [#opal]
dimaursu16 has joined #opal
e_dub has joined #opal
GitHub105 has joined #opal
<GitHub105> lissio/gh-pages 18b52ef meh: Update build
<GitHub105> [lissio] meh pushed 1 new commit to gh-pages: http://git.io/zsmLAQ
GitHub105 has left #opal [#opal]
<meh`> http://liss.io/ huehue
<adambeynon> \o/
DouweM has quit [Read error: Connection reset by peer]
ryanstout has joined #opal
meh` has quit [Ping timeout: 245 seconds]
ryanstout has quit [Quit: ryanstout]
meh` has joined #opal
<meh`> adambeynon, any news?
<adambeynon> meh`: not a lot
e_dub has quit [Quit: e_dub]
elia has quit [Quit: Computer has gone to sleep.]
ryanstout has joined #opal
ryanstout has quit [Quit: ryanstout]
RoxasShadowRS has quit [Quit: Leaving]
RoxasShadowRS has joined #opal
<adambeynon> meh`: do you use '::' for method calls at all?
<meh`> adambeynon, nope
<meh`> no wait
<meh`> adambeynon, how does it work?
<meh`> lol
<adambeynon> just an alias, `self.foo(1, 2, 3)` == `self::foo(1, 2, 3)`
<meh`> then no, never
<meh`> didn't even know it was possible
<adambeynon> meh`: thinking about abusing it with opalscript
<meh`> adambeynon, how so?
<adambeynon> self::foo compiles to `self.foo`
<adambeynon> same for setters
<adambeynon> document::title
<adambeynon> etc
<meh`> sounds good
<adambeynon> meh`: first thing finished is having nil == null
<adambeynon> works mostly without any problems
<adambeynon> "mostly"
<meh`> no love for opal today? :<
<adambeynon> meh`: well, the work I have done has made me think of some good optimization ideas for opal
<adambeynon> runtime method donations etc
<meh`> noice
meh` has quit [Ping timeout: 272 seconds]
meh` has joined #opal
meh` has quit [Ping timeout: 272 seconds]
ryanstout has joined #opal
<adambeynon> ryanstout: hi. how much does the javascript/ruby divide matter to you?
<adambeynon> i.e. the difficulty in calling js methods/properties/etc
<ryanstout> adambeynon: like is it important to be able to call ruby from JS?
<ryanstout> adambeynon: sorry, not sure I follow
<adambeynon> ryanstout: other way around. at the moment, to call a library, e.g. jquery, we need a wrapper
<adambeynon> or lots of inline javascript
<ryanstout> I personally like the inline JS
<ryanstout> the wrappers are nice, but I think for opal to get big, its gotta be able to easily leverage existing JS
<ryanstout> but thats just my thoughts
<ryanstout> adambeynon: is there a reason you're asking?
<adambeynon> ryanstout: I agree on that point. Im playing with a fork to try and get opal able to call normal js methods
<ryanstout> like how jruby does?
<ryanstout> with java
<adambeynon> ryanstout: yeap. i havent used jruby, but I think its the same idea
<ryanstout> I will say, there's a bit of a learning curve now for calling out to JS, and passing things back and forth. Some of that could be solved with better docs, but I think your idea sounds better.
<ryanstout> adambeynon: can you give me an example of what a call would look like?
<adambeynon> ryanstout: well, the compiler would compile `self.do_something(1, 2, 3)` into `this.do_something(1,2,3)`
<adambeynon> ryanstout: I want to remove the '$' prefix
<ryanstout> ah
<ryanstout> interesting
<ryanstout> is that possible without messing up a bunch of other things?
<adambeynon> it would clash with arrays and strings, which have methods of the same name, but they would be special cases
<ryanstout> what happens to instance vars?
<adambeynon> @foo => this.$foo
<ryanstout> ok
<ryanstout> very interesting
<adambeynon> actually, '$' looks similar to '@'
<adambeynon> in a weird way
<ryanstout> yea, I think that would be nice
<adambeynon> ryanstout: also, `object.foo = 100`
<adambeynon> would compile into a runtime helper
<adambeynon> if `object` responds to that method, it calls it
<adambeynon> otherwise, it sets it as a normal js property
<adambeynon> so object could be a ruby object, or a js object
<adambeynon> and the right thing happens
<ryanstout> interesting
<adambeynon> same with #[] and #[]=
<ryanstout> any performance concerns?
<adambeynon> ryanstout: far less than having to wrap objects inside a Native::Object
<ryanstout> adambeynon: yea :-)
<ryanstout> sounds very interesting
<adambeynon> ryanstout: Im thinking about maybe having just #[] and #[]= be special
<adambeynon> and leave normal setters as they are
<ryanstout> I will say, working with some other people on volt, they don't seem to get how to do things like passing a ruby method as a callback
<ryanstout> so normal setters would always call the setter method, and fail on JS objects right?
<adambeynon> ryanstout: yes. I think using #[] and #[]= could be acceptable for js objects
<ryanstout> yea
<adambeynon> make them feel like a hash, I suppose
<adambeynon> but, in my testing code, I can just write $document.getElementById("foo") and it compiles to pure javascript
<adambeynon> no wrappers in sight
<ryanstout> yea, thats nice
<ryanstout> and might be a good selling point
<adambeynon> ryanstout: my aim, is to be able to write Backbone View and Model subclasses in opal, and it just work as expected
<ryanstout> though I haven't really used Native yet
<ryanstout> that would be cool
<adambeynon> ryanstout: Native is very useful - but dealing with a wrapper isnt nice. Its a level of indirection. And having to always convert it back and forth is error prone
<adambeynon> ryanstout: oh, one more thing - im hoping to get nil === null working too
<adambeynon> so nil is no longer a special object
<ryanstout> adambeynon: that would also be nice
<ryanstout> does that mean we couldn't add methods to nil?
<adambeynon> ryanstout: you *could*, but it might mean having to register them with the compiler
<ryanstout> humm
<adambeynon> ryanstout: not ideal
<ryanstout> I'm adding methods to nil now
<ryanstout> in Volt
<adambeynon> ryanstout: many?
<ryanstout> just a few
<adambeynon> ryanstout: it is a sticking point
<ryanstout> I have one method on object, that gets the current value of a reactive value, or self if its not a current value
<ryanstout> so at least for me its pretty important
<adambeynon> it breaks rspec #should() as well
<ryanstout> how would registering it with the compiler work?
<ryanstout> to be honest, I hadn't run into an issue with nil === null
<adambeynon> its more to handle null/undefined being returned from javascript functions
<ryanstout> yea, that I guess I have run into
<ryanstout> so totally un-related question, but is there a way you could make the block syntax pass a bound function to JS?
<ryanstout> thats the thing I find confuses most people is trying to pass a ruby method to something like setTimeout
<ryanstout> adambeynon: let me say though, as is things are great, so I'm not complaining
<adambeynon> ryanstout: I'll take a look. see If I can improve that
<adambeynon> ryanstout: oh yeah. this is all out of the main repo - just experimenting
<ryanstout> adambeynon: it sounds cool though. Its super nice in jruby to be able to just call into java without using Java
<ryanstout> but the gap isn't as big with ruby to js
<adambeynon> ryanstout: the most frustrating thing about opal for me is having to require opal-jquery just to get any dom stuff working - thats my target for elimination
<ryanstout> ah, yea
<ryanstout> did you get a chance to check out volt at all? (I need to do some more intro videos)
<adambeynon> ryanstout: in my app I was working on this morning, I had wrappers for jquery, websockets, localstorage and canvas going - It struck me as a little ridiculous :)
<ryanstout> yea, thats a lot of wrappers
<adambeynon> ryanstout: I did, and it inspired me to improve my view stuff in vienna to have proper observer type things
<adambeynon> ryanstout: I need to have a few spare days to jump into volt fully
<adambeynon> the reactive thing is really nice though
<ryanstout> adambeynon: hold off, I'm going to do some more videos, should make things more clear
<adambeynon> ryanstout: sure, look forward to them
<ryanstout> I've got the data store layer working on my branch now too. Its pretty great, like meteor's collections. Things just get synced with the database without making rest api's or anything
DouweM has joined #opal
<ryanstout> adambeynon: let me know if there's anything I can help with on the direct call stuff
<adambeynon> ryanstout: will do. btw, what is the method on NilClass you use?
<adambeynon> blank?
<ryanstout> .cur
<ryanstout> I also have .true?, .false?
<ryanstout> since reactive value's are always true, I use .true? internally to check if its content value is true
<ryanstout> (cur for current value)
<adambeynon> right. yeah, null might be tricky. I suppose the if/unless checks in ruby could also check for null
<adambeynon> so if a method might return null, a simple if check can get around it
<ryanstout> yea
<ryanstout> I don't pollute object much, but I think for frameworks it can be really nice :-)
<adambeynon> ryanstout: volt looks quite complex/large, how do you find performance with opal?
<ryanstout> I'm not sure yet, I have a few very low hanging optimizations I need to do in the reactive stuff before I'll really be able to tell.
<ryanstout> I'm also probably going to make a managed draw cycle, so after that I think I'll have a much better idea
<ryanstout> adambeynon: just curious, what makes it seem large? (it is bigger than some stuff, but I'm hoping from an end user it won't feel too big)
<adambeynon> ryanstout: well, not large. I guess its larger than vienna, but then vienna is a very simple system
<adambeynon> I guess volt looks to be a kind of ember style system compared to vienna as a backbone
<adambeynon> which is good
<ryanstout> yea
<ryanstout> ok. I've gotta take some time and write a tutorial. :-)
<ryanstout> adambeynon: are you planning on doing bindings that update for Vienna?
<adambeynon> ryanstout: I have been trying, but i am learning that trying to shoe-horn that into haml or erb templates is really difficult
<ryanstout> yea, that was where I ended up also
<adambeynon> ryanstout: I then got stuck with resorting to angular style data-html attributes, or whether to look at something like handlebars/mustache
<ryanstout> yea
<ryanstout> I went the handlebars way because thats what I prefer, but a lot of people like the angular style. I always feel like its makes it so too much is going on in your help. And mentally its harder for me to parse and see where things are going to "happen"
<ryanstout> also, you can do stuff like two <tr>'s in an each :-)
<adambeynon> ryanstout: I really dont like the angularjs style, as you say, parsing it quickly is tough
dleedev has joined #opal
<adambeynon> that is my unfortunate current state trying to force bindings into haml
<ryanstout> thats not too bad
<ryanstout> I do like the handlebars style though
<ryanstout> but yea, its a ton more work
<adambeynon> ryanstout: yep. Im keeping my eye on HTMLbars too. looks like a replacement which generates better output (real dom nodes, rather than a string)
<ryanstout> yea, I saw that
<adambeynon> it also makes it way easier to use with something that isnt ember
<ryanstout> seems like the project isn't very active at the moment though
<ryanstout> actually, looks like they picked back up https://github.com/tildeio/htmlbars/graphs/contributors
<ryanstout> I looked at it last in December I think
<ryanstout> my stuff already builds dom instead of strings like ember
<ryanstout> and tracks nodes
<ryanstout> though at the moment its building from a string each time a new node is inserted, so I could cache at the template level, then cloneNode the cached dom.
<ryanstout> would probably give a big performance boost
<adambeynon> ryanstout: yeah. some combination with documentfragments would be huge
<adambeynon> btw, where is the html compiler?
<adambeynon> I cant find it in the repo :(
<ryanstout> its not a real compiler at the moment. Its just a placeholder using nokogiri, until I get time to make a real compiler
<ryanstout> ^ definitely the ugliest part of volt at the moment
<ryanstout> as confirmed by: https://codeclimate.com/github/voltrb/volt hehe
<ryanstout> the templates get compiled on the backend though, so it works until I get time to build something better
<adambeynon> ryanstout: just looking through the readme again. looks like the templates would cover everything I want to do r.e. bindings
<ryanstout> I need to add an #each_pair hash iterator, but I think most everything else is there
e_dub has joined #opal
dimaursu16 has quit [Read error: Operation timed out]
dimaursu16 has joined #opal
ryanstout has quit [Quit: ryanstout]
elia has joined #opal
e_dub has quit [Remote host closed the connection]
e_dub has joined #opal