New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Puma/Sinatra app fails to start: classname is not a class #3787

Open
onli opened this Issue Mar 17, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@onli
Copy link

onli commented Mar 17, 2018

Rubunius seems to think that a class of mine is not a class, at least that is how I interpret the stacktrace. The class in question is this, which ruby -c benchmark.rb confirmed to be correct - besides, it works with MRI. I'm aware that the issue is likely something deeper than just a code syntax misinterpretation - but this is not the first class the program is loading, and the others seem to load fine.

  1. What command did you run?

I ran bundle exec puma -e development

  1. What behavior did you expect?

I expected my sinatra application to be started

  1. What behavior did you get instead?

This stacktrace of a TypeError.

  1. What version of Rubinius?

Output of rbx -v: rubinius 3.100.c2 (2.3.1 d08bd4e 2018-03-16 3.9.1) [x86_64-linux-gnu]

  1. What version of operating system?

Output of uname -a: Linux Fallout 4.14.12-2 #1 SMP Sun Jan 7 22:35:18 CET 2018 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux

  1. What is your operating system distribution, if your operating system has more than one?

My distribution is funtoo, a fork of gentoo.

  1. How did you build your version of Rubinius?
  • I used RVM.
  • I used ruby-build.
  • I used ruby-install.
  • I built manually from a tarball.
  • I built manually from a git clone.
  • I installed a binary.
  1. Does this issue involve proprietary code?
  • Yes, this issue involves proprietary code that I cannot share.
  • Yes, this issue involves proprietary code, but I am able to share it under certain conditions.
  • No, this issue doesn't involve proprietary code.
  1. Are you able to help us debug the issue?
  • Yes, I'm able to help debug, including running commands under lldb.
  • No, I'm not able help debug or I don't have time to help.
@jc00ke

This comment has been minimized.

Copy link
Member

jc00ke commented Mar 17, 2018

Ruby/Rubinius already has a module defined calledBenchmark. Try renaming your class, or nesting it under a namespace of your own.

-c will pass on MRI when only that file is checked, but I'm guessing it won't if you add -rbenchmark.

@jc00ke jc00ke closed this Mar 17, 2018

@onli

This comment has been minimized.

Copy link

onli commented Mar 17, 2018

Thanks, putting Benchmark into a module helped with this issue :) I'd like to kindly suggest that this difference to MRI might be cumbersome for others as well, and maybe that namespace could be freed - Benchmark can't be a too uncommon class name.

@jc00ke

This comment has been minimized.

Copy link
Member

jc00ke commented Mar 17, 2018

@onli can you share your new version? If you just switched from class to module then you're just adding methods to the existing Benchmark module.

As for your suggestion, it's better to organize one's code so that it doesn't conflict with other's, and this is a perfect example.

@brixen

This comment has been minimized.

Copy link
Member

brixen commented Mar 17, 2018

@onli thanks for opening the issue and @jc00ke for helping look into it.

The issue here is that Benchmark is provided by the stdlib and Rubinius is currently preferring the stdlib over $LOAD_PATH due to previous issues with trying to gemify stdlib and Bundler and RubyGems not respecting that. I've removed the stdlib gems, and the files are pre-compiled into the Rubinius CodeDB.

I'll revisit the load order resolution shortly. I do think @jc00ke has good advice about properly namespacing your own app's classes and not assuming that the global namespace under Object won't have a conflict. But in this case, I think fixing the load order resolution will be better overall, but it does impose an extra cost for resolving stdlib files.

@brixen brixen reopened this Mar 17, 2018

@onli

This comment has been minimized.

Copy link

onli commented Mar 17, 2018

@jc00ke I wrapped a different module around it: https://gist.github.com/onli/f3d295667cc5288b720eb01f3c1c5754. Thanks for warning me about that though :)

@brixen I'm happy to head you consider fixing this at the core!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment