Re: My trail / Cache chain

Quote
arisoft
While debugging this I really missed the debug log output. Is there any possibility to get the output saved?

To be honest I am not sure how to solve the problem with getting the output from a process that's in an endless loop.

Your web browser is contacting a web server, which starts a PHP process (with LUA support). PHP-FPM is configured to kill the process after X seconds, the output is then lost.

I can currently think of two solutions.
1) Instead of outputting to stdout, write it to a file that can later on be retrieved. Since the LUA-sandbox doesn't have any functions that can read or write from/to disk a new PGC-api-method would have to be created for that purpose.

2) Build a standalone framework. In this case the LUA code would be run on your computer. One of the downsides would be that you have to install an environment for executing LUA. PGC would then need to expose the LUA callbacks as AJAX calls so that they can be fetched from LUA code in some way, probably via a built LUA library. While this has some advantages, it's a lot more work to implement, and has the mentioned downside that the developer would need LUA installed as well.

Of those suggestions I can think of right now, #1 seems easier. I'll get right at trying to implement it. I don't know how hard it will be yet.



Edited 2 time(s). Last edit at 02/06/2018 09:14PM by ganja1447. (view changes)

If there is no bad side effects while redirecting the current Print or special Debug -output to a temporay file for retriewing later, I would welcome this solution many ways. For debugging purposes it should flush the buffer on every write which makes it slower but more valuable for this purpose.

I will not override the current Print(). Mainly because the new method will be slower.

I will use a NoSQL storage where the logs will be stored. So every write is a write over the network. I assume an endless loop could potentially log quite often, and in those cases the network latency might affect the run-time.

I will add a PGC_Log() which should be used more for debugging/developing. It takes one string as a parameter, just as Print(), so it should be a fairly easy search and replace to switch between them.

Potentially, the code for logging is already in place, I am about to test it. If that seems to work, I just need to write some code to retrieve it as well.

Ok, a beta of the new function is now available. For now, I would suggest to do both Print() and PGC_Log(), but that's up to you. I'll explain how it works.

As mentioned before. The new function is PGC_Log(), it takes one parameter, it's a string. If you need a new-line at the end, you add it yourself, just as with Print().
Anything above 100 kB for each checker run will be truncated. The log will live for 3600 seconds, after that it's gone.

When clicking Run checker there is a new line added during the queue process, Using token. To view the log, take that token (md5 hash) and use it in an URL like this:
https://project-gc.com/Challenges?viewDebugLog=414880a109df7fd5be33983ab83cedc6 (but with the correct hash).

If it seems to work as it should, and actually solves the issue we are trying to solve, I will add links to the log in the responses as well.

Please get back to me with the result when you have tried it.

One idea: If the command works only when used from script author's account there would be minimal effect on production runs.

I start testing the new log function now. I need it for testing controlled time out handling. It just misses the limit sometimes.

I was thinking something similar, regarding the log for script author only. It would be quite easy to implement. On the other hand, it's probably quite easy to search and replace Log( into --Log( as well. Or have a if(debug).

Not sure what is the best solution. But let's start by seeing if it helps. As mentioned, there should be a few links in the UI as well for reading the logs. Having a secret URL to enter manually isn't very convenient.

Another note. The log you output isn't secure in any way. Anyone who has the link (the hash) can read it, as long as they are authenticated with Project-GC. On the other hand, the only security issue I can think of is if you log coordinates to premium geocaches and a none premium member finds the log. I wouldn't care too much. :)

First note about the syntax. It is not actually the same

Print(checkcount," / ",dt,"s\n")
PGC_Log(checkcount.." / "..dt.."s\n")

Print does not use concatenation because it is always "expensive" operation in LUA.

Ah, I can change the Log() function to take n variables instead. It's quite easy. It will automatically be backwords compatible to how it is now.

Pushing a release with this small patch in it:
$string = implode('', func_get_args());

I will also split this topic so that this new "method request" gets its own thread. We are starting to get a bit deep in the threading on the forum.

Something happened to newlines. The first version did separate lines on screen but now newlines are visible only in the source and text is flowing wihout newlines.

Log storage seems to work correctly. I already managed to find a problematic situation from the saved log.

EDIT: Sometimes it works and sometimes browser does not display newlines. page type is text/html. It changes to html for some reason but not always.



Edited 2 time(s). Last edit at 02/06/2018 11:32PM by arisoft. (view changes)

I found a solution to the missing newline issue.

The log file starts this way:

<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"></head><body>

It did not help to change it text/plain but if you add <pre> in the beginning - then it works fine.

<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"></head><body><pre>