Rack::Reloader not picking up changes - sinatra

Consider this config.ru file:
require 'sinatra'
use Rack::Reloader, 0
get '/' do
'hi'
end
run Sinatra::Application
I start it from the command line with thin start. The application runs and shows hi when I hit localhost:3000. If I now change hi to hello, save the file, and reload the page, the change does not appear: the page still says hi.
Why does Rack::Reloader not work in this case? Can I change anything to make it work?

See here for a detailed explanation of what's happening. Essentialy everytime your file is changed, Rack::Reloader re-requires it.
Unfortunately with Sinatra, if you redefine a route a second time (which is what happens when you re-require), sinatra ignores the new definition since get '/' do end is already defined!
What you will need to do is reset any defined routes you have as well:
# inside app.rb
require 'sinatra'
require 'rack'
configure :development do
Sinatra::Application.reset!
use Rack::Reloader
end
get '/' do
'hi'
end
Note that sometimes it takes a few seconds (5s on my machine) for the changes to be reloaded and I recommend you take a look at the alternatives here

Related

coqIDE is not properly connecting files in project and is not compiling

I'm new to using coq/coqIDE and I'm not computer savvy either so I don't know whats wrong or what to call the issue. I was trying to go through the Software Foundations book, but coqIDE isn't working right. I'm using the latest windows 10, and coqIDE 8.10.2
The first issue is when I go to the tab compile -> compile buffer in Basics.v, coqIDE doesn't create a .vo file or a .glob. None of the other buttons worked either. Running coqIDE as admin didn't make it work either, but I figured out I can get around this by manually dragging Basics.v into the coqc application file.
I had no issues with coq working during the first lesson, but in the next lesson we're meant to import the definitions from Basics.v into Induction.v, when I run what they say
From LF Require Export Basics.
I get the error The file C:\Users\...\Coq Files\Tutorial\lf\Basics.vo contains library Basics and not library LF.Basics even though the _CoqProject file contains "-Q . LF" as it should.
I can get around this error too by just writing "Require Export Basics."
which properly loads, up until I actually try calling a definition from Basics
Running
Require Export Basics.
Example example: evenb 2 = true.
works until I get to evenb, and then gives the error
The reference evenb was not found in the current environment. even though it's in Basics.v
If I get even more anal and try
Add LoadPath "C:\Users\...\Coq Files\Tutorial\lf".
From LF Require Export Basics.
I get the error
Cannot find a physical path bound to logical path matching suffix <> and prefix LF.
And then finally if I try
Add LoadPath "C:\Users\...\Coq Files\Tutorial\lf".
Require Export Basics.
Example example: evenb 2 = true.
Loads properly.
So I'm wondering how should I fix the load path so that the project works without putting that junk in every file and how do I make the compile tab work.
There were some people talking about "hitting make in the top-level" but I have no idea what that means. I tried it anyway and ran the Makefile as a .bat even though I already downloaded it properly so there shouldn't be any need, but the Makefile didn't change anything anyway.
I don't think I'm forgetting anything, thanks in advance.
Instead of choosing Compile > Compile buffer, try Compile > Make instead (when browsing any one of the vernacular files in Logical Foundations) - I think that is what others meant by "hitting make in the top-level". But first, you may want to remove the workarounds you added in e.g. Induction.v, and save a trivial change in Basics.v such as adding/removing a newline somewhere in order to convince make to recompile it.

Another way to set DB::deep?

When debugging complex code using standart Perl debugger in NonStop mode sometimes we get 100 levels deep in subroutine calls error.
Is there another way to set $DB::deep variable, without touching code ?
I tried to use dumpDepth option, but seems like it's not available in NonStop mode.
I know about perl -MPerlIO='via;$DB::deep=500' hack, but it's not working with perl version >= 5.20
Create a ~/.perldb file with
$DB::deep=500
Set permissions on this file to something secure (0444 or 0644) so you don't get this admonishment:
perldb: Must not source insecure rcfile /Users/mob/.perldb.
You or the superuser must be the owner, and it must not
be writable by anyone but its owner.

Set arbitrary breakpoint in debugger

I have been using the perl interactive debugger (basically perl -d script)
I have a script that has quite a lot of modules imported and I need to debug a problem.
What I do is start the debugger and go over lines, stepping into where necessary.
But this is tedious as I need to step into many lines of code and function calls.
Question: Let's say that after going over the lines of code I eventually step into function A::B::C::foo() of some module where is the problem I am debugging.
Is there a way to set a break point in that function in the beginning of the debugging session so that I jump there directly instead of going over the code line by line until I reach there?
I know that I can add a break point in the same file my debugger is currently but how can I add a breakpoint in a line that is outside of the debugger's scope at this point (to some arbitrary file/module that eventually the debugger would have reached)?
Note:
Just to clarify: It is not like A::B::C::foo() is in line X of the script. It is eventually called after going down the call chain of a lot other functions in many modules
You can set a breakpoint to a subroutine with the documented b sub syntax. In this case, just use
b A::B::C::foo
c
You may set a break point by defining file name and then line number
b YourModule.pm:line_number
where line number is inside the module function you want to break at.
You can even put a breakpoint on a sub that hasn't been loaded/defined yet using the postpone option:
b postpone Name::Of::Sub::Yet::To::Be::Created

writing own oh-my-zsh plugin

I want to write a simple plugin for oh-my-zsh completing only possible server arguments.
Example 1:
$ myserver st # hits tab
start stop
Example 2:
$ myserver # hits tab
start stop restart
According to wiki I have created file named ~/.oh-my-zsh/custom/plugins/myserver/myserver.plugin.zsh with sample content of coffee plugin (I tried brew plugin as well) but completition doesn't work (any of described in file). Moreover error is thrown:
_arguments:comparguments:312: can only be called from completion function
I checked similar problems and my fpath includes ~/.oh-my-zsh/custom/plugins/myserver.
What am I missing? This should be pretty simple... Thanks for help
From your post I'd assume that you have named the file myserver.plugin.zsh, however, if it is used to define a completion function its name must start with an underscore. It seems to be customary that the underscore is followed by the command name, i.e. in your case _myserver.
However, without the explicit code you are using I can not help you any further. You might want to check this blog post for further help.
I should remark that it is completely unnecessary to design a completion function as oh-my-zsh plugin; just create it as standalone piece of code.

How can I force unload a Perl module?

Hi I am using a perl script written by another person who is no longer in the company.
If I run the script as a stand alone, then the output are as expected. But when I call the script from another code repeatedly, the output is wrong except for the first time.
I suspect some variables are not initialised properly. When it is called standalone, each time it exits and all the variable values are initialised to defaults. But when called from another perl script, the modules and the variable values are probably carried over to the next call of the script.
Is there any way to flush out the called script from memory before I call it next time?
I tried enabling warning and it was throwing up 1000s of lines of warning...!
EDIT: How I am calling the other script:
The code looks like this:
do "processing.pl";
...
...
...
process(params); #A function in processing.pl
...
...
...
If you want to force the module to be reloaded, delete its entry from %INC and then reload it.
For example:
sub reload_module {
delete $INC{'Your/Silly/Module.pm'};
require Your::Silly::Module;
Your::Silly::Module->import;
}
Note that if this module relies on globals in other modules being set, those may need to be reloaded as well. There's no easy way to know without taking a peak at the code.
Hi I am using a perl script written by another person who is no longer in the company.
I tried enabling warning and it was throwing up 1000s of lines of warning...!
There's your problem right there. The script was not written properly, and should be rewritten.
Ask yourself this question: if it has 1000s of warnings when you enable strict checking, how can you be sure that it is doing the right thing? How can you be sure that it is not clobbering files, trashing data sets, making a mess of your filesystem? Chances are it is doing all of these things, either deliberately or accidentally.
I wouldn't trust running an error-filled script written by someone no longer with the company. I'd rewrite it and be sure that it was doing what I needed it to do.
Unloading a module is a more difficult task than simply removing the %INC entry of the module. Take a look at Class::Unload from CPAN.
If you don't want to rewrite/fix the script, I suggest calling the script via exec() or one of its varieties. While it is not very elegant to do, it will definitely fix your problem.
Are you sure that you need to reload the module? By using do, you are reading the source every time and executing it. What happens if you change that to require, which will only read and evaluate the source once?
Another possibility (just thinking aloud here) could be to do with the local directory? Are they running from the same place. Probably wouldn't work the first time though.
Another option is to use system ('doprocessing.pl');. Lazily, we do this with a few scripts to force re-initialisation of a number of classes/variables etc. And to force the log files to rotate properly.
edit: I have just re-read your question, and it would appear that you are not calling it like this.