How to tell if route_cgi.lsp is running?

[ghyll]

tldr: How do I tell whether route_cgi.lsp is running?



A "submit" button on index.nhtml POSTs to script.nl. Instead of getting the desired/expected response from script.nl, I get the full text of the script file.



index.nhtml and script.nl are both in /views, and route_cgi.lsp is in /plugins-active... however, the same thing happened when route_cgi.lsp was in /plugins-inactive.



I got stuck trying to debug because I do not know how to verify whether route_cgi.lsp is loading/running. It doesn't show up in the network debugger (but I don't know if it should), but script.nl does.

I apologize for asking such a simple question. I have no other experience with web frameworks or cgi. I tried google, but all the answers seemed to be specific to PHP or Perl, etc.



Thank you for any help. :)

[hilti]

Hi Ghyll!



Welcome to the newLISP world! Any questions are great and will help others learning.



First questions:

1. Why are You using .nhtml as extension for the views - just use .html and Dragonfly will execute it

2. Working with forms is easier via resources (http://dragonfly.neocortex.io/dragonfly_routes">//http://dragonfly.neocortex.io/dragonfly_routes)



If You'd like just sent me the code as a ZIP and I'll help You out.



Greetings from Germany

Marc

[cormullion]

Hi Marc - what happened to http://www.rundragonfly.com">//http://www.rundragonfly.com? I went there the other day (problems with Dragonfly and newlisp v10.6) and I didn't understand a thing (although I liked the castle) !

[ghyll]

Hi Marc, thanks for the help :)  Unfortunately, the code is proprietary, so I can't take advantage of your offer to check a ZIP.



1. .nhtml is for views containing newLISP code, and .html is for views without -- just an easy way to check at a glance.

2. The .nl script is not RESTful, so I don't think it would properly translate to a resource. (Not fixing the cgi bit would also require re-writing all of the other .nl scripts as resources.)



route_cgi.lsp is loading -- I had it print something on the view (apologies for not thinking of this before I posted). The .nl script still isn't running, but I'll keep troubleshooting.

[hilti]

what happened to http://www.rundragonfly.com">http://www.rundragonfly.com?

I just quit a lot of rare used domains including this one. I'll put the Dragonfly Example Site under my current main domain uberberg.com.



Or just Google "dragonfly example-site" (https://www.google.de/#q=dragonfly+example-site&start=10">//https://www.google.de/#q=dragonfly+example-site&start=10) to find some Dragonfly users ;-)





Update:

It's here: http://dragonfly.uberberg.com">//http://dragonfly.uberberg.com

[cormullion]

Cool, thanks! On Github there are a number of other repos too - e.g. https://github.com/marchildmann/Dragonfly">https://github.com/marchildmann/Dragonfly (Last updated 6 years ago... ! :)). And there's a four-year old version (https://github.com/taoeffect/dragonfly-newlisp">https://github.com/taoeffect/dragonfly-newlisp).



I've been tinkering with my local copy (I had problems when the host upgraded to 10.6, don't know what they were, though). It's still nice and quick though!



Perhaps sometime you can put the definitive latest version on Github and people can start putting in pull requests...



BTW Google Code is http://google-opensource.blogspot.co.uk/2015/03/farewell-to-google-code.html">shutting down on January 25th, 2016.

[itistoday]

Hi Marc, thanks for the help :)  Unfortunately, the code is proprietary, so I can't take advantage of your offer to check a ZIP.



1. .nhtml is for views containing newLISP code, and .html is for views without -- just an easy way to check at a glance.

2. The .nl script is not RESTful, so I don't think it would properly translate to a resource. (Not fixing the cgi bit would also require re-writing all of the other .nl scripts as resources.)



route_cgi.lsp is loading -- I had it print something on the view (apologies for not thinking of this before I posted). The .nl script still isn't running, but I'll keep troubleshooting.

So dragonfly overrides print and println to send the output as part of the webpage that's returned.



You should use the DF:log-info, DF:log-warn and DF:log-err functions to send debug statements to the dragonfly.log file (which is specified by the LOG_FILE_PATH variable in config.lsp).

[ghyll]

You should use the DF:log-info, DF:log-warn and DF:log-err functions to send debug statements to the dragonfly.log file (which is specified by the LOG_FILE_PATH variable in config.lsp).

Changing 'LOG_LEVEL to 'LOG_DEBUG resulted in malloc errors and segmentation faults, which I'm unsure how to troubleshoot. The dragonfly.log entries from these times show:

Code Select Expand

[ERROR]: ERR: list or string expected in function find : nil
called from user function Dragonfly:eval-template
called from user function Dragonfly:display-file
called from user function Dragonfly:display-view
called from user function Dragonfly:display-error
called from user function $error-event
with all but the first line repeated dozens of times.



I am using Dragonfly 0.72, and have made only the following changes to Dragonfly:

- route_cgi.lsp moved to /plugins-active

- (constant 'VIEW_EXTENSION ".nhtml") [line 36 of config.lsp]

- (constant 'LOG_LEVEL 'LOG_DEBUG) [line 78 of config.lsp]



I'm continuing to fiddle and troubleshoot, but of course appreciate any help figuring out what might be preventing the .nl script from running. :-)

[itistoday]

Code Select Expand

   [ERROR]: ERR: list or string expected in function find : nil
    called from user function Dragonfly:eval-template
    called from user function Dragonfly:display-file
    called from user function Dragonfly:display-view
    called from user function Dragonfly:display-error
    called from user function $error-event

Sounds like some HTML file that has newLISP in it has an improper call to 'find'.



As for segfaults, I can't help there, those shouldn't happen at all, and if they do that's something Lutz would need to help with.

[Lutz]

Some functions in newLISP have syntax patterns which can crash the system when not used properly. Most of these deal with hardware access or importing from C-libraries.



Improperly self-modifying code can also lead to crashes. So does using the delete function with reference checking turned off.



These cases are mentioned in the documentation. When properly used, these features are also what makes newLISP unique among scripting languages.

[ghyll]

A "submit" button on index.nhtml POSTs to script.nl. Instead of getting the desired/expected response from script.nl, I get the full text of the script file.

Changing 'LOG_LEVEL to 'LOG_DEBUG resulted in malloc errors and segmentation faults, which I'm unsure how to troubleshoot. The dragonfly.log entries from these times show:

Code Select Expand


   [ERROR]: ERR: list or string expected in function find : nil
    called from user function Dragonfly:eval-template
    called from user function Dragonfly:display-file
    called from user function Dragonfly:display-view
    called from user function Dragonfly:display-error
    called from user function $error-event

Apparently, all of this trouble was not a problem with Dragonfly or the .nhtml, .html or .nl files I was using. Instead, it was somehow caused/triggered by unrelated data protection software.