Hey all, application completely breaks down in production mode. I
followed the execution file by file line by line and yet I cannot figure
out where an instance variable is being generated from. But I have a
suspicion. This method right here:
# neeeded becasuse of a rails bug
def to_s
"#{self.class.name.underscore}__#{object_id}"
end
I think it's cause of problem. I also noticed that the developer left a
comment above it. Problem is it's part of a class that gets yielded into
a ruby block and there's a number of partials that get rendered in the
new view. But I cannot find for the life of me where to_s is called
during execution of clicking a new button.
I think it's cause of problem. I also noticed that the developer left a
comment above it. Problem is it's part of a class that gets yielded into
a ruby block and there's a number of partials that get rendered in the
new view. But I cannot find for the life of me where to_s is called
during execution of clicking a new button.
It appears caller expects an argument. This is not a setter method.
There is no argument passed to this object, and in your example, if i
add one like 'skip', of course I receive an exception "wrong number of
arguments".
The argument to caller is optional. You might also want to install ruby-debug and add a breakpoint.
Hey all, application completely breaks down in production mode. I
followed the execution file by file line by line and yet I cannot figure
out where an instance variable is being generated from. But I have a
suspicion. This method right here:
# neeeded becasuse of a rails bug
def to_s
"#{self.class.name.underscore}__#{object_id}"
end
I think it's cause of problem. I also noticed that the developer left a
comment above it. Problem is it's part of a class that gets yielded into
a ruby block and there's a number of partials that get rendered in the
new view. But I cannot find for the life of me where to_s is called
during execution of clicking a new button.
I need some debugging advice for this.
If all else fails put some code there that generates a runtime error,
then you will get a stack trace. If you only want it to stop under
some conditions use a global variable and test it at the offending
point to find out whether to crash or not.
Fred's suggestion of using ruby-debug and putting a (possibly
conditional) breakpoint there is probably better.
