<adambeynon>
I will try and work out those date/time bugs too
<meh`>
adambeynon, yeah, I added some stuff to the 0.5 milestone
GitHub92 has joined #opal
<GitHub92>
[opal-jquery] adambeynon pushed 2 new commits to master: http://git.io/-sCA5g
<GitHub92>
opal-jquery/master 69c58fe Adam Beynon: Support running specs for both jquery and zepto
<GitHub92>
opal-jquery/master 3b61222 Adam Beynon: Slight cleanup of Element
GitHub92 has left #opal [#opal]
DouweM has quit [Quit: Leaving...]
GitHub134 has joined #opal
<GitHub134>
opal-jquery/master 6cacc6f Adam Beynon: Put all spec fixtures under spec/fixtures
<GitHub134>
[opal-jquery] adambeynon pushed 1 new commit to master: http://git.io/bnEl_Q
GitHub134 has left #opal [#opal]
GitHub199 has joined #opal
<GitHub199>
opal-jquery/master 7bde6f1 Adam Beynon: Docs for running specs on Zepto
<GitHub199>
[opal-jquery] adambeynon pushed 1 new commit to master: http://git.io/w2RitQ
GitHub199 has left #opal [#opal]
GitHub140 has joined #opal
<GitHub140>
[opal-jquery] adambeynon created native-v2 (+1 new commit): http://git.io/IaUrkA
GitHub140 has left #opal [#opal]
<GitHub140>
opal-jquery/native-v2 6237439 Adam Beynon: Initial v2 of native
elia has quit [Quit: Computer has gone to sleep.]
<adambeynon>
meh`: playing with rspec now - async tests are going to be tricky as rspec runs everything in turn - it wont wait for async tests to come back
<adambeynon>
so..
<adambeynon>
do you think its acceptable to intercept all async tests, and run them manually?
<adambeynon>
as in, after all the normal tests run, we then run the async tests
<meh`>
yeah
<adambeynon>
meh`: I dont think async specs are going to work in rspec
<meh`>
well, that's a problem
<adambeynon>
the only way I can see around it is to have 2 independant test runners. so it prints 2 lines at the end of your code
<adambeynon>
well, even then it wont really work properly
<adambeynon>
we wouldnt be able to use let() before() or after()
<adambeynon>
which isnt great..
<meh`>
I guess we'll have to keep opal-spec for browser testing
<adambeynon>
:(
<meh`>
well, it wasn't useless work
<meh`>
it showed a bunch of bugs
<meh`>
and it's a good way to say "dude, it just werks"
<meh`>
but without async tests it's pointless in most browser things
<adambeynon>
meh`: think I have found a way around it. If we subclass their Example#run method (just for our async tests), we might be able to get around it
<adambeynon>
*might*
<adambeynon>
we just have to keep an eye on that class incase they ever change how it works
<adambeynon>
which seems to happen quite often looking at their logs
fkchang has joined #opal
eventual1uddha has joined #opal
<adambeynon>
meh`: got it working
<adambeynon>
its ugly
<adambeynon>
but its working
eventual1uddha has quit [Ping timeout: 260 seconds]
<fkchang>
adambeynon: I had an idea driving to work. We could do the lookup for lambda's by name if you can name the lambda's
<adambeynon>
fkchang: for the comments?
<fkchang>
i.e. l = lambda {|i| 2*i}; l.name # <Lambda: 1232>
<fkchang>
and code. I want to be able to edit lambda's I type into opal-inspector as well as the normally defined methods in classes
<fkchang>
so long as everything has a unique name, we can use a hash by name
<adambeynon>
fkchang: would that be lambdas *just* typed into the opal-inspector panel?
<adambeynon>
or all lambdas?
<adambeynon>
as in, from anywhere in the code
<adambeynon>
also, do you mean just lambdas, or also procs?
<fkchang>
I think the same would work for either. For all the lambda's typed in to code, I store all things evaluated so that I would have easy access to them
<fkchang>
are u doing lambda's and proc's differently in opal (i always have to read up to remember the differences)
<meh`>
fkchang, the only different is #call
<meh`>
*difference
<meh`>
and #lambda?
<adambeynon>
fkchang: problem with keepting all lambdas is that they will never be garbaged collected
<adambeynon>
and in ruby, there are a lot of procs/lambdas
<adambeynon>
however
<adambeynon>
ones typed into opal-inspector should be easy
<fkchang>
adambeynon: that's acceptable
GitHub57 has joined #opal
GitHub57 has left #opal [#opal]
<GitHub57>
[opal-rspec] adambeynon pushed 1 new commit to master: http://git.io/W5w2eQ
<GitHub57>
opal-rspec/master a95cd0b Adam Beynon: Initial commit for supporting async specs under rspec
<adambeynon>
meh`: any thoughts/suggestions/improvements for the async api would be appreciated as well
<adambeynon>
those changes use the same idea as opal-spec
<adambeynon>
I did think about adding some `default_timeout` option
<adambeynon>
to stop specs just breaking when we dont use `run_async` correctly
<meh`>
adambeynon, I was fine with API of opal-spec for async specs
<meh`>
what I didn't like is it didn't throw errors if something failed in the spec body
<meh`>
so catch those errors
<meh`>
and fail the spec if something bad happens
<meh`>
I had to keep changing it from async to sync to find what was going wrong
<adambeynon>
meh`: ah, didnt realise that was happening. I will double check to make sure it works
<meh`>
thanks
<adambeynon>
meh`: it is worth noting that we wont be able to capture anything that happens outside the block
<meh`>
adambeynon, that is fine
<meh`>
often I just fucked up the startup of the block
<meh`>
and didn't see anything happening, at all
<adambeynon>
meh`: just wondering actually if something like `window.onerror` works cross browser now - might make it all a bit easier to handle outside errors
<meh`>
heavily doubt it
GitHub79 has joined #opal
<GitHub79>
[opal-rspec] adambeynon pushed 1 new commit to master: http://git.io/DqKgEQ
<GitHub79>
opal-rspec/master 03f5d2e Adam Beynon: Add spec to test async examples can fail before async block reached
GitHub79 has left #opal [#opal]
<adambeynon>
ok, asynx examples can fail like any other example now