<travis-ci>
[travis-ci] opal/opal#943 (master - 5ec2bdf : Adam Beynon): The build passed.
<DouweM>
I'm asking because, for example, Array#[]= isn't implemented right either, and there's no rubyspecs or bug filters for that one
<adambeynon>
DouweM: Im working today to add as many as possible. Up until now, its been a case of adding methods/specs as I have needed them
<adambeynon>
the plan would be to link against rubyspec directly
<adambeynon>
and have a load of filters that are a guide to what works, and what doesnt
<DouweM>
right
<adambeynon>
also, we are splitting them into "bugs" and "unsupported"
<adambeynon>
we wont ever support threads, for example
<adambeynon>
DouweM: also, we have been bad sometimes at adding methods with no specs at all
<adambeynon>
really, any new methods should only be added with the relevant specs from rubyspec
<DouweM>
so the new plan is to add all of the rubyspecs, label them as not_implemented, bug or unsupported, and slowly go about removing the not_implemented and bug labels?
<DouweM>
by implementing/fixing them of course
<adambeynon>
exactly that
<DouweM>
cool
<adambeynon>
it is also fair to say that quite a few filters can be removed, as they have been fixed and not updated
<DouweM>
which answers my question that I don't need to file an issue about Array#[]= now because it'll be caught by the rubyspecs anyway
<adambeynon>
well, im working on Array specs now, so I will check out #[]= now to get that working as expected
<DouweM>
all right
<DouweM>
how are you implementing most of these anyway? going off the rubyspecs, the docs, the MRI implementation, the Rubinius implementation, or a combination of those?
<adambeynon>
mostly just implement the basic structure of a method based on my knowledge of how it works, and then usually the rubyspecs highlight any corner cases which are broken
<adambeynon>
rubinius is sometimes useful for more complex alogorithms
<adambeynon>
rubyspec is very good though at covering the entire workings of a method
<DouweM>
yeah, rubyspecs are grea
<DouweM>
t
<adambeynon>
oh wow, I see what you mean about Array#[]=
DouweM has quit [Read error: Connection reset by peer]
DouweM has joined #opal
meh` has joined #opal
<meh`>
adambeynon, yo
<adambeynon>
meh`: morning!
<meh`>
what's up?
<adambeynon>
bug fixing day!
<meh`>
nice
<meh`>
will you try to fix the blankslate stuff too?
<adambeynon>
well, it requires needing a way to enable/disable method_added
DouweM has quit [Read error: Connection reset by peer]
<meh`>
it should be on by default tho, right?
<meh`>
I mean, you shouldn't be defining methods in a loop or something
<adambeynon>
meh`: well, we cant have it turned on in corelib, as it won't have been defined by then
<meh`>
adambeynon, yeah, I meant for user code
GitHub161 has joined #opal
<GitHub161>
opal/master 087cc6a Adam Beynon: Fix rubyspecs for Array#[]= accepting index or index, size
<GitHub161>
[opal] adambeynon pushed 1 new commit to master: http://git.io/eqhvvQ
GitHub161 has left #opal [#opal]
<adambeynon>
meh`: yeap, but the parser (currently) treats corelib just as any other code, so we need a way to turn certain features on and off
<DouweM>
adambeynon: opting out rather than opting in makes sure the not_yet_implemented/bug lists are complete
<DouweM>
adambeynon: which makes it easier to just look through those files and start fixing stuff
<meh`>
that is true
<DouweM>
it also makes it easier for you guys to check that every pull request that says it fixes something also removes one or more lines from those tag files
<adambeynon>
true, but there is a huge amount of specs that we dont currently attempt to pass
<adambeynon>
a load of stdlib stuff
<meh`>
adambeynon, I think it's worth it
<meh`>
we can tag those specs as "doesntmakeanysense" or something :P
<meh`>
so people know what to expect and what to not expect
<adambeynon>
I suppose we can opt-out on whole files as well then..
<adambeynon>
and directories
<meh`>
yeah
<DouweM>
adambeynon: sure
<DouweM>
Does mspec support tags on the describe blocks, like RSpec does? then doing`describe Thread, unsupported: true do ... end` would exclude that entire suite
<adambeynon>
I *think* it does it on the entire spec name
<adambeynon>
describe_name + it_name
<adambeynon>
well, that is how our filters work
<adambeynon>
and it was the only way I could see
<adambeynon>
but, I could well be wrong...
<DouweM>
adambeynon: yeah, that's your filters. but adding unsupported: true and broken: true to individual describe/it blocks is also supported in RSpec at least
<DouweM>
although
<DouweM>
that won't work with the imported submodule
<DouweM>
yeah, an irb with multiline support is a must. I've been using opalrb.org/try to look for bugs, which obviously doesn't have my modified code and which has some problems of its own to boot
<meh`>
you have a top level component which is called an application
<meh`>
and you combine components and render them
<meh`>
so a Menu will be a component as a Tooltip is a component
<meh`>
the logic and the view is tightly coupled within the component
<meh`>
let's say you have a MenuItem component
<meh`>
it can have a tooltip doing something like @tooltip = Tooltip.new(self)
<meh`>
and it can be activated, so it will be rendered when hovered or whatever
<meh`>
I'll see how it goes
<elia>
meh`: tabs ftw
<DouweM>
meh`: I don't really see the difference with Views in Backbone's interpretation
<meh`>
DouweM, not much, except more magic will be going on and they aren't really views
<meh`>
DouweM, I mostly disagree with calling them views
<DouweM>
:)
<meh`>
because then you wouldn't see a tooltip as a view
<meh`>
so what do you make of it?
<meh`>
but yeah, bikeshedding
<adambeynon>
meh`: does a component relate 1:1 with a dom element?
<DouweM>
well, if a view is an element with related logic, a tooltip is still a view
<DouweM>
I have a PopoverView in Backbone
<meh`>
adambeynon, yes, a component has always a root dom element
<DouweM>
that's different of course from views in Rails (which are just templates) or views in, say, iOS, which don't wrap logic, but views in the Backbone interpretation seem to be what you call components
<meh`>
DouweM, yes, it's just weird to call them views when they're also controllers
<DouweM>
meh`: sure
DouweM has quit [Read error: Connection reset by peer]
DouweM has joined #opal
GitHub183 has joined #opal
<GitHub183>
[opal] adambeynon pushed 3 new commits to master: http://git.io/t16GoA
<GitHub183>
opal/master c1de15a Adam Beynon: Convert some core/array specs to use rubyspec
<GitHub183>
opal/master 366b109 Adam Beynon: Merge branch 'master' of github.com:opal/opal
GitHub183 has left #opal [#opal]
<GitHub183>
opal/master 996e877 Adam Beynon: Move most of Array specs over to rubyspec
travis-ci has joined #opal
<travis-ci>
[travis-ci] opal/opal#950 (master - 996e877 : Adam Beynon): The build passed.
<travis-ci>
[travis-ci] opal/opal#951 (master - 047b8ef : Adam Beynon): The build passed.
<DouweM>
and we're not loading the other half becaues they don't work at all? too much work to add filters for all of them?
<adambeynon>
DouweM: a mixture, 50/50. some need a very small fix to get them working, and others we might not have implenented at all
<DouweM>
I understand, but you say "we are currently only loading about half the files from core/array", why don't we load the other half as well (because we want to support it at some point) and then just add fails filters?
<DouweM>
and in that case, we could just use core/array/**/*
<meh`>
I agree with DouweM
<DouweM>
:P
<adambeynon>
thats the next step. I need to check up on how to block entire describe blocks to save adding 10 - 20 fails for each method we dont implement
<DouweM>
adambeynon: ah, right
<adambeynon>
but yes, hopefully by tonight we will just have `core/array/**.*`
<adambeynon>
well
<DouweM>
perfect
<adambeynon>
if I had typed it right, anyway
<DouweM>
hah. what timezone are you guys in anyway?
<adambeynon>
BST (not that it feels very much like summer here...)
<meh`>
DouweM, UTC+1:00
<fkchang>
adambeynon: how do u turn on line numbers in comments?
<fkchang>
adambeynon: so do I have to wrap all js objects in Native() now? My use of codemirror is also broken
<DouweM>
elia: native_class makes an Opal class a native class, native_alias makes a native method an Opal method. they do opposite things but have the same name.
<DouweM>
elia: how about alias_native instead, like alias_method ?
<DouweM>
alias_native :has_class? :hasClass looks nice to me
<DouweM>
alias_*method* :x, :y makes x an alias of the *method* y, alias_*native* :x, :y makes x an alias of the *native (method)* y. the more I think about it, the more sense it makes to me
<meh`>
DouweM, we already have alias_native
<DouweM>
ooh
<meh`>
both in Module and Native::Base
<DouweM>
oh shit
<DouweM>
native_alias actually does the opposite of what I thought it did
<DouweM>
so it's already named correcrtly
<meh`>
yeah, it was confusing to me too :)
<DouweM>
carry on folks :P
<DouweM>
elia: in that case, why isn't there a bang at the end of native_alias?
<DouweM>
only now do I see that mere lines above the native_alias there is the alias_native I was thinking of :P
elia has quit [Ping timeout: 264 seconds]
<DouweM>
bye elia
<meh`>
adambeynon, ping
<adambeynon>
ping pong
<meh`>
adambeynon, if I do a toplevel return it will work properly, right?
<meh`>
or maybe it doesn't even work in ruby
<meh`>
maybe break
<adambeynon>
in ruby it raises a LocalJumpError
<meh`>
nope
<DouweM>
doesn't work in ruby, from IRB anyway
<meh`>
I don't want to wrap it in an if :(
<adambeynon>
whats wrong with if? :)
<meh`>
nothing
<meh`>
fucking requires
<meh`>
FUCKING REQUIRES
<meh`>
adambeynon, fix this shit :((((
<meh`>
the order always fucks with me
<DouweM>
fucking requires stamina?
<adambeynon>
its going to be tricky, probably not possible with sprockets
<meh`>
adambeynon, it's a must
<meh`>
for real
<meh`>
most gems will fail
<meh`>
we don't want that
<meh`>
do we?
DouweM has quit [Read error: Connection reset by peer]
<meh`>
at least the compatibility layer will be clean
<meh`>
one file per method
<meh`>
"clean"
<meh`>
cleaner than the javascript messes
<adambeynon>
yep
<fkchang>
adambeynon: if it's possible, I thought it was an option, it makes it easier to go back to the opal code in question, though I'll say the generated js looks better than when I last looked at it alot
<adambeynon>
and then we can have nice dom programming
<adambeynon>
fkchang: we can add it back I suppose, but I felt the new js is easier to read
<adambeynon>
but
<adambeynon>
if you find it useful
<adambeynon>
I did think about adding the line comments at the start of each line
<adambeynon>
/*1*/ $opal.class('foo', …)
<adambeynon>
/*2*/ def.$foo ...
<adambeynon>
etc
<adambeynon>
instead of all intermingled in the actual javascript
<adambeynon>
or maybe at the end
<meh`>
I vote for the end
<meh`>
no
<meh`>
I vote for the beginning
<adambeynon>
sure? :P
<meh`>
yes
<meh`>
I want to feel like I'm reading FORTRAN again
<adambeynon>
vintage
GitHub171 has joined #opal
<GitHub171>
[opal] adambeynon pushed 1 new commit to master: http://git.io/5X-ZFg
GitHub171 has left #opal [#opal]
<GitHub171>
opal/master 5244182 Adam Beynon: Cleanup more filters for array and enumerable
<adambeynon>
ok, we are getting a handle on our rubyspecs now
DouweM has quit [Read error: Connection reset by peer]
<fkchang>
meh`: I do like it. The ability to do it all in ruby is compelling
<fkchang>
though css and html modes can be pretty nice
<meh`>
the css and html calls are just wrappers for the CSS::Builder and DOM::Builder in opal-browser
<fkchang>
nice
<meh`>
I also added support for deferred event registration like jquery does
<meh`>
I couldn't understand how jquery did it tho
<meh`>
so I did mine with MutationObserver
<fkchang>
how ready is Lissio for use outside of you
<meh`>
not ready at all
<meh`>
I'm working in tandem on the project and lissio, and opal-browser
<meh`>
but it will all be ironed out before rubyconf
<fkchang>
The code looks good, it'd make some pretty compelling slides for rubyconf, esp. if I can do some live mucking w/the code
<meh`>
now that you say that
<meh`>
it gives me a good idea
<fkchang>
what's that?
<meh`>
just minor details, right now if you call css twice, it just adds the css, twice
<meh`>
I'm making it so it deletes the previous style
<meh`>
also on/offing on the component events too
<fkchang>
it's my intent w/opal-inspector to be able to modify stuff like that live in the browser and see the changes right there
<meh`>
yeah, I'll keep an eye on making it seamless with lissio
<fkchang>
how much work do you think lissio needs before someone else can use it? I want to re do opal-inspect w/some sort of dom builder
<meh`>
lissio just leverages opal-browser
<meh`>
but not much work I think, most of it goes in opal-browser
<meh`>
mostly ironing out what Component might need, and then work on Model
<meh`>
but yeah, this weekend I'll write documentation for opal-browser
<meh`>
it has a lot of good stuff
<meh`>
fkchang, if you replace `css &block` with `CSS &block` you get the same thing
<meh`>
it's automatically added to the tree tho
<fkchang>
maybe I'll start w/opal browser and refactor to lissio, though I have to get opal-irb all working w/more recent versions of opal
<fkchang>
removal of seamless bridging will hit me
<meh`>
html is the same thing basically
<meh`>
DOM { div.home { i.icon[:home] } } would give you back the DOM
<meh`>
it doesn't add it anywhere in that case
<meh`>
fkchang, in what timezone are you?
<fkchang>
Pacific time
<fkchang>
GMT+9
<fkchang>
GMT+8
<fkchang>
man, everytime I'm away from opal and come back, everything's broken. My specs don't run, and I forget what I did last time to get everything working
<meh`>
the fun of living on the edge
<meh`>
fkchang, expect less breakage in the future, if you didn't notice adam started the move to a rubyspec submodule
<meh`>
it'll be waaaay easier to check for broken specs and fix them