<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
<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
<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
<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
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
<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>
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