Skip to content
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

__str__ method not found Error with ecr_embed on String::Builder.build on 0.11.0 #2057

Closed
f opened this issue Jan 24, 2016 · 4 comments
Closed
Labels
kind:bug A bug in the code. Does not apply to documentation, specs, etc. topic:compiler

Comments

@f
Copy link
Contributor

f commented Jan 24, 2016

String::Builder.build do |__str__|
    embed_ecr("hello.ecr", "__str__")
end

This code is broken on 0.11.0.

instantiating 'String::Builder:Class#build()'
in macro 'macro_4616040192' expanded macro: embed_ecr:1, line 1:

  1. __str__ << "Hello "
  2. (#<loc:"hello.ecr",1,10> env.params["name"] ).to_s __str__
  3. __str__ << "\n"

__str__ << "Hello "
^~~~~~~

undefined method '__str__' (If you declared '__str__' in a suffix if, declare it in a regular if for this to work. If the variable was declared in a macro it's not visible outside it)
@f
Copy link
Contributor Author

f commented Jan 24, 2016

Update

I solved with removing block.

__str__ = String::Builder.new
embed_ecr({{filename}}, "__str__")
__str__.to_s

And now I have another strange problem:

hello.ecr:

Hello <%= env.params["name"] %>

This is not working (says env is not unknown):

kemal.add_route "GET", "/view/:name" do |env|
  render "hello.ecr"
end

This is working:

kemal.add_route "GET", "/view/:name" do |temp_env|
  env = temp_env
  render "hello.ecr"
end

@ysbaddaden
Copy link
Contributor

What about String.build instead of String::Builder.build ?

@asterite asterite added kind:bug A bug in the code. Does not apply to documentation, specs, etc. topic:compiler labels Jan 24, 2016
@asterite
Copy link
Member

@f Thanks for reporting this!

This and #2050 are probably worth a minor release with these fixes (0.11.1). All of these regressions are because of these two bug fixes: 81a7af2 and 92aabbd. There was a big chance that they introduced new bugs.

@f
Copy link
Contributor Author

f commented Jan 24, 2016

@ysbaddaden Same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:bug A bug in the code. Does not apply to documentation, specs, etc. topic:compiler
Projects
None yet
Development

No branches or pull requests

3 participants