This is really a must for debugging, not all browsers report syntax errors on included scripts, so we should really check the compiled code for them and raise a parse error.

We could either write our own javascript parser or use therubyracer to do a simple check. We should also be able somehow to infer the originating Ruby line.

This is required because it's really easy to write buggy inlined js (forgetting parenthesis and the like) and it would result in a LoadError when requiring said code.

What I mean is, I want to use the call-me gem inside opal-browser, it's a pure Ruby gem so it should work without any changes with Opal, right now we're checking for /^opal-/ so, any good way to achieve this?

Currently Builder must use a Gemfile to build a project. This should be simplified so that the Gemfile is only needed to build dependencies of the app/gem. The rake task should be sufficient to build a standalone app/gem.

Replace special :BLOCK_GIVEN lexer token and treat it as a normal method call. The generator nodes should handle its special case instead of the parser.

Shouldn't it add a return to the last statement in the generated js?

Having to do

def title
  `return document.title`
end

is kind of ugly and unexpected for a rubyist instead of

def title
  `document.title`
end

> opal
>> ?l
/home/meh/.rvm/gems/ruby-head/gems/opal-0.3.15/lib/opal/parser/parser.rb:98:in `rescue in parse':  (Opal::OpalParseError)
parse error on value "?" ("?")
from parsing (irb):1

So yeah, it's completely missing I guess.

Currently, opal has its own racc based parser for the lexing and parsing stage. Instead, opal should use ruby_parser, a ruby lib used to parse ruby code into s-expressions. The ruby_parser branch is the workings of doing this.

This new branch should also run in the browser, so we need to make sure ruby_parser is fully working with opal.

Block args should be nil by default, in both normal mode AND debug mode.

They are currently null/undefined.

Currently break is implemented on top of throw to bubble a break up to the method that yielded the respective block. This is slow. It can be optimised by having break just return a special value out of the block and then each yield call should just check the return value to see if it is the break instance.

undefined can be set to something else, as in, undefined is a valid variable name, we should find a way to avoid redefinition of undefined.

The best way to go with this is to add var undefined at the beginning of each function, or find a better way to avoid cluttering up everything.

#$0 doesn't interpolate.

Opal.object?, true if the object is a Ruby object, false otherwise.
Opal.native?, true if the object is not a Ruby object, false otherwise.
Opal.string?, true if the object is a JS string (or a Ruby string).
Opal.number?, true if the object is a JS number.
Opal.function?, true if the object is a function.
Opal.defined?, works like Ruby #defined? but uses typeof to do its job.
Opal.undefined?, checks if the value is undefined.
Opal.null?, checks if the value is null.
Opal.typeof, same as typeof.

I'm building to build/ and it fails if it doesn't exist.

I think we should implement various cloning methods, they would really come in handy.

Some inspiration: http://oranlooney.com/deep-copy-javascript/

/discuss

Currently subclassing arrays breaks because subclass instances wont be real js arrays, therefore their length property will not update to reflect the true length. To fix this, js arrays will be instances of NativeArray, which is a ruby subclass of Array. NativeArray will re-implement all the methods that need auto updating .length properties with methods that assume they can update. This means that subclassing Array in ruby will give you methods that will check for the length property in relevant methods, and NativeArray will keep native js arrays nice and fast.

To summarise; NativeArray will re-implement around 10 Array methods that will fix this gap (and be faster than checking .length each time).

Debug mode supports method_missing, but normal mode doesn't. method_missing is too slow to be on by default, so it will need to be opt-in as an option in the Rakefile for the gem/app.

For instance, $/ is needed in String#chomp.

We should really add those before 0.4.

As the title states.

commit 868146147

opal/examples/browser $  bundle exec rake opal --trace
** Invoke opal (first_time)
** Execute opal
rake aborted!
wrong number of arguments (1 for 0)
opal/opalite/opal/builder.rb:71:in `initialize'
opal/opalite/opal/rake/builder_task.rb:37:in `new'
opal/opalite/opal/rake/builder_task.rb:37:in `block in define_rake_task'
Tasks: TOP => opal

Currently, when compiling a method that accesses an instance variable, the ruby method:

def title
  @title
end

Will compile into (roughly) the following javascript:

function() { var self = this; if (self.title == undefined) { self.title = nil; }
  return self.title;
}

This if check is needed as returning a non-initialised instance variable should return nil. The check is needed every time the function is run as the opal compiler has no idea when it will first be run.

Proposition

The proposal is to, at compile time, gather a list of all ivar accesses inside a class and then on class definition set all these properties to nil on the prototype chain for the class constructor. This means that at runtime all instances of a class will have these ivars already set to nil.

Inheritance

As opal uses prototype inheritance anyway, these ivars will be carried into child classes as well.

Kernel#instance_variable_{get,set,defined?}

Using hasOwnProperty, the runtime can determine whether these ivars have actually been set, or have been carried through the prototype chain.

Benefits

The benefit would be, firstly, cleaner generated code which makes opal easier to debug. Secondly, method accessors using ivars will be faster as they will not need to check on property existence on every call. Finally, the reduced size of the generated javascript has obvious benefits.

New generated code:

function() { var self = this;
  return this.title;
}

opal.js contains the runtime and core library built for the browser. Currently it measures at:

Raw: 124,141 bytes
minified: 56,707 bytes
gzipped: 12,735 bytes

The aim is to cut this just short of half in size to make opal as small as possible. The aim is to make opal.js 40kb to reduce the overhead considerations for mobile devices.

The speed_over_features branch should hold this. This issue is to hold any broken parts that arise from changes.

First change set: a9e2053

#to_native should be the default way to get a native object from a Ruby object.

Object#to_native should return a JS object with the object instance variables as elements.
Array#to_native should return a map of self with #to_native called on every element that is a Ruby object.
Hash#to_native should return a JS object with as values #to_native called on every element that is a Ruby object.
NilClass#to_native should return undefined.

It doesn't interpolate inside regexes.

It fails to leave chars unescaped inside regexes.

// should be converted to new RegExp("") or /(?:)/ because // is a comment in js.

A parsing issue indeed.

The js based parser (dev in core lib) should be removed and the opalite parser (ruby written + racc) should be compiled into js so that it runs inside browser. mass-args not causing it to compile correctly.

rake opal

gives this error

to work around it, I have to create extras/opal.js by hand

I get this error trying to run the browser demo in Chrome

Right now you have to provide the needed stdlib in the Rakefile.

As the title states.

I'm not so sure how much using js strings as symbols would improve speed.

While implementing some corelib stuff I noticed the absence of real symbols is making some methods implementation impossible.

In short, we should benchmark speed of both, and I sincerely would prefer to have Symbol back.

Symbols are a really important part in Ruby, it would be like disabling operator overload, a lot of libraries won't work and won't be able to be patched, because Symbol and String are the same thing.

I also am not really sure about the caching of strings improving our speed.

Which should be something on the lines of (function () { return this; })() in global scope, in this way you can easily access global constructors and such.

For instance, I need it in typed-array, where I build a string with the name of the array constructor and I'd have to use eval to get it, or use window which is only in the browser's scope.

I'll do it.

Debug mode should generate code for every method that checks if the correct number of arguments were given to the method. Default/production mode should not generate this code.

This depends on the new parser rewrite and runtime cleanup.

Add support for 1.9 style hashes

Add compiler/runtime support for masgn args (a, b, c = some_call etc).

Currently Opal needs to wrap any native js construct (arrays, jquery instances, custom libraries etc) so they can be accessed in a ruby way - i.e. so we still get method_missing, "getter" and "setter" methods, operator overloading etc. Opal still needs a proper way to interact with js objects without using the backtik approach.

One solution is to use the :: construct to access javascript properties. For instance, to get an array length using its native length property, we could use:

[1, 2, 3, 4]::length           # => compiles to [1, 2, 3, 4].length

Instead of the method call version:

[1, 2, 3, 4].length             # => compiles to [1, 2, 3, 4].m$length()

Another approach is to make it obvious that we are running directly on top of javascript, and maybe make an "opalscript" branch which is more of a ruby syntax for javascript, rather than a ruby runtime on top of javascript. Method calls would follow perhaps Coffeescript's style where a call without args and parans is simply a property access.

Thanks ruby_parser, but no thanks.

When looking up constants in a class/module, the wrong scope is checked. const_get is used for all scope lookups, but really there should be an addition const_at function for checking just in the required context. For example, A::B, where A is looked up using const_get, but B should be looked up using const_at, where the search is more specific and does not bubble up to top level namespaces.

While implementing the wrapper for XHR I found out there's an easy way to transfer and work with binary data, and it uses typed arrays.

So I started working on a bridging implementation.

Will report back on IRC to ask for some assistance in the class bridging operation.

It will also give (me) the chance to implement really fast wrapping stuff, it's also needed in WebGL.

how can i see object like jQuery, prototype, backbone in opal?

Constant lookup should be done on scope instead of superclass chain. Makes constant lookup much faster (based on prototypes).

Opal example works fine for me but if I try precompile ruby code (browser.rb) I get this error:
$runtime is not defined (in precompiled browrser.rb, I called browser.js)

I use HTML code like this:

<script src="../../extras/opal.js"></script>
<script src="../../extras/opal.dev.js"></script>    
<script type="text/javascript" src="browser.js"></script>

I've tried removing opal.dev.js, I've tried rquery.js (from homepage) but I always get the same error.

Any help? Thank you in advance.

Would like to discuss pros & cons of partially compatibility with the standard Ruby. As far as I understood there are no plans to do it 100% compatibile, if so - maybe it's worth to leverage this fact and turn lemons into lemonade.

This is not proposals, but just a rough thoughts and ideas, would like to see what do You think about it.

1. Inheritance & Object Model:
   Maybe it's worth to leverage native JavaScript prototypical inheritance (with fixed self and added method_missing & super)?
   If this stuff will be fixed and it will be nicely wrapped - it may also be quite powerful and handy model.
   After all the Ruby Object Model is not an ideal (it doesn't support multiple inheritance for example).
   I'm personally would be quite satisfied with (fixed) JavaScript Prototypical model.
   And it probably gives more simple implementation code and better performance.
2. Global variables:
   During 3 years of ruby I never used all this cryptic perlish stuff like $1 $&amp; $:< and so on. Also I never used global variables at all.
   In almost all situations they can be easily replaced with constants & singletons. Is there a need for this stuff?
3. Maybe it's wort also to drop the Symbol class. I mean - leave the Symbol syntax(it's quite handy) but make it to define String instead of Symbol (because the only point of introducing it in Ruby was performance, but because in JS strings are immutable - there's no point of using it here).

There are some quite successful projects using this approach (CoffeeScript, Mirah, Boo).

This is only my subjective and personal opinion, and would be interesting what do You think about it?

Module#define_method_bridge (target, name, alias = nil), defines a method that bridges arguments to a native js function.

Module#attr_accessor_bridge (target, *names), defines accessors to the target native attributes, same goes for reader and writer.

I sincerely think Native should be in the corelib, same goes for the stuff I'm doing for typed arrays.

Practically all wrapper libraries will use Native and it's small anyway.

I think corelib should contain language related things, while stdlib should contain stuff that has nothing to do with the language itself.

Wanting to reduce the size of the resulting file should be a priority, but not this much IMHO, especially when including stdlib stuff is a pain in the ass.

Does Opal support #coerce already?

Grepping for coerce doesn't show up anything, so I guess not.