Notes on Developing MagLev Applications
This file contains random insights into developing MagLev applications.
One thing to be careful of, is running bundler under maglev, and then accidentally using MRI rake. You can get a lot of messages like:
$ rake -T (in /Users/pmclain/tmp/myapp) Could not find tzinfo-0.3.24 in any of the sources Try running `bundle install`.
In this example, tzinfo-0.3.24 is installed as a Maglev gem, but not installed in MRI. The Gemfile.lock was generated by Maglev bundler, but when you run MRI rake, MRI can't find the appropriate tzinfo gem. Running $MAGLEV_HOME/bin/rake -T works fine.
File View vs Repository View
One thing that will probably bite you at one time or another, is that you'll be developing an application, commit some code, then refactor it and re-commit, but you'll get a mysterious bug:
Deleting a method from your file does not delete it from the repository!
Maglev.persistent do class Tag attr_reader :name def initialize(name) @name = name end # Other stuff... end end Maglev.commit_transaction t = Tag.new("fred")
You run the code to test it and it works. Now you decide to refactor (you don't want to name your tags afterall), so you edit tag.rb and delete the intialize method and the reader:
Maglev.persistent do class Tag # Other stuff... end end Maglev.commit_transaction t = Tag.new
You re-run the code, but you get the following error:
$ maglev-ruby tag.rb -- RubyFile>>load : loading /Users/pmclain/GemStone/dev/tag.rb error , too few arguments, during /Users/pmclain/GemStone/dev/tag.rb ----------------------------------------------------- GemStone: Error Nonfatal Error, 'too few arguments' Error Category: 231169 [GemStone] Number: 2023 Arg Count: 1 Context : 148473601 Arg 1: [69411841 sz:17 cls: 74753 String] too few arguments
While the code in tag.rb is “correct”, MagLev still has the old definition of Tag#initialize in the repository, so it is expecting one parameter, and the new code doesn't pass any parameters to new.
Currently, the only thing to do is to reset the repository back to scratch:
$ cd $MAGLEV_HOME $ rake maglev:reload $ rake maglev:start
Now, the second version of the file is “in-synch” with the state of the repository, and the code runs fine.
MagLev provides a Gprof-like profiling utility to analyze the performance of your application. To profile some code, simply wrap it in a block and pass it to Maglev::Gprof.monitor:
profile_results = Maglev::Gprof.monitor do # Code to profile goes here... end puts profile_results
The return value of Maglev::Gprof.monitor is a String with formatted results.
Be careful of running applications on a stone that has a different app/framework persisted on it. E.g., if you've persisted a Sinatra app on your maglev stone, then running a Rails app (even non-persisted) may be affected. Sinatra will decorate kernel classes (i.e., Object) with methods that may confuse the Rails app. It is probably best, even in development, to create a separate stone for each application that you persist, that way you won't accidentally confuse other apps. This is probably mostly a concern with frameworks. You probably won't run into many problems running several Sinatra apps on a stone with persisted Sinatra apps. But you probably shouldn't mix persisted Sinatra apps with Rails apps etc.