Comments for wycats's merb  

Sorry my fault.

oh man--forgot the <pre> tags around those <code> blocks!

the first displays correctly, but the second should read

[*:foo] == [*[:foo]] == [:foo]

idiom I picked up somewhere that accomplishes the same thing:


helpers = [*helpers]


which works because

[:foo] == [[:foo]] == [:foo]

gem "json_pure", ">= 1.1.7", :require_as => "json"

Ok, in the generated Gemfile, it looks like it needs to be:

gem "json_pure", ">= 1.1.7"

This seems to break newly generated projects (from merb-gen). I'll try to track down the cause

[jc@macbookpro ~/Bundler/bookstore]# bin/merb
Merb root at: /Users/jc/Bundler/bookstore
Loading init file from ./config/init.rb
Loading ./config/environments/development.rb
/Users/jc/.rvm/ruby-1.8.7-p174/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- json_pure (LoadError)
    from /Users/jc/.rvm/ruby-1.8.7-p174/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /Users/jc/Bundler/bookstore/gems/gems/bundler-0.6.0/lib/bundler/dependency.rb:40:in `require_env'
    from /Users/jc/Bundler/bookstore/gems/gems/bundler-0.6.0/lib/bundler/dependency.rb:39:in `each'
    from /Users/jc/Bundler/bookstore/gems/gems/bundler-0.6.0/lib/bundler/dependency.rb:39:in `require_env'
    from /Users/jc/Bundler/bookstore/gems/gems/bundler-0.6.0/lib/bundler/environment.rb:114:in `require_env'
    from /Users/jc/Bundler/bookstore/gems/gems/bundler-0.6.0/lib/bundler/environment.rb:114:in `each'
    from /Users/jc/Bundler/bookstore/gems/gems/bundler-0.6.0/lib/bundler/environment.rb:114:in `require_env'
    from /Users/jc/Bundler/bookstore/gems/gems/merb-core-1.1/lib/merb-core/bootloader.rb:413:in `load_dependencies'
    from /Users/jc/Bundler/bookstore/gems/gems/merb-core-1.1/lib/merb-core/bootloader.rb:391:in `run'
    from /Users/jc/Bundler/bookstore/gems/gems/merb-core-1.1/lib/merb-core/bootloader.rb:99:in `run'
    from /Users/jc/Bundler/bookstore/gems/gems/merb-core-1.1/lib/merb-core/server.rb:172:in `bootup'
    from /Users/jc/Bundler/bookstore/gems/gems/merb-core-1.1/lib/merb-core/server.rb:42:in `start'
    from /Users/jc/Bundler/bookstore/gems/gems/merb-core-1.1/lib/merb-core.rb:169:in `start'
    from ./bin/../gems/gems/merb-core-1.1/bin/merb:10
    from bin/merb:3:in `load'
    from bin/merb:3

LOL.

This is terrible!

Use Gem::Specification#to_ruby!

It existed all the way back to 0.8.11!

With documentation!

rubygems 1.3.3

Deprecation Notices:
* Time::today has been removed early. There was no way to make it warn and be easy to override with user code.

Anyone knows the reason why Time.today doesn't work anymore?

while looking at core_ext.rb i noticed that the link to extlib is outdated. it now lives at github.com/datamapper/extlib

My vote is for fragment, since an anchor just refers to the DOM, fragment would be the proper term IMO

Supplying both is a sad path. We should probably raise an exception in that case.

The slight difference here is that when they are both on the same line, anchor will pass through if you define both :fragment and :anchor

example:

url(:my_url, :anchor => “something1”, :fragment => “something2”)

1. /my_url/?anchor=something1#something2

original 2 line approach: url(:my_url, :anchor => “something1”, :fragment => “something2”)

1. /my_url#something2

Either way seems ok, just worth noting.

Thanks for this commit, wycats.

The need for it has been nagging me, but never when I was actually sat down at a computer ^^;

fair enough, removed in http://github.com/wycats/merb/commit/133111d5ee518c17ba8b78d00fb1961b9f66d036

This probably isn’t necessary any longer, provided the merb deps specify the last stable DM release (0.9.10) as the minimum dependency.

Made a ticket for the issue here:

http://merb.lighthouseapp.com/projects/7433/tickets/1159-weird-class-loading-issues-under-jruby

Aha, I wonder if it relates to this JRuby bug:

http://jira.codehaus.org/browse/JRUBY-3078

Which was addressed with the following:

Fixed in r8188 by having threads synchronize their mutation of the included features array, thereby guaranteeing only one will ever add a feature and execute its associated file. The more aggressive options of synchronizing all requires or synchronizing by name are too likely to lead to deadlock.

I wonder if Merb’s bootloader needs some sort of similar synchronizing?

Hello,

I’m running into some very weird issues with class loading on JRuby. I was hoping this commit might fix it, but trying it with 1.0.7 doesn’t appear to solve my issue.

The issue for me seems to be that it yields to the class-loading logic at some point in the middle of a class definition, eg:

class Foo < Bar … puts “About to call method” call_some_simple_class_method puts “This never prints out; call_some_simple_class_method never returns” … end

- Encounter missing constant Foo - Load foo.rb - inside the class definition of Foo in foo.rb, for some reason, during an innocent method call, at this point start trying to load some unrelated file which is not referenced there at all. (Perhaps this is happening in another thread? however it appears to be blocking any further execution in the first thread as the method call never returns)

- this seems to lead to a whole bunch more classes being loaded, with some duplication – including loading the first class (Foo in foo.rb) again, which we hadn’t actually finished loading to start with. At this point it rightfully complains.

I also notice that class loading is very slow under JRuby, much slower than under MRI.

(FYI I have tried this with JRuby 1.1.5 and 1.1.6)

I wondered if this relates to Merb::Config[:fork_for_class_load]

With this set to false, I get the issue as described, and with it set to true, I get:

fork is unsafe and disabled by default on JRuby (NotImplementedError).

I realise there are some thread-safety issues with require and autoloading in Ruby. Are there any workarounds I can use, though, to at least get something going under JRuby?