Trying out 3.0.0rc3

[Goutte]

So, I tried the latest version, and here's some feedback :

$ git clone git@github.com:sinisterchipmunk/jax.git jax-3.0.0rc3
[...] OK

$ cd jax-3.0.0rc3
[RVM automagically triggers...]
Using /usr/local/rvm/gems/ruby-2.0.0-p247 with gemset jax
Resolving dependencies...
Using rake (10.0.4) 
Using RedCloth (4.2.9) 
Using i18n (0.6.4) 
Using minitest (4.7.5) 
Using multi_json (1.7.7) 
Using atomic (1.1.10) 
Using thread_safe (0.1.0) 
Using tzinfo (0.3.37) 
Using activesupport (4.0.0) 
Using builder (3.1.4) 
Using erubis (2.7.0) 
Using rack (1.5.2) 
Using rack-test (0.6.2) 
Using actionpack (4.0.0) 
Using mime-types (1.23) 
Using polyglot (0.3.3) 
Using treetop (1.4.14) 
Using mail (2.5.4) 
Using actionmailer (4.0.0) 
Using activemodel (4.0.0) 
Using activerecord-deprecated_finders (1.0.3) 
Using arel (4.0.0) 
Using activerecord (4.0.0) 
Using bundler (1.3.5) 
Using execjs (1.4.0) 
Using thor (0.18.1) 
Using railties (4.0.0) 
Using gl-matrix-rails (0.1.5) 
Using hike (1.2.3) 
Using jasmine-core (1.3.1) 
Using tilt (1.4.1) 
Using sprockets (2.10.0) 
Using sprockets-rails (2.0.0) 
Using rails (4.0.0) 
Using jasmine-rails (0.4.5) 
Using jax-core (3.0.0.rc3) from source at . 
Using jquery-rails (3.0.4) 
Using jax-engine (3.0.0.rc3) from source at . 
Using jax (3.0.0.rc3) from source at . 
Using jshintrb (0.2.1) 
Using json (1.8.0) 
Using mustache (0.99.4) 
Using nokogiri (1.5.9) 
Using redcarpet (1.17.2) 
Using rocco (0.8.2) from git://github.com/rtomayko/rocco.git (at master) 
Using w3c_validators (1.2) 
Your bundle is complete!

Hey, where are the development dependencies of jax-core and jax-engine ?

Because, then I get :

$ rake
rm -rf guides/output
/usr/local/rvm/rubies/ruby-2.0.0-p247/bin/ruby guides/jax_guides.rb
Generating layout.html
Generating lighting.html
Generating materials.html
Generating testing.html
Generating matrices.html
Generating getting_started.html
Generating shaders.html
Generating index.html
Generating plugins.html
cd jax-core
rake aborted!
cannot load such file -- rspec/core/rake_task
/home/goutte/Code/FORKS/jax-3.0.0rc3/jax-core/Rakefile:54:in `require'

I found rspec in jax-core.gemspec. I can cd jax-core and bundle update, but when I cd .. and rake I still get the same error.

I really am still a noob when it comes to ruby >.<

---

Also, the generate-testbeds worked.

[sinisterchipmunk]

I'm having trouble coercing rake and bundler from the project root. I decided to call it a night without quite getting this working.

You can run rake inside of the jax-core directory to test just jax-core; you can do the same in jax-engine to test just jax-engine. Ideally, rake in the project root should do both, but Bundler messes with the load paths and keeps me from dynamically loading the sub-projects' gemfiles. (FYI, automated in-browser testing for jax-engine isn't functional right now either. You have to rackup for that -- see TESTING.)

The answer might be to refactor out the gemfiles into the project root, I don't know yet. I'd rather not do that if possible because jax-engine relies on testbeds, but jax and jax-core do not, and it seems like a waste of cycles.

Leaving this open until rake works from project root, because it should. :)

[sinisterchipmunk]

Ok, this seems to be working now.

Example from project root:

BUNDLE_GEMFILE=`pwd`/gemfiles/rails-3.2 rake

I think using an absolute path to the Gemfile is required.

When jax-core runs its in-browser tests, be patient. It takes a while to serialize the results to Ruby. As of this writing, only the picking tests are failing for me. Failures in JavaScript don't cause the rake command to fail, at this time.

For running tests within a jax-core or jax-engine directory instead of from project root, export BUNDLE_GEMFILE as an absolute path, first.

I haven't been successful with hooking jax-engine JavaScript tests into rake just yet, so you have to continue with rackup for that.

[Goutte]

Ok !

I think it's a neat idea to separate jax-core from jax-engine, even at the cost of some tesing complexity (who said brainfcuk?). It'll be easier to later separate the shaders in a jax-shaders section for example, with its own visual testing facility !

---

I've moved to installing a jax app using the 3.0.0rc2, and I ran into problems similar to issue #72.

I spent my day trying various dependencies configurations (up until I capped out rubygems' API limit)... I seems to be a bug related to jasmine-rails, but I don't really understand because it should be fixed in the version of jasmine jax uses... which does not use jasmine-rails !

Here's what I did :

$ gem install jax -v "=3.0.0rc2"
$ rvm use 2.0.0
$ bundle install
$ bundle update
$ jax new cyx

Everything's shiny up to this point, not to fret.

$ jax server
=> Booting WEBrick
=> Rails 3.2.14 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2013-07-27 18:44:06] INFO  WEBrick 1.3.1
[2013-07-27 18:44:06] INFO  ruby 2.0.0 (2013-06-27) [x86_64-linux]
[2013-07-27 18:44:06] INFO  WEBrick::HTTPServer#start: pid=6479 port=3000

Started GET "/assets/jax.js" for 127.0.0.1 at 2013-07-27 18:44:08 +0200

NameError (uninitialized constant Jasmine::Config):
  jax (3.0.0.rc2) lib/jax/jasmine/config.rb:1:in `<top (required)>'
  jax (3.0.0.rc2) lib/jax/jasmine/rails_adapter.rb:18:in `middleware'
  jax (3.0.0.rc2) lib/jax/jasmine/rails_adapter.rb:12:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/best_standards_support.rb:17:in `call'
  rack (1.4.5) lib/rack/etag.rb:23:in `call'
  rack (1.4.5) lib/rack/conditionalget.rb:25:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/head.rb:14:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/params_parser.rb:21:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/flash.rb:242:in `call'
  rack (1.4.5) lib/rack/session/abstract/id.rb:210:in `context'
  rack (1.4.5) lib/rack/session/abstract/id.rb:205:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/cookies.rb:341:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
  activesupport (3.2.14) lib/active_support/callbacks.rb:405:in `_run__1898584455044460363__call__1644893896191916401__callbacks'
  activesupport (3.2.14) lib/active_support/callbacks.rb:405:in `__run_callback'
  activesupport (3.2.14) lib/active_support/callbacks.rb:385:in `_run_call_callbacks'
  activesupport (3.2.14) lib/active_support/callbacks.rb:81:in `run_callbacks'
  actionpack (3.2.14) lib/action_dispatch/middleware/callbacks.rb:27:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/reloader.rb:65:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/remote_ip.rb:31:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/debug_exceptions.rb:16:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
  railties (3.2.14) lib/rails/rack/logger.rb:32:in `call_app'
  railties (3.2.14) lib/rails/rack/logger.rb:16:in `block in call'
  activesupport (3.2.14) lib/active_support/tagged_logging.rb:22:in `tagged'
  railties (3.2.14) lib/rails/rack/logger.rb:16:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/request_id.rb:22:in `call'
  rack (1.4.5) lib/rack/methodoverride.rb:21:in `call'
  rack (1.4.5) lib/rack/runtime.rb:17:in `call'
  activesupport (3.2.14) lib/active_support/cache/strategy/local_cache.rb:72:in `call'
  rack (1.4.5) lib/rack/lock.rb:15:in `call'
  actionpack (3.2.14) lib/action_dispatch/middleware/static.rb:63:in `call'
  railties (3.2.14) lib/rails/engine.rb:484:in `call'
  railties (3.2.14) lib/rails/application.rb:231:in `call'
  rack (1.4.5) lib/rack/content_length.rb:14:in `call'
  railties (3.2.14) lib/rails/rack/log_tailer.rb:17:in `call'
  rack (1.4.5) lib/rack/handler/webrick.rb:59:in `service'
  /usr/local/rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/webrick/httpserver.rb:138:in `service'
  /usr/local/rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/webrick/httpserver.rb:94:in `run'
  /usr/local/rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/webrick/server.rb:295:in `block in start_thread'

[sinisterchipmunk]

The released RC is not compatible with recent changes to jasmine-rails. Try using bundler to install jax from github. I have not tested recent commits this way, and jax master may be broken in other ways right now, but it should at least be compatible with jasmine.

[Goutte]

oooOOooOoooh ! Did not even figured that rc2 was frozen >.< I must be exhausted from the heat...

---

Well I can definitely add in the Gemfile

gem 'jax', :git => "git://github.com/sinisterchipmunk/jax.git"

but, how can I create a new jax (non-rails) project in an empty directory ?

Is it still possible to create through something like

$ gem install jax -v "=3.0.0rc3"

(which does not find rc3 because it is not on rubygems i suppose, though the git repo says rc3)

---

My story is : I need to jax new ... so I get the new files, because with the jax new ... from rc2, when I only update the Gemfile, I get :

$ jax server
script/jax:8:in `require': cannot load such file -- jax/commands (LoadError)

[Goutte]

BTW, gem install has no option for git, all of the internet tells me to use a Gemfile... :(

[Goutte]

Don't mind me, I got it working by initializing a new Rails project, works fine that way ! I don't have access to jax, but I still can generate using rails generate jax:<something> !

Of course, as you said, some things are broken, but it's coffeescript, I can deal with it ! :)

Would you like me to collect and report (and even try to fix hack around) broken things ? (broken = not working as documentation states)

[sinisterchipmunk]

Yes, I would appreciate people pointing out places where the docs don't make sense. Keep in mind that in many cases, it's the docs, not the code, that will change -- but shedding light on those changes is important regardless of where they need to be made.

After much deliberation, I've decided to make Jax more rails-centric. My reasoning is simple: a standalone Jax application is really just a Rails application where you never create a controller, and always precompile your assets. So, it makes more sense to make Jax be a Rails framework, and users who need a standalone app can just rake assets:precompile to get the exact same benefit, with half the magic.

Thus, the jax command-line tool has been removed, and now rails generate jax:<something> is the preferred way to invoke the generators.

If there's enough push-back from the community, then I could be convinced to continue supporting static applications, but if you give the rake assets:precompile approach a try, I think you'll eventually agree that this makes more sense, and makes the whole Jax app build process more transparent.

[Goutte]

Okay !

I don't mind one way or the other, and like you I prefer when things stay simple ; I was merely following the doc blindly, and it took me quite a while to figure out the rails generate jax:<something> command, and even then I was convinced I was not doing the right thing. ;)

Static apps are not needed, I think ; it's easy enough to rails new awesomeness.

---

I'll make a PR when LEAP controls are hacked and I'll post other issues as well, but right now, know that the Light generator still generates .resource files instead of Jax.Light.addResources coffeescript files and that the generated Model resource files lack the .getGlobal() after Jax. (I don't yet really understand why it is needed, though)

[sinisterchipmunk]

I'll make a PR when LEAP controls are hacked

Sounds great, but be aware that I have been working on the input code. The API is somewhat different. It should make adding new devices much more seamless -- but hopefully it doesn't break anything you've been working on so far. Take a look at Jax.Input.Keyboard and Jax.Input.Mouse for examples.

the Light generator still generates .resource files instead of Jax.Light.addResources coffeescript files and that the generated Model resource files lack the .getGlobal() after Jax.

Thanks for the heads up. I'll get both of those fixed soon. Actually, I'm thinking of removing Jax.getGlobal(). It adds an unnecessary verbosity, with no real gain at all. Its original intent was to make Jax more friendly to CommonJS (e.g. node.js) environments -- but since WebGL isn't supported in those environments right now, it's kind of a waste. For now, I'm still debating whether Jax.getGlobal() helps future-proof the framework, or just makes it harder to understand and use.

[Goutte]

Don't worry, my time has mostly been spent to install the leap motion on debian, and trying to figure out (on paper) the best gesture ergonomy to control a trackball camera from the data the leap webservice sends.

Thanks for the Input tips, I'll get right down to it !

[sinisterchipmunk]

Cool, thanks for the link! I spent only enough time with my Linux box to say, "Ehh, no installer", and moved on to my other machines.

I, too, am playing with adding a Leap input to Jax. Since it sounds like you're not quite ready to code yet, if I get something operational first, I'll commit it. Then, if you don't agree with the implementation, I'm always open to suggestions.

[Goutte]

Well don't be too excited, I haven't yet managed to install Airspace... But it works with leapjs, so it should be enough to hack leap controls for JAX ! It does bug quite often, though. (leapd stops responding, and I have to SIGKILL it)

There's a trackball controls demo by the guy behind three.js, and it works for me on debian, but it's exactly the kind of too sensitive controls I don't want.

[sinisterchipmunk]

See commit eaab2409: add support for Leap Motion input devices. :dancer:

Here's the simplest possible demo, just paste it into a (Jax-ready) console and start making gestures:

jQuery.getScript("https://raw.github.com/leapmotion/leapjs/master/leap.js", function() {
  Jax.Controller.create('leapdemo', {
    leap_gesture_circled: function(data) { console.log("CIRCLE", data); },
    leap_gesture_swiped: function(data) { console.log("SWIPE", data); },
    leap_gesture_key_tapped: function(data) { console.log("KEY TAPPED", data); },
    leap_gesture_screen_tapped: function(data) { console.log("SCREEN TAPPED", data); }
  });

  var context = new Jax.Context(document.createElement('canvas'))
  context.redirectTo("leapdemo")
});

You can process way more than just gestures like this, see the commit for details.

[Goutte]

OMG ! :clap:

I'm so glad you did it and not me ! It would have been so shameful to publish my awful code ! :sheep:

Besides, I don't know about you, but my leapd keeps freezing after minutes of use, which is really annoying (and chronophage)...

[sinisterchipmunk]

my leapd keeps freezing after minutes of use

Odd. I've not tried to get it running on *nix yet, but it's working pretty well on my Mac.