adambeynon changed the topic of #opal to: - Ruby runtime and library on top of Javascript | 1.0.0 is near | This channel is logged at
mehowte has quit [Ping timeout: 240 seconds]
adrocknaphobia has joined #opal
DrShoggoth has quit [*.net *.split]
fkchang has quit [*.net *.split]
aflatter has quit [*.net *.split]
harrow has quit [*.net *.split]
aflatter has joined #opal
DrShoggoth has joined #opal
fkchang has joined #opal
harrow has joined #opal
Guest76482 is now known as denysonique
fkchang has quit [Ping timeout: 260 seconds]
ryanstout has joined #opal
e_dub has quit [Quit: It's a hard knock life]
<ryanstout> does string appending via "<<" work in opal? or is that a side effect of immutable strings in JS?
ryanstout has quit [Quit: ryanstout]
e_dub has joined #opal
DrShoggoth has quit [Quit: Leaving]
elia has joined #opal
[spoiler] has joined #opal
adambeynon has joined #opal
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #opal
kludge` has quit [Ping timeout: 272 seconds]
kludge` has joined #opal
GitHub66 has joined #opal
<GitHub66> opal-activesupport/master 98ec90e Elia Schito: Update opal, switch to opal-rspec
GitHub66 has left #opal [#opal]
<GitHub66> [opal-activesupport] elia pushed 1 new commit to master:
<elia> adambeynon, opal-rspec is supercool! :D
GitHub113 has joined #opal
<GitHub113> [opal-activesupport] elia pushed 1 new commit to master:
GitHub113 has left #opal [#opal]
<GitHub113> opal-activesupport/master 14e2ebd Elia Schito: Bump version
GitHub27 has joined #opal
GitHub27 has left #opal [#opal]
<GitHub27> [opal-activesupport] elia tagged v0.0.5 at b818c33:
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #opal
GitHub76 has joined #opal
<GitHub76> [opal-activesupport] svoboda-jan closed pull request #3: Support newer opal versions (master...update_opal_version)
GitHub76 has left #opal [#opal]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #opal
GitHub151 has joined #opal
GitHub151 has left #opal [#opal]
<GitHub151> opal/master 7b56fb2 meh: Cleanup Kernel#loop
<GitHub151> opal/master 90c33cd meh: Cleanup Kernel#methods
<GitHub151> opal/master 82440a4 meh: Cleanup Kernel#define_singleton_method
<GitHub151> [opal] meh pushed 3 new commits to master:
GitHub81 has joined #opal
GitHub81 has left #opal [#opal]
<GitHub81> opal-activesupport/master 8b098fc Elia Schito: Update readme
<GitHub81> [opal-activesupport] elia pushed 1 new commit to master:
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal#1359 (master - b0ae678 : meh): The build was fixed.
<travis-ci> [travis-ci] Build details :
travis-ci has left #opal [#opal]
GitHub70 has joined #opal
GitHub70 has left #opal [#opal]
<GitHub70> opal-rails/master 1f26c02 Elia Schito: Update to opal 0.5
<GitHub70> [opal-rails] elia pushed 4 new commits to master:
<GitHub70> opal-rails/master 4f199e2 Elia Schito: Opal.{parse => compile}
<GitHub70> opal-rails/master becd334 Elia Schito: Switch to opal-rspec
GitHub179 has joined #opal
<GitHub179> [opal] meh pushed 1 new commit to master:
GitHub179 has left #opal [#opal]
<GitHub179> opal/master e258f76 meh: Cleanup Kernel#printf
travis-ci has joined #opal
<travis-ci> [travis-ci] Build details :
<travis-ci> [travis-ci] opal/opal-rails#61 (master - 1b8f573 : Elia Schito): The build has errored.
travis-ci has left #opal [#opal]
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal#1361 (master - e258f76 : meh): The build was broken.
<travis-ci> [travis-ci] Build details :
travis-ci has left #opal [#opal]
GitHub69 has joined #opal
<GitHub69> opal-rails/master cf27e07 Elia Schito: Bump version
GitHub69 has left #opal [#opal]
<GitHub69> [opal-rails] elia pushed 1 new commit to master:
travis-ci has joined #opal
<travis-ci> [travis-ci] Build details :
<travis-ci> [travis-ci] opal/opal#1361 (master - e258f76 : meh): The build passed.
travis-ci has left #opal [#opal]
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal-rails#62 (master - cf27e07 : Elia Schito): The build passed.
travis-ci has left #opal [#opal]
<travis-ci> [travis-ci] Build details :
GitHub183 has joined #opal
GitHub183 has left #opal [#opal]
<GitHub183> [opal-rails] elia tagged v0.6.0 at 12827ad:
<elia> adambeynon, we need a mega blog post on the ton of stuff that has been released
<meh`> adambeynon, I think our #methods is kinda broken
travis-ci has joined #opal
<travis-ci> [travis-ci] opal/opal-rails#63 (v0.6.0 - cf27e07 : Elia Schito): The build passed.
<travis-ci> [travis-ci] Change view :
<travis-ci> [travis-ci] Build details :
travis-ci has left #opal [#opal]
elia has quit [Quit: Computer has gone to sleep.]
<adambeynon> meh`: broke in which case?
<adambeynon> elia: yeap, was thinking something similar
<meh`> >> "".methods.grep(/^[A-Z]/)
<meh`> => ["Array", "Integer", "Float", "String", "Native"]
<meh`> >> "".methods.grep(/^[A-Z]/)
<meh`> => []
<meh`> first is opal
<adambeynon> yeah, thats due to bridged classes. we cant really overcome that limitation
<adambeynon> or not easily, anyway
<meh`> I see
GitHub43 has joined #opal
GitHub43 has left #opal [#opal]
<GitHub43> [opal-rails] boberetezeke opened pull request #12: Update the readme to specify the correct spec directory (master...master)
elia has joined #opal
GitHub168 has joined #opal
<GitHub168> opal/master 31c12c5 meh: Cleanup Kernel#proc
GitHub168 has left #opal [#opal]
<GitHub168> [opal] meh pushed 2 new commits to master:
<GitHub168> opal/master 49ab70f meh: Cleanup and compliancy fixes for Kernel#rand
<adambeynon> meh`: hold off a little on the coerce stuff, Im still not sure its the best way to go
<meh`> adambeynon, it's not compliant without it
<adambeynon> yes, but I dont think some `Opal::Type.coerce_x()` is the best way to go with it
<meh`> adambeynon, we can always change it, at least we have it working now and know where the checks should go
<meh`> adambeynon, I also think native calls should wrap/unwrap
<meh`> or it's useless
<adambeynon> meh`: I don't use Native (nor did I write it), so I dont really mind what happens with it
<meh`> adambeynon, roger
<adambeynon> it makes sense to wrap/unwrap though, yeah
<meh`> doing it
travis-ci has joined #opal
<travis-ci> [travis-ci] Build details :
travis-ci has left #opal [#opal]
<travis-ci> [travis-ci] opal/opal#1362 (master - 49ab70f : meh): The build passed.
<adambeynon> meh`: how much need is there for Native::Array ?
<meh`> adambeynon, quite a lot
<meh`> there are many array-like objects
<meh`> arguments is one
<meh`> and in the DOM API there are a fuckton
<meh`> adambeynon, any way to run opal-repl with phantomjs?
<adambeynon> meh`: no - couldnt figure out a good way to do it
<meh`> snab
<adambeynon> meh`: opal-parser.js can run code from script tags
<adambeynon> if you want a quick browser test of something
<meh`> nah, I can test it another way
<meh`> adambeynon, when are we doing the corelib stdlib move?
<adambeynon> meh`: cant we move Native::Array to opal browser?
<meh`> adambeynon, it's useful outside of it
<meh`> it's not uncommon in javascript to return array-like objects
<adambeynon> I really dont think so. we are not going to start making wrappers for every lib out there
<adambeynon> opal-browser is the exception
<meh`> adambeynon, trust me, it's a common pattern
<adambeynon> fine, but Native::Array isnt something that belongs in opal core
<meh`> why not?
<meh`> it's just few lines anyway, and the pattern is present in the core of javascript
<meh`> arguments is just one example
<adambeynon> why would we ever need to wrap `arguments`?
<meh`> no clue, but there are other examples with stuff like typed arrays
<meh`> they're part of the core language
elia has quit [Ping timeout: 245 seconds]
<adambeynon> so are for and for-in loops, but we dont want to start offering a wrapper for those ^_-
<meh`> it's not the same
<meh`> in javascript you can have array-like objects, and you don't need to care about it being a real or not array
<meh`> because you use a for loop using the length attribute
<meh`> and if it's accessed using other functions on the object
<meh`> you don't care all the same
<meh`> because you use a for loop
<meh`> in Ruby it has to be an Enumerable
<meh`> and Native::Array does it
<meh`> prototypejs had $A that converted array like objects to real arrays
<meh`> but we don't need to create a real array out of it, since we have Enumerable
<adambeynon> so, we are creating an abstraction on top of another abstraction of an array
<meh`> array-like objects aren't an abstraction
<meh`> they're common in javascript
<meh`> for instance, you can pass an array-like object to Function.prototype.apply
<meh`> they're pervasive in the language
<meh`> and it needs a specific wrapper
<adambeynon> right, but I dont get why we need a specific wrapper for those sort of objects in opal?
<[spoiler]> I think jQuery() returns an array-like object
<meh`> adambeynon, because it's pervasive in the language
<meh`> adambeynon, you don't use native, and that's fine, but that doesn't mean it doesn't belong in the core
<meh`> if something is part of javascript, it should be available in some way or another
<meh`> and native wrapping is useful if you don't have or don't want to use a full blown wrapper
<meh`> also what [spoiler] said, jQuery returns an array-like object
<meh`> and it's not just jQuery, it's also in the core of the language
<adambeynon> Native should be a very minimal class: #method_missing, #[], #[]=, #include?
<meh`> it's a pervasive pattern
<adambeynon> thats all we need Native to do
<[spoiler]> Well, it's not very common, AFAIK and I only ever used it twice myself (and I work often with JS). However, I can't see why you need that in opal/ruby
<adambeynon> if you are actually digging deeper, and trying to use these very small parts of javascript like passing array-like objects to slice() and call() and apply() etc, then some wrapper isnt going to help, and its probablly better writing that code in javascript anyway
<meh`> [spoiler], I think you might be dealing with those objects and not realize it :)
<[spoiler]> meh`: I rarely use libraries, though. Got an example where vanilla JS uses those?
<meh`> [spoiler], typed arrays, arguments, most of the DOM stuff
<meh`> the DOM is full of array like objects
<[spoiler]> Oh, I never realised arguments were array-like. I always figured they were just an array
<meh`> nope
<[spoiler]> and typed-arrays is a godo example actually, yeah
<[spoiler]> good*
<adambeynon> so, class TypedArray < Native; include Enumerable; def each; ...; end; end
<meh`> adambeynon, that's not enough, and it shouldn't be a child of Native but include Native::Base like it does now
DouweM has quit [Ping timeout: 260 seconds]
<adambeynon> meh`: thats the other thing, why do we need Native and Native::Base ?
<adambeynon> for general cases
<adambeynon> or extend from Native for custom classes
<meh`> because we had Native::Object
<meh`> and you wanted Native
<meh`> Native was Native::Base before
<meh`> a Native::Object is a full blown wrapper for a native object
<meh`> Native::Base is the contract your class has to fulfill to be treated as a native wrappre
<meh`> *wrapper
<meh`> so #to_n
<meh`> and getting created with a native
<adambeynon> meh`: but lots of objects can act as a native
<adambeynon> Boolean#to_n, String#to_n
<adambeynon> self.is_a?(Native::Base) becomes useless
<adambeynon> as its not a guarantee that its a native
<adambeynon> self.respond_to? :to_n
<meh`> adambeynon, yes, but it's common boilerplate
<adambeynon> much better
<meh`> I don't want to see the same boilerplate everywhere
<meh`> that's what modules are for
<adambeynon> include Native::Base vs def to_n; @native; end
<meh`> and def initialize(native); @native = native; end
<meh`> and you can see what's going on from the start
<meh`> instead of having to look for def to_n
DouweM has joined #opal
<adambeynon> the problem is, Native has become a very complex solution to a very easy problem
<adambeynon> forwarding calls to method_missing
<adambeynon> we cant cover every edge case in javascript
<meh`> adambeynon, you're not seeing it from the right perspective
<adambeynon> otherwise we would need Native::Hash as well
<meh`> you didn't use the native stuff much, did you?
elia has joined #opal
<adambeynon> meh`: no, because I didnt like, not because I didnt need it
<meh`> I work with it every day
<meh`> and Native::Hash has no meaning in js
<adambeynon> In my apps I have a JsObject class which just does the method_missing stuff - its all that is needed
<meh`> while Native::Array does
<meh`> to you
<meh`> you're not using much of the Ruby features
<meh`> boilerplate is bad, constructs in the core should be supported
GitHub104 has joined #opal
<GitHub104> opal/master 16af36e meh: Make Native method calls unwrap arguments and wrap results
<GitHub104> [opal] meh pushed 1 new commit to master:
GitHub104 has left #opal [#opal]
<meh`> adambeynon, you should look at more general cases than your specific ones
<adambeynon> meh`: its also about performance. looking at the code you just comitted now, we are talking about going from 1 js function call into using 20 or 30 to send 2 arguments to an object
<adambeynon> thats not going to be useful
<adambeynon> thats huge performance loss
<adambeynon> custom wrappers are the only decent solution
travis-ci has joined #opal
<travis-ci> [travis-ci] Build details :
travis-ci has left #opal [#opal]
<travis-ci> [travis-ci] opal/opal#1363 (master - 16af36e : meh): The build passed.
<meh`> adambeynon, I'm not following, where's the performance loss?
GitHub178 has joined #opal
<GitHub178> opal-rails/master d22d6aa Steve Tuckner: Merge remote-tracking branch 'opal/master'
GitHub178 has left #opal [#opal]
GitHub142 has joined #opal
<GitHub142> [opal-rails] elia closed pull request #12: Update the readme to specify the correct spec directory (master...master)
GitHub142 has left #opal [#opal]
<GitHub178> opal-rails/master 55195ce Steve Tuckner: fixed sentence that specifies spec directory
<GitHub178> [opal-rails] elia pushed 4 new commits to master:
<GitHub178> opal-rails/master 12c7108 Steve Tuckner: upped versions for opal and opal-sprockets
<adambeynon> meh`: Native, its slow
<meh`> adambeynon, where? you have to wrap natives anyway, how is it slower than wrapping it yourself?
<meh`> Native is supposed to be a general wrapper around any native
<meh`> Native::Array is supposed to be a general wrapper around array-like objects
<adambeynon> how many array like objects are we ever going to deal with? outside of opal-browser
<meh`> adambeynon, typed arrays, arguments, and libraries
<meh`> other libraries outside of DOM libraries make usage of array-like objects
<meh`> adambeynon, all I'm saying is, the fact YOU are not going to use it isn't a good reason to not have it
<meh`> they're supposed to be for general use, not for specific use
<meh`> if you have your stuff wrapped already, you won't use them
<meh`> but that doesn't mean they're useless
<adambeynon> meh`: but we could add a ton of stuff to opal core that im not going to use
<adambeynon> but someone might, one day
<adambeynon> doesnt mean its a good idea
<meh`> adambeynon, the discerning factor is "is it a part of javascript?"
<meh`> are natives part of javascript? yes
<meh`> are array-like objects part of javascript? yes
<meh`> is library X part of javascript? no
<elia> adambeynon, meh`, my take on being in or out of core is will it be frequently used? otherwise it's good for stdlib
<meh`> elia, I wouldn't be against moving Native::Array to native/array in the stdlib
<meh`> but Native is there to stay
<meh`> and I also think the #to_n stuff in the core should include Native::Base
<meh`> for the sake of consistency
<elia> meh`, on the last one I don't agree at all, ruby doesn't do that
<[spoiler]> meh`: I still don't see why they need to be implemented with opal, though
<meh`> [spoiler], which one?
<[spoiler]> "ArrayLike" (do those even have a proper name?) objects
<meh`> they're called array-like objects
<[spoiler]> LOL, that's such an odd name
<adambeynon> array-like objects have no use inside ruby code though. we cant get their benefits inside ruby code, so why treat them differently?
<meh`> adambeynon, they're a matter of bridging
<[spoiler]> Yeah, I keep thinking that. They're useless in Ruby. They can be an Array with a flag (like the proc/lambda business)
<meh`> [spoiler], they can't
<meh`> they have to be wrapped
<[spoiler]> meh`: but aren't they just normal objects with length & splice on them?
<meh`> [spoiler], no
<meh`> they're just objects
<meh`> they don't have any methods
<elia> adambeynon, just to understand, you against having Native::Array in the stdlib?
<meh`> sincerely I don't get all the fuzz, it's just 50 lines
<meh`> and it's part of the native bridging
<[spoiler]> meh`: Well, their prototype must have splice :P
<meh`> [spoiler], no
<meh`> { length: 0 }
<meh`> there', an array-like object
<adambeynon> they are special in js, but not special to ruby, so I dont get why they need their own special ruby wrapper
<adambeynon> it doesnt make a difference to ruby code
<meh`> adambeynon, they need a special wrapper class if they want to be of any use at all
<meh`> again, it's 50 lines, it makes it seamless to work with them and is part of the rest of native bridging
<meh`> why are you so against it?
<[spoiler]> Why can't we just treat them as normal arrays inside Ruby? I mean they *are* array like.
<adambeynon> Im against it because I dont want corelib to become a dumping ground for bits of code that are useful in a very small group of contexts
<adambeynon> thats what stdlib isfor
<adambeynon> or even better, thats what rubygems is for
<meh`> adambeynon, we had the native stuff in a gem before
<meh`> and you realized it was useful
<meh`> do I have to wait for you to hit a place where you HAVE TO deal with array-like objects to realize it's needed?
<meh`> it's not a small group
<adambeynon> meh`: back then it was, when it was a very light and simple wrapper
<meh`> any use of Native ends up requiring to use array-like objects
<meh`> you might not realize it now, but it does
<meh`> even that example in issue #428 requires it
<meh`> and corelib will never be a dumping ground like that
<meh`> native bridging needs to be part of the corelib for many reasons
<adambeynon> meh`: but array-like objects simply do not have any meaning from ruby code
<adambeynon> getElementsByClassName() can be wrapped in a Native
<meh`> adambeynon, what do you mean by that?
<meh`> and it will be unsable
<meh`> #each won't work properly
<meh`> and access will work weirdly
<meh`> and you won't have Enumerable on it
<meh`> you NEED a Native::Array to work with that
<meh`> $$.document.getElementsByClassName("summary").to_ary.length
<meh`> this is the code that will work
<meh`> if you want array-like objects to be usable in Ruby, you need Native::Array
<meh`> Native won't work
<adambeynon> meh`: we cant pretend that working with native objects is seamless, it isnt. Native is there purely as a convenience for very small, simple interactions
<adambeynon> anything more complex needa a wrapps
GitHub54 has joined #opal
<GitHub54> opal/master 69c96e1 meh: Add Native#to_a and Native#to_ary
<GitHub54> [opal] meh pushed 1 new commit to master:
GitHub54 has left #opal [#opal]
<adambeynon> needs a wrapper*
<meh`> adambeynon, I don't think so
<meh`> it doesn't have to be
<adambeynon> meh`, it's the exact reason you have built opal-browser
<adambeynon> simple wrappers dont do the job
<meh`> they do, full blown wrappers are just nicer
<meh`> Native won't get any more complex than that, it does all that is needed
<meh`> just a method_missing as you put it, doesn't cut it
<meh`> it cuts it in your limited usage, but Native has to be general
<meh`> we're running on javascript, that won't change
<meh`> we need a way to wrap natives when we don't have a full blown wrapper
<adambeynon> meh`: we are running a ruby-like runtime on top of javascript. we cant pretend that our ruby is suddenly able to work 1:1 with javascript objects
<meh`> well, guess what, it can now
ylluminate has quit [Quit: Bye!]
<meh`> Native does the right thing in any case
<adambeynon> but in that commit you just pushed
<adambeynon> to_ary
<adambeynon> isnt that better just to create an Array of natives?
<meh`> no, it's slower
elia has quit [Ping timeout: 240 seconds]
elia has joined #opal
<elia> adambeynon, meh`, reprise: put the file into stdlib, that's the right place, that's where fundamental libs like FileUtils and Pathname live
* elia is living
<elia> ouch
<elia> :)
* elia is leaving
<elia> :D
elia has left #opal [#opal]
elia has joined #opal
elia has quit [Ping timeout: 245 seconds]
fkchang has joined #opal
adambeynon has quit [Quit: ["Textual IRC Client:"]]
ryanstout has joined #opal
_whitelogger has joined #opal
jakeblue has joined #opal
<jakeblue> Hi can anyone help me with a javascript question
adambeynon has joined #opal
ryanstout has quit [Quit: ryanstout]
<fkchang> jakeblue: no guarantees I know the answer, but I'll give it a shot
cogitator has joined #opal
<cogitator> Hi there. I have a question while working with Opal. How can you build two Ruby files at once. This " s.main = 'rubycanvaslib' " is only for one?
<meh`> cogitator, the simplest way is requiring the two from the main
<cogitator> What's the syntax, please?
<meh`> I mean having `require 'a'; require 'b'` in rubycanvaslib
jakeblue has left #opal [#opal]
elia has joined #opal
adambeynon has quit [Quit: Textual IRC Client:]
[spoiler] has quit [Read error: Connection reset by peer]
<fkchang> I got bait and switched. jakeblue's question was apparently some js homework
<fkchang> good deed goes unpunished, I guess
<meh`> lol
<cogitator> meh', thanks (a delayed one...), that was it needed.
<meh`> np :)
<meh`> cogitator, but keep in mind it doesn't need a main if it's a library
<meh`> and you might want to contribute to this instead
<cogitator> I am testing it out, but we'll see,
cogitator has quit [Quit: Page closed]