Some sessions delayed 15 minutes because of projector trouble.
I attended these sessions:
N.B. These summaries may be imprecise.
- Ruby Interpreter: The Current Status and Future
- speaker: Koichi Sasada
- Please migrate to Ruby 1.9
- multi functions and high performance
- Survey the migration point: e.g. C extentions and M17N
- Many Ruby implementations
- Ruby 1.8
- Ruby 1.9
- JRuby
- IronRuby
- Rubinius
- MagLev
- smallruby
- Cardinal
- Ruby 1.8
- The most stable Ruby currently
- 1.8 trunk: maintained by musha
- 1.8.7: maintained by musha
- 1.8.6: maintained by EngineYard
- Used in Ruby on Rails
- Never change drastically
- Migration path to the Ruby 1.9
- in Ruby 1.8.8, never raises syyntax error by the syntax of Ruby 1.9
- Ruby 1.8.9 will never be released
- Ruby 1.9 features
- M17N
- Ordered hash
- New hash notation with Symbol keys only:
{a: 1, b: 2, c: 3}- New lambda notation ->
- Block parameters
- Changing scope of parameters in block
- include RubyGems
- include Rake
- Fiber
- Ruby 1.9 performance
- speed: improved little better
- By introducing the new VM, many functions speed up.
- Few functions speed down, but Rails often uses them.
- memory footprint: improved muchj better
- Reduce dependency on Matz
- start to establish the release manager
- start to establish the coverage tester
- start to track tickets with Redmine
- Ruby 1.9.2
- improve the stability
- improve the working with RubySpec
- ready to run Ruby on Rails
- Stabilization
- Documentation
- Portability
- From Ruby 1.9, we have clarified the platforms to support and not to support.
- And we would like to increase supporting platforms.
- Researching now
- high performance
- embedded system
- multi VM
- more functions
- IronRuby and Software, Service
- speaker: Kazuyoshi Korosue
- What can Microsoft do for Rubyists to be happy?
- Assistance development of IronRuby
- Suppport IronRuby community
- Hiring core members
- Simple platform access
- Decide scopes of standardization and compatibility
- Separating language specification from implementation
- DLR
- IronPython, IronRuby, ECMAScript and so on
- Plans to be standard feature in .NET 4.0
- Use .NET from IronRuby
- Use IronRuby from C#
- Interoperability between dynamic languages
- Silverlight
- I think it's weak point of Ruby to implement rich clients.
- In Silverlight, we can implement it with only Ruby and XAML.
- Cross-platform: Win, Mac, Linux
- Cross-browser: IE, Firefox, Safari
- e.g. Super fruit world
- Social application in mixi(most popular SNS in Japan)
- front-end: IronRuby and Silverlight
- back-end: Some applications include Ruby on Rails
- Silverlight DEMO
Q from attendee Can IronRuby operate Word or Excel? A from speaker It's easy for the user from C# backgrounds, but difficult for the user from Ruby backgrounds. Q from attendee What's unique benefit of IronRuby? A from speaker Interoperating with .NET and related technologies. Q from me At past, I read the article about the project simplifying from XAML to Ruby's internal DSL. How about it now? A from speaker We recommand XAML. And I don't know much about that project. So I will survey. - JRuby: Bringing Ruby to the Java World
- speaker: Thomas Enebo
- speaker: Charles Nutter
- We have been developing JRuby as a full-time job for 3 years.
- We were hired at Sun until nowadays.
- Recently, we join to Engine Yard.
- We have also been using Java for 12 years.
- JRuby
- A Ruby interpreter running on JVM
- Support native thread
- Not support C Extentions
- Some libraries in common usage are ported for JRuby like YAML library.
- We will use FFI eventually.
- To access Java libraries
- Java is Everywhere
- Java is mature
- JRuby Codebase
- 3 full-time engineers
- Large number of community members
- JRuby DEMO
- Android
- Runs JRuby very well = Ruby as a mobile language
- jirb on Android DEMO
- ActiveHibernate DEMO
- Load Hibernate XML file.
- class Event
extend Hibernate::Model;
hibernate_attr :id => :long, :title => :string, :date => :date
hibernate!
end- tx(&block) ... Block to do with transaction
- Google App Engine
- Deploying JRuby and Rack
- Scaling automatically
- To access Google resources
- Sites working with JRuby on Rails
- Kenai
- auktionskompaniet.com
- Pons.eu
- Trisano
- Fuel system of Gardermoen airport
Q from attendee Do you have a plan to release jirb on Android? A from speaker Yes. We are going to release it as free. And also release source codes. What should we release in the next week? Q from attendee What is most difficult ever on developing JRuby? A from speaker Porting C Extentions to JRuby libraries. Q from attendee In current demonstaraion, You use the file called "Hibernate XML". What is this? A from speaker It's only just Hibernate's XML file. We plan to simplify as internal DSL. - Applying compiler technology to Ruby
- speaker: Evan Phoenix
- Reasons that Ruby is wonderful also make Ruby slow.
- A new code is interpreted each time.
- Dynamic typing
- late-bound method call
- Can I learn from the example of other languages?
- Smalltalk
- Self
- Java(Hotspot)
- Codes compiled are faster than codes interpreted.
- It's almost impossible to figure out statically.
- Type profile
- Code generation with JIT compiler
- Dynamic dispatch is possible, but not always.
- Method inlining: The method called frequently is inlined.
- In Rubinius, JIT compiler is built with LLVM.
- Type profiling with LLVM and Inline Cache
- A benchmark of Rubinius is faster than Ruby 1.8.
- A benchmark of Rubinius with JIT-on is faster than Ruby 1.9.
- A benchmark using Hash of Rubinius is slower than Ruby 1.8 and Ruby 1.9.
- A benchmark using Tak of both Rubinius with JIT-on and Ruby 1.9 is faster than others.
- Closing
- speech: Hiroshi Inoue
Sorry for my vocabulary and knowledge are so poor to understand this Evan Phoenix's session.
At last, in closing, Numbers of attendees are announced:
The 1st day: 590
The 2nd day: 502
No comments:
Post a Comment