-
move current master to 0-0-stable branch, drop newast on master
-
add method lookup for varargs methods
-
add varargs method creation support.
-
setup mirah.github.com moreso
- setup boulder bugmash website.
$ gf
From github.com:mirah/mirah
* [new branch] 0-0-11-maven-release -> origin/0-0-11-maven-release
$ g
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
Cool we're all up to date. Let's make some branches
$ git co -b 0-0-stable
Switched to a new branch '0-0-stable'
$ git push origin 0-0-stable
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:mirah/mirah.git
* [new branch] 0-0-stable -> 0-0-stable
Now to merge newast into master. I'm making a separate local repo, in case I bork things up.
$ cd ..
$ git clone git@github.com:mirah/mirah.git moving_mirah_about
Cloning into moving_mirah_about...
remote: Counting objects: 10714, done.
remote: Compressing objects: 100% (3195/3195), done.
remote: Total 10714 (delta 7166), reused 10345 (delta 6803)
Receiving objects: 100% (10714/10714), 44.71 MiB | 1.41 MiB/s, done.
Resolving deltas: 100% (7166/7166), done.
$ cd moving_mirah_about
I'm trying out using the ours strategy, based on reading this stackoverflow answer. I'll merge master into newast with ours, then merge it back into master, and see what happens.
$ git co newast
$ git merge -s ours master
Merge made by ours.
$ git log -1
commit 26224db9c49afd8b874c83965dffe6c5ddc36557
Merge: 93cb158 9e10f98
Author: Nick Howard <ndh@baroquebobcat.com>
Date: Sun Jul 29 14:03:59 2012 -0600
Merge branch 'master' into newast
$ git co master
Switched to branch 'master'
$ git merge newast
Updating 9e10f98..26224db
Fast-forward
...
$ git log -1
commit 26224db9c49afd8b874c83965dffe6c5ddc36557
Merge: 93cb158 9e10f98
Author: Nick Howard <ndh@baroquebobcat.com>
Date: Sun Jul 29 14:03:59 2012 -0600
Merge branch 'master' into newast
$ g
# On branch master
# Your branch is ahead of 'origin/master' by 192 commits.
#
nothing to commit (working directory clean)
Huzzah! It appears to have worked!
Let's see if everything is in order. Do tests run? Not all of them will pass, but that's ok.
$ rvm jruby@mirah_hacking
$ rt
Bundler::GitError: https://github.com/headius/bitescript.git (at master) is not checked out. Please run `bundle install`
$ bundle
Updating https://github.com/headius/bitescript.git
Fetching gem metadata from http://rubygems.org/.......
Using rake (0.9.2.2)
Installing ansi (1.4.3)
Using bitescript (0.1.0) from https://github.com/headius/bitescript.git (at master)
Using columnize (0.3.6)
Installing minitest (3.3.0)
Using mirah (0.1.0.dev) from source at /Users/nick/hacking/mirah_hacking/moving_mirah_about
Using ruby-debug-base (0.10.4)
Using ruby-debug (0.10.4)
Installing turn (0.9.6)
Using bundler (1.1.4)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
Ran tests on newast, and on new master.
old local repo's newast:
171 tests, 507 assertions, 4 failures, 17 errors
org.jruby.exceptions.RaiseException: (SystemExit) exit
Errors in test:jvm:bytecode
Errors in test:core
Errors in test:jvm
rake aborted!
new master:
171 tests, 505 assertions, 4 failures, 18 errors
org.jruby.exceptions.RaiseException: (SystemExit) exit
Errors in test:jvm:bytecode
Errors in test:core
Errors in test:jvm
rake aborted!
hmm. Maybe it's something with my old repo
new repo, newast, with merge...:
$ git co newast
$ rt
...
171 tests, 505 assertions, 4 failures, 18 errors
org.jruby.exceptions.RaiseException: (SystemExit) exit
Errors in test:jvm:bytecode
Errors in test:core
Errors in test:jvm
rake aborted!
maybe it's the merge?
$ git co HEAD^
$ rt
...
171 tests, 507 assertions, 4 failures, 17 errors
org.jruby.exceptions.RaiseException: (SystemExit) exit
Errors in test:jvm:bytecode
Errors in test:core
Errors in test:jvm
rake aborted!
Yep. What's the differing test?
# in old repo
$ rake test > /tmp/old_newast
# in new repo
$ rake test > /tmp/new_master
$ diff /tmp/old_newast /tmp/new_master
$ diff /tmp/old_newast /tmp/new_master
...
232a233,245
> test_nil_assign(JVMCompilerTest):
> Mirah::MirahError: Cannot find instance method length() on java.lang.Object
> moving_mirah_about/lib/mirah/generator.rb:68:in `infer_asts'
> moving_mirah_about/lib/mirah/util/process_errors.rb:82:in `process_inference_errors'
> moving_mirah_about/lib/mirah/generator.rb:71:in `infer_asts'
> moving_mirah_about/lib/mirah/generator.rb:63:in `infer_asts'
> moving_mirah_about/test/jvm/bytecode_test_helper.rb:119:in `compile'
> moving_mirah_about/test/jvm/jvm_compiler_test.rb:1918:in `test_nil_assign'
> org/jruby/RubyKernel.java:2076:in `send'
> org/jruby/RubyArray.java:1615:in `each'
> org/jruby/RubyArray.java:1615:in `each'
>
> 16) Error:
249c262
< 16) Error:
...
322c335
< 171 tests, 507 assertions, 4 failures, 17 errors
---
> 171 tests, 505 assertions, 4 failures, 18 errors
Ah ha test_nil_assign(JVMCompilerTest) and lib/mirah/generator.rb
what's up there?
$ git diff origin/newast
bangs head on desk for a while
de nada. Hmm, maybe it's the jars, if the old master jars were still in javalib, they'd be the same.
$ rake bootstrap test
...
171 tests, 505 assertions, 4 failures, 18 errors
org.jruby.exceptions.RaiseException: (SystemExit) exit
Errors in test:jvm:bytecode
Errors in test:core
Errors in test:jvm
rake aborted!
yep! Pushing it. With a couple bits from master, namely the History.txt for 0.0.12.
argh! that commit had too many bits in it. Serves me right. Time to cherry pick w/o committing.
$ git cherry-pick -n 9e10f98e40724d
error: refusing to lose untracked file at 'javalib/mirah-bootstrap.jar'
error: could not apply 9e10f98... bump versions to 0.0.13.dev
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit -c 9e10f98'
$ g
# On branch master
# Your branch is ahead of 'origin/master' by 192 commits.
#
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: History.txt
#
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# deleted by us: javalib/mirah-bootstrap.jar
# both modified: lib/mirah/version.rb
# both modified: maven/mirah-complete/pom.xml
# both modified: maven/mirah/pom.xml
# both modified: pom.xml
#
$ git add .
$ git reset .
Unstaged changes after reset:
M Gemfile
M History.txt
M lib/mirah/version.rb
M maven/mirah-complete/pom.xml
M maven/mirah/pom.xml
M pom.xml
$ git add History.txt
$ git ci -m "put the 0.0.12 history back in"
[master e45e21b] put the 0.0.12 history back in
1 files changed, 21 insertions(+), 0 deletions(-)
$ git co .
$ g
# On branch master
# Your branch is ahead of 'origin/master' by 193 commits.
#
nothing to commit (working directory clean)
$ git push
added deprecation notice to newast branch. http://git.io/rDnplw
Putting it in test/jvm/jvm_compiler_test.rb, AKA the dumping ground. More seriously, there are a number of lookup tests in it, so when I factor those out into their own file, they'll still be in one place.
def test_varargs_method_lookup
cls, = compile(<<-EOF)
puts String.format "%02d %s's", 2, "bananas"
EOF
assert_output "02 bananas\n" do
cls.main nil
end
endThere was some nasty stuff in the lib/mirah/jvm/method_lookup.rb file, so I changed it
diff --git a/lib/mirah/jvm/method_lookup.rb b/lib/mirah/jvm/method_lookup.rb
index 70ac07a..02899ed 100644
--- a/lib/mirah/jvm/method_lookup.rb
+++ b/lib/mirah/jvm/method_lookup.rb
@@ -31,16 +31,15 @@ module Mirah
if mapped_type.error?
raise "WTF?!?"
end
- if name == 'new'
- if meta
- name = "<init>"
- constructor = true
- mapped_type = mapped_type.unmeta
- meta = false
- else
- constructor = false
- end
- elsif name == '<init>' && !meta
+
+ if name == 'new' && meta # we're calling SomeClass.new
+ name = "<init>"
+ constructor = true
+ mapped_type = mapped_type.unmeta
+ meta = false
+ elsif name == 'new' && !meta # we're calling some_instance.new
+ constructor = false
+ elsif name == '<init>' && !meta # how do we get here?
constructor = true
endugh, there's some gnarly code in here. I'll need to clean this up later. Looks like I need to modify the find_jls2 method.
Maybe this will help there. It checks for exact size or if it's a varargs method, that the args passed are <= in number than the required ones.
# filter by arity, varargs
by_name_and_arity = by_name.select {|m| m.argument_types.size == mapped_params.size ||
m.respond_to?(:var_args?) && m.var_args? &&
m.argument_types.size <= mapped_params.size}But now, I need to look in phase1
actually phase3 http://stackoverflow.com/questions/6032901/java-overloaded-method-resolution-and-varargs-confusing-example