I like using the --noprompt option on irb sometimes, especially when I may want to copy code from it and paste it somewhere else. However, an error occurs when the following appears in the .irbrc file:
IRB.conf[:AUTO_INDENT] = true
The following error occurs when irb starts up:
/Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb.rb:280:in `dup': can't dup NilClass (TypeError)
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb.rb:280:in `prompt'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb.rb:129:in `block in eval_input'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb/ruby-lex.rb:206:in `call'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb/ruby-lex.rb:206:in `prompt'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb/ruby-lex.rb:220:in `initialize_input'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb/ruby-lex.rb:227:in `each_top_level_statement'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb.rb:155:in `eval_input'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb.rb:70:in `block in start'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb.rb:69:in `catch'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/irb.rb:69:in `start'
from /Users/keithb/.rvm/rubies/ruby-1.9.3-p125/bin/irb:16:in `<main>'
The error also occurs in JRuby, but the stack trace is of course a bit different.
This is a bug, right? One would think an inappropriate configuration setting would be handled more gracefully, at minimum reporting the nature of the error at a higher level so the user would have an idea how to resolve it. Or could it be argued that it's the developer's fault for specifying an indent on a nonexistent prompt?
-- Keith
This is not a bug.
If you would like to have a .irbrc file ignored for special cases (such as when you want --noprompt) then you are likely also wanting to supply the -f flag to suppress loading your .irbrc file.
You will correctly get problems when supplying contradicting options.
TLDR;
irb -f --noprompt
Related
Ruby 3.0.0, YARD 0.9.28, Linux (Fedora 35).
Running yardoc on my project works through most of the tasks, but blows up with an apparent infinite recursion when it comes to the Serializing to doc/top-level-namespace.html. I had this problem earlier in development, but I have no idea what I did to make it go away — and now it's back.
It might have something to do with the convoluted interplay of include and extend uses; there are four modules in the project that get mixed into almost every source file in some combination or other. Regardless, this has me stumped, and I haven't found anything like it online.
Here's the tail-end of the processing (I had to pull it out of the Rake task and do it by hand because the Rake output didn't compress the repeating lines):
% bundle exec yardoc
:
:
[debug]: Parsing ["config/macros.yard", "lib/sptaf.rb", "lib/sptaf/classmethods.rb", "lib/sptaf/cli.rb", "lib/sptaf/container.rb", "lib/sptaf/debugging.rb", "lib/sptaf/exceptions.rb", "lib/sptaf/faction.rb", "lib/sptaf/feature.rb", "lib/sptaf/game.rb", "lib/sptaf/inventory.rb", "lib/sptaf/item.rb", "lib/sptaf/location.rb", "lib/sptaf/mixin/actor.rb", "lib/sptaf/mixin/container.rb", "lib/sptaf/mixin/location.rb", "lib/sptaf/mixin/thing.rb", "lib/sptaf/npc.rb", "lib/sptaf/player.rb", "lib/sptaf/version.rb"] with `ruby` parser
[debug]: Parsing config/macros.yard
[debug]: Parsing lib/sptaf.rb
[debug]: Parsing lib/sptaf/classmethods.rb
:
:
[debug]: Serializing to doc/top-level-namespace.html
bundler: failed to load command: yardoc (./vendor/bundle/ruby/3.0.0/bin/yardoc)
./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/proxy.rb:101:in `path': stack level too deep (SystemStackError)
from ./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/proxy.rb:129:in `equal?'
from ./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/module_object.rb:15:in `block in inheritance_tree'
from ./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/module_object.rb:14:in `map'
from ./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/module_object.rb:14:in `inheritance_tree'
from ./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/proxy.rb:180:in `method_missing'
from ./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/module_object.rb:17:in `block in inheritance_tree'
from ./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/module_object.rb:14:in `map'
from ./vendor/bundle/ruby/3.0.0/gems/yard-0.9.28/lib/yard/code_objects/module_object.rb:14:in `inheritance_tree'
... 10681 levels...
from /usr/share/gems/gems/bundler-2.2.33/lib/bundler/friendly_errors.rb:103:in `with_friendly_errors'
from /usr/share/gems/gems/bundler-2.2.33/libexec/bundle:37:in `<top (required)>'
from /home/coar/bin/bundle:23:in `load'
from /home/coar/bin/bundle:23:in `<main>'
Here is the .yardopts file it is using:
--charset="utf-8"
--verbose
--debug
--backtrace
--no-cache
--title="Text Adventure Framework (TAF) Gem"
--private
--embed-mixins
--markup-provider="rdiscount"
--markup="markdown"
config/macros.yard
lib/sptaf.rb
lib/sptaf/classmethods.rb
lib/sptaf/cli.rb
lib/sptaf/container.rb
lib/sptaf/debugging.rb
lib/sptaf/exceptions.rb
lib/sptaf/faction.rb
lib/sptaf/feature.rb
lib/sptaf/game.rb
lib/sptaf/inventory.rb
lib/sptaf/item.rb
lib/sptaf/location.rb
lib/sptaf/mixin/actor.rb
lib/sptaf/mixin/container.rb
lib/sptaf/mixin/location.rb
lib/sptaf/mixin/thing.rb
lib/sptaf/npc.rb
lib/sptaf/player.rb
lib/sptaf/version.rb
-
CHANGELOG.md
CODE_OF_CONDUCT.md
LICENCE.md
README.md
TODO.md
My apologies if the #documentation tag is inappropriate here; it says it's for questions about document generators, which seems to kinda fit.
As always, thanks for reading and particularly for any kind feedback!
I'm running a script (running on an AWS EC2 instance) that continually pulls state legislative data from an API, and persists it to a SQLite3 .db file. When I try to run the script as a daemon in the background, the process immediately stops and I'm given the following error.
stateleg.rb: process with pid 4666 started.
Traceback (most recent call last):
11: from stateleg_daemon.rb:4:in `<main>'
10: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons.rb:149:in `run'
9: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/cmdline.rb:121:in `catch_exceptions'
8: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons.rb:150:in `block in run'
7: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/controller.rb:59:in `run'
6: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/application.rb:307:in `start'
5: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/application.rb:228:in `start_load'
4: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/application.rb:228:in `load'
3: from /home/ubuntu/stateleg.rb:8:in `<top (required)>'
2: from /home/ubuntu/stateleg.rb:8:in `new'
1: from /usr/local/rvm/gems/ruby-2.5.1/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:89:in `initialize'
/usr/local/rvm/gems/ruby-2.5.1/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:89:in `open_v2': unable to open database file (SQLite3::CantOpenException)
When I try to run the script in the foreground, the script runs perfectly, and the necessary information is written to the .db file.
How can I make this daemon open the database file? Are SQLite3 and Ruby daemons in some way incompatible? Any information at all would be tremendously helpful.
This is the entirety of the daemon script.
require 'daemons'
Daemons.run('stateleg.rb')
When something is "daemonized" it's usually running in a different working directory than the one you expect. This is especially true for services that are spun up on boot, such as through systemd, or on cron.
In order to account for this you need to specify the full path to files you're intending to work with. These are called absolute paths since they're not impacted by the current working directory. /a/b/c is an absolute path, it starts with /, but b/c is relative. If you're in /a it's equivalent, but it won't work outside of that scope.
If you know the location of that file relative to your script, you can usually do this:
Daemons.run(File.expand_path('stateleg.rb', __dir__))
Where __dir__ is the directory in which the currently executing script file is stored.
I want to run the Prometheus Ruby Client, to gather statistics values and to save in the Prometheus database.
I've followed the instructions here : Rack middleware
https://github.com/prometheus/client_ruby#rack-middleware
I've installed two gems, prometheus and prometheus-client.
The exporter.rb (https://github.com/prometheus/client_ruby/blob/master/lib/prometheus/middleware/exporter.rb) and the collector.rb (https://github.com/prometheus/client_ruby/blob/master/lib/prometheus/middleware/collector.rb) is saved in the location: prometheus/middleware
I've saved the config.ru (https://github.com/prometheus/client_ruby#rack-middleware) in the local folder.
Then I've started the rack web server with: rackup -d config.ru -I /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/prometheus-client-0.6.0/lib -I /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/quantile-0.2.0/lib
The -I include statement is necessary to let find the required files.
Then I got this error :
/home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/prometheus-client-0.6.0/lib -I /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/quantile-0.2.0/lib
nil
Exception `ArgumentError' at /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:86 - wrong number of arguments (given 2, expected 1)
Exception `ArgumentError' at /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:49 - wrong number of arguments (given 2, expected 1)
Exception `ArgumentError' at /home/sven/.rbenv/versions/2.3.3/bin/rackup:22 - wrong number of arguments (given 2, expected 1)
/home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/deflater.rb:20:in `initialize': wrong number of arguments (given 2, expected 1) (ArgumentError)
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:86:in `new'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:86:in `block in use'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:134:in `block in to_app'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:134:in `each'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:134:in `inject'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:134:in `to_app'
from /home/sven/StarPerfMonitor_v2.0.0/config.ru:13:in `<main>'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:49:in `eval'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:49:in `new_from_string'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:40:in `parse_file'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:277:in `build_app_and_options_from_config'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:199:in `app'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:314:in `wrapped_app'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:242:in `start'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/server.rb:141:in `start'
from /home/sven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.5.5/bin/rackup:4:in `<top (required)>'
from /home/sven/.rbenv/versions/2.3.3/bin/rackup:22:in `load'
from /home/sven/.rbenv/versions/2.3.3/bin/rackup:22:in `<main>'
It seems you are using client_ruby 0.6.0 whereas Prometheus::Middleware is available only for client_ruby 0.7.0.
Check https://github.com/prometheus/client_ruby/tree/v0.6.0
This issue was too tricky, and I decided to switch over to InfluxDB.
And I was able to run the Ruby Client within minutes. It seems to be much more better for me, than Prometheus. Sorry.
I'm using the Rye ruby gem to SSH to a server and I'm having the problem where if I try to run any command from there I'm getting the following error:
rbox = Rye::Box.new(server, :user => "user", :password => "password")
rbox.ls
fingerprint d3:a1:15:ab:05:0d:4e:45:9f:b3:94:14:ca:11:d6:be does not match for "server,10.10.10.2"
Continue?
Net::SSH::HostKeyMismatch: Net::SSH::HostKeyMismatch
from C:/jruby-1.6.8/lib/ruby/gems/1.8/gems/rye-0.9.8/lib/rye/box.rb:678:in `connect'
from C:/jruby-1.6.8/lib/ruby/gems/1.8/gems/rye-0.9.8/lib/rye/box.rb:778:in `run_command'
from C:/jruby-1.6.8/lib/ruby/gems/1.8/gems/rye-0.9.8/lib/rye/cmd.rb:106:in `which'
from (irb):31:in `evaluate'
from org/jruby/RubyKernel.java:1112:in `eval'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:158:in `eval_input'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:271:in `signal_status'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:270:in `signal_status'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:155:in `eval_input'
from org/jruby/RubyKernel.java:1439:in `loop'
from org/jruby/RubyKernel.java:1212:in `catch'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:154:in `eval_input'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:71:in `start'
from org/jruby/RubyKernel.java:1212:in `catch'
from C:/jruby-1.6.8/lib/ruby/1.8/irb.rb:70:in `start'
from C:\jruby-1.6.8\bin\irb:13:in `(root)'
I've tried deleting the 'known_hosts' file from the current user home (~/.ssh/known_hosts) but still failing with the same issue.
I've tried connecting with a different user and same problem as well.
The strange thing is that that fingerprint is always displaying the same value, so not sure where it's coming from.
rbox.keys -> doesn't return anything, just []
rye keys -> NameError: undefined local variable or method `keys' for main:Object
rbox.host_key -> The process cannot access the file because it is being used by another process.
=> [, , 1, ]
Any idea what could be causing this issue and what else could I try to sort it out or work around it?
Many thanks!
This library is based on Ruby's Net::SSH and it is looking for cached host keys in ~/.ssh/known_hosts and /etc/ssh/knowh_hosts.
For more information see documentation on Net::SSH::KnownHosts.
It turns out that even though you connect from:
*Local_pc => *Middle_server => *Final_server
it doesn't matter in which of those 2 servers you are, it seems the 'known_hosts' file that's used is not that of any of those 2 servers, it's your LOCAL known_hosts file.
As such, you can either remove the entry for the specific host that's failing in your end or create the following .ssh/config file to ignore the host keys:
Host *
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
That config file is located in the following path in Windows:
C:\Users\<your_user>\.ssh\config
EDIT : (SOLVED) actually it probably was raised BECAUSE OF an infinite loop
I was coding and after adding a method I got this :
user_name#the_computer:/media/ECC3-C3B0/Prog/mts/src/mts$ rake test --trace
** Invoke test (first_time)
** Execute test
/home/user_name/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36: stack level too deep (SystemStackError)
rake aborted!
Command failed with status (1): [/home/user_name/.rvm/rubies/ruby-1.9.3-p19...]
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils.rb:53:in `block in create_shell_runner'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils.rb:45:in `call'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils.rb:45:in `sh'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:39:in `sh'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils.rb:82:in `ruby'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:39:in `ruby'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/testtask.rb:99:in `block (2 levels) in define'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:60:in `verbose'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/testtask.rb:98:in `block in define'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/home/user_name/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block (2 levels) in top_level'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block in top_level'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `block in run'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/gems/rake-0.9.2.2/bin/rake:33:in `<top (required)>'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/bin/rake:19:in `load'
/home/user_name/.rvm/gems/ruby-1.9.3-p194#global/bin/rake:19:in `<main>'
/home/user_name/.rvm/gems/ruby-1.9.3-p194/bin/ruby_noexec_wrapper:14:in `eval'
/home/user_name/.rvm/gems/ruby-1.9.3-p194/bin/ruby_noexec_wrapper:14:in `<main>'
Tasks: TOP => test
I'm pretty sure there is no infinite recursive loop involved.
The code is for now somehow gemified, but I also got the error running the ruby file directly.
Thank you for any help on how to (get some information to, run some tests to) fix the problem, if possible without having to rewrite the whole thing...
Environment :
ruby 1.9.3p194 / rails 3.2.8, installed via rvm
the program at this stage only uses rails string inflexions functions
OS : linux kubuntu i386
memory 4GO
'ulimit -s' : 8192 (stack size in kB)
What I tried unsuccessfully :
removed the chunk of code where the exception was initially raised, but it was still raised a tiny bit later at runtime
set stack size with command line 'ulimit -s 20000', 'ulimit -s unlimited'. Same error, apparently at the same place (which makes me think the stack size wasn't actually changed)
downgraded to ruby1.9.2 / rails3.1.3, got the same message
same error under Windows
Application context :
I'm writing an application that heavily uses ruby mixins.
Besides I created a bunch of classes that generate mixins (instance / class methods modules to be included by other classes).
So all in all I end up with quite a bit of generated named modules with some custom generated code, and classes with many ancestors.
But that should eventually save me quite a bit of pain in the as$ when I write the program that sits on top of this lib (that's the plan anyway).
Resources I used :
How to increase stack size for a ruby app. Recursive app getting: Stack level too deep (SystemStackError)
http://dalibornasevic.com/posts/5-ruby-stack-level-too-deep-systemstackerror
EDIT : Until some code is available for the showing/testing, let's abstract my question down to this one : Are there other cases that raise stack level too deep exception, besides the classical program-execution-tree-is-too-deep scenario (crossing fingers it's clear and means something...) ?
Are there other cases that raise stack level too deep exception, besides the classical program-execution-tree-is-too-deep scenario?
Yes. Since the stack is not measured in depth, but in bytes, anything stored on the stack will fill it up sooner:
def recurse(depth=0)
recurse depth+1
rescue SystemStackError
depth
end
=> nil
recurse
=> 8717
def recurse(depth=0)
a,b,c = 1,2,3
recurse depth+1
rescue SystemStackError
depth
end
=> nil
recurse
=> 7264
def recurse(depth=0)
a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z = *(0..25)
recurse depth+1
rescue SystemStackError
depth
end
=> nil
recurse
=> 3187
In this example, a function with only one variable can go several thousand calls deep before failing, and adding three more variables does very little; but adding 26 more variables balloons the stack size to a point where only around 3000 levels are available.
This will, of course depend somewhat on the ruby implementation, and the system it's running on. But I believe it will always hold as a general rule.
However, I still think recursion is likely your problem, since the number of variables required to have this happen at small call chain lengths is immense.