<GitHub47>
[opal-sprockets] elia pushed 2 new commits to master: http://git.io/Jpt8Hg
GitHub82 has joined #opal
<GitHub82>
[opal-rails] elia pushed 1 new commit to master: http://git.io/syWhuA
<GitHub82>
opal-rails/master b09d5f0 Elia Schito: Add the sourcemap route only if they're enabled
GitHub82 has left #opal [#opal]
<adambeynon>
elia: could be, yeh
<adambeynon>
I'll come back to it. forcing them over http could be an option
<elia>
adambeynon: you said some time ago there was something ready for serving them over http
<adambeynon>
elia: yeh, I seem to remember having this problem before. If it is indeed the file:// vs http:// problem, then I could just post this fix
<adambeynon>
meh`: which browser do the maps work for you in?
<meh`>
adambeynon, chrome
<adambeynon>
which version?
<meh`>
29
<adambeynon>
hmmm, wonder why they dont for me..
<adambeynon>
maybe a setting somewhere..
<adambeynon>
the wrong line numbers should be fixable - just a bug in the line counting in source_map.rb
<elia>
adambeynon: back to the basics, check if they're enabled!
<adambeynon>
elia: triple checked! :P
<adambeynon>
well, pushing maps over http isnt a problem anyway, and probably the way to go. exposing the dir structure in maps probably isnt a great idea
<GitHub2>
opal/master 8434825 Adam Beynon: Group all #to_n methods under native/ext_spec
GitHub20 has joined #opal
GitHub20 has left #opal [#opal]
<GitHub20>
opal/master f865b51 Adam Beynon: Support %i() as an alias for %w()
<GitHub20>
[opal] adambeynon pushed 1 new commit to master: http://git.io/7ZNYjw
<adambeynon>
There we go. I haven't added specs for it yet, as Im not sure where to put them.
elia has joined #opal
GitHub185 has joined #opal
<GitHub185>
[opal] adambeynon pushed 1 new commit to master: http://git.io/4X76kQ
GitHub185 has left #opal [#opal]
<GitHub185>
opal/master b44aa64 Adam Beynon: Use each_with_object() in code gen. ftw
<adambeynon>
meh`, elia : In the interest of being able to debug generated code, I think Im going to fix and merge in the branch where blocks are passed as the last arg into methods
<meh`>
adambeynon, is it any slower?
<adambeynon>
meh`: same. we take the 2 extra asignments "outside" the method call, and change them to two assignments inside the receiver method
<meh`>
adambeynon, fine by me then
<adambeynon>
is arguments.callee considered a no-go? I seem to remeber them talking about removing it
<adambeynon>
remember*
<adambeynon>
eek
<adambeynon>
Warning: The 5th edition of ECMAScript forbids use of arguments.callee() in strict mode.
<adambeynon>
thats a no-go then
<fkchang>
adambeynon: how's your schedule these days and near future? Would like to see the "storing code/comments " parser addition to continue work on opal-inspector. I'd be glad to actually help, but would want to solifidy the API and the basic approach
<meh`>
mh
<meh`>
what the
<meh`>
adambeynon, anyway, please don't merge master in master
<meh`>
use rebase
<meh`>
git pull --rebase does the trick
<meh`>
you always fuck up the git history otherwise :(
<fkchang>
adambeynon: Need to the parser to store the code (first) and comments (later? ) with a code so that we can pull the code for any class or method up in the inspector. I would want to enable this on both server side parse as well as browser side parse. I imagine there is overlap w/source mapping, so some unifying api would be preferable. Let me step you through a use scenario. Deploy my app, hit the page, open opal-inspector. Browse
<fkchang>
through the classes, find the one I want, pull it up. mess w/stuffin the inspector/irb, change the code in the browser (coz it's all accessible), etc.
<meh`>
adambeynon, there's still a problem with inheritance
<fkchang>
So an option to store this stuff, possibly via a Parser subclass might make sense
<fkchang>
Would want to be able to edit in the browser and then send it back to the server - have brainstormed a few schemes on that, but utlimately just need to store corresponding code
<adambeynon>
fkchang: that all sounds relatively straight forward
<adambeynon>
we can just dump it all in a json format
<adambeynon>
meh`: but sprockets doesnt always compile the files in the right order. it compiles them all, builds its own graph of what needs what, and then combines them
<adambeynon>
well, it doesnt always combine them
<adambeynon>
just makes an ordered list of what file must load first
<meh`>
adambeynon, can't we force some kind of ordering?
<meh`>
I think we can
<meh`>
we just have to do the dependency tracking ourselves
<meh`>
and it's fairly simple if we follow the Ruby semantics
<adambeynon>
meh`: dependency tracking is simple, but making that interact with sprocket's render pipeline would be difficult
<fkchang>
adambeynon: If it seems straight forward, that's good news. JSON is fine. Certainly an overlap in functionality w/source maps. I'd probably start w/a basic implementation and see what falls out for the various edge cases like dynamic definition. Can you have def store the code?
<fkchang>
or define_method, etc..
<meh`>
adambeynon, I think it's worth it
<meh`>
adambeynon, I could look into it
<meh`>
if you're not in the mood for it
<adambeynon>
meh`: I dont think its a good approach long term. we would be hacking away at sprockets, which is already very fiddily. if they introduce a small change, it could break our pipeline completely
<adambeynon>
if you can find a good way, I would support that
<adambeynon>
but from my experience with sprockets, I would say it is very hard to do
<adambeynon>
fkchang: I will make a small demo of it, and you can see what does or doesnt work
<travis-ci>
[travis-ci] opal/opal#1035 (master - 8f800db : Adam Beynon): The build was fixed.
<meh`>
I'm working on gradients now
<meh`>
fkchang, I'm making it so it outputs vendor prefixes too
<meh`>
it already does for border-radius and box-shadow
<fkchang>
definitely very sexy
<fkchang>
you have a sample app w/lissio?
<meh`>
not yet
<meh`>
I can make one before november if you need it for rubyconf
<fkchang>
that would be useful, also useful in learning how to use it, the specs are pretty sparse
<meh`>
yeah, it's still under heavy development
<meh`>
my plan is to have a sample app and documentation for lissio, and documentation + released gem for opal-browser in time for rubyconf
<fkchang>
nice, it'll definitely get some air time in my talk
e_dub has quit [Quit: It's a hard knock life]
e_dub has joined #opal
elia has joined #opal
e_dub has quit [Quit: It's a hard knock life]
ylluminate has joined #opal
elia has quit [Quit: Computer has gone to sleep.]
<meh`>
did anyone try if opal runs on IE7?
<meh`>
let the fun begin =_=
elia has joined #opal
<meh`>
elia, fkchang, what do you think is the minimum IE version opal-browser should support?
elia has quit [Quit: Computer has gone to sleep.]
<fkchang>
meh`: good question, I guess I'd start w/a variant of your question, what's the lowest IE that will support opal, and work from there. My inkling is to start at IE8
<meh`>
fkchang, as far as I can see, opal works on IE7
<meh`>
I have to check what's the market share of IE7 in Italy
<meh`>
I refuse to go below IE7 anyway
<meh`>
the choice lies between IE7 and IE8
elia has joined #opal
adambeynon has joined #opal
_elia has joined #opal
<_elia>
meh`: im back
<_elia>
meh`: I think you have two choices
<meh`>
adambeynon, opal-browser IE minimum support
<meh`>
adambeynon, throw me your thoughts
<_elia>
1. stay on par with jquery
<_elia>
2. stay on par jquery 1.9
<_elia>
:)
elia has quit [Ping timeout: 246 seconds]
<meh`>
elia, yeah, I know
<meh`>
adambeynon, but I guess that question also becomes, what's opal's minimum IE version? :)
<_elia>
meh`: having opt-in support for older IEs (say lt9) would be optimal imo
<meh`>
_elia, that's what I'm doing
<meh`>
well, it's not really optional
<adambeynon>
meh`: opal itself should work with ie6+
<meh`>
but it could be easy to make optional
<meh`>
adambeynon, ok
<meh`>
then opal-browser too
<adambeynon>
you would need json2.js for json, but apart from that...