I have a piece of javaScript that works (alongside html) to produce the GUI for a program written in C++. The program has to run for a long time (Sometimes 14/15 days, without monitoring).
The C++ and javaScript communicate by writing to/reading from a XML file.
After running the program for over 24 hours at a time, I've noticed the occasional javaScript error appearing 'someArray[...].name' is null or not an object.
Now: These are all arrays that are filled with information taken from the XML file, written by the C++. The contents of these arrays are refreshed every few seconds (To update information in the GUI 'live').
Question is: Could these errors be caused by an access/timer problem as in --> The javaScript starts reading a line from the XML just as the C++ swoops in and rewrites that line. Therefore information is parsed into the javaScript arrays with some illegal characters (etc) which when accessed throws the errors?
Hope that all makes sense. Thanks.
Your suggestion seems to provide a plausible explanation of what's happening.
You're probably seeing a race condition.
To fix it, you could implement a synchronization mechanism between C++ and JS.
The simplest form of sync I can think of is creating a second file each time C++ writes to your main XML file (this file acts as a lock). JS waits for the lock file to disappear before reading the XML. The same is done on the C++ side.
Sample code:
C++:
while(programRunning) {
do stuff;
// Now it's time to write XML
while("lockCpp.txt" exists)
; // Do nothing, JS is reading
create file "lockJS.txt";
write to xml;
delete file "lockJS.txt";
}
JavaScript:
while(programRunning) {
do stuff;
// Now it's time to read XML
while("lockJS.txt" exists)
; // Do nothing
create file "lockCpp.txt";
read xml;
delete file "lockCpp.txt";
}
This should in practice eliminate race conditions (though some are theoretically, possible, but unlikely).
Should JS not be allowed to write to the file system, then you could remove one of the lock files (lockCpp.txt) and, if the reading on the JS side is normally faster then the writing, it should still eliminate most conflicts.
EDIT after comment:
If you only have access to JS, you could check that the XML document is complete when reading, e.g. the root element is correcly matched by a </rootElementName> at the end.
That will ensure the file write is complete provided C++ doesn't do writes at random locations, but always rewrites the whole document.
Another route would be checking the file is not changing over time. If C++ only sporadically writes to XML, you can read it a few times over a few, say, seconds, and, if unchanged, use the read value. If changed, keep waiting.
HTH
Related
I have a program that logs every GET/POST request made by a website during the page load process. I want to go through these requests one by one, execute them, and then determine if the file that was returned is a Javascript. Given that it won't have a .js ending (because of scripts like this, yanked from google.com a minute ago), how can I parse the file gotten from the request and identify if it is a Javascript file?
Thanks!
EDIT:
It is better to get a false positive than a false negative. That is, I would rather have some non-JS included in the JS-list than cut some real JS from the list.
The javascript link that you referred does not have a content type, nor does it have the js extension.
Any text file can be considered javascript if it can get executed which can make detection from scratch very difficult. There are two methods that come to mind.
Run a linter on the file contents. If the error is a syntax error or a Parsing error, it is not javascript. If there are no syntax error or parsing error, it should be considered javascript
Parse the AST (Abstract syntax tree) for the file contents. A javascript file would parse without errors. There should be a number of AST libraries available. I haven't worked with JS AST, so can't recommend any one of them but a quick search should give you some options.
I am not sure but probably a linter would also run AST before doing syntax checks. In this case, running AST seems like a lighter option.
The easiest way would be to check if there was anything identifying javascript files by their URI, because the alternatives are a lot heavier. But since you said this isn't an option, you can always check the syntax of the contents of each file using some heuristic tool. You can also check the response headers for its content-type.
I am writing a Media-HUD that runs totally on local notecard files stored within the prim's inventory, with notecards named like index.html, style.css, icon.svg etc.
My hope is to use the LSL HttpServer functions, and the script's URL to create a totally self-contained media based HUD that is easy to edit like editing any web page.
This is completely possible on its own, however there is a limitation in that, the pages must fit into the memory allocated to the LSL script. Under mono this is only 64kb.
I want to remove this limitation, by somehow, perhaps from javascript, reading in each 'file' from a notecard line by line in the users browser itself (thusly, getting around the memory limit by only bringing one notecard line into memory at a time).
Is there a way to do this? generate a entire file in javascript procedurally by loading in the strings making it up line by line, and then serve it as though it were a whole file? I'm not sure how feasible this is.
Any idea's/guidance greatly appreciated!
You could do this through Javascript using XMLHttpRequest. jQuery's wrapper for this is called Ajax. You could request each line individually, which would be slightly slower, or read in a number of lines at a time, at the script's leisure. http_request is not throttled so either works. Note that the loader has to be sent in a single response, because the LSL server has no way of pushing data "piecemeal" like an actual server does.
Notes:
llGetNotecardLine only returns the first 255 bytes per line.
llHTTPResponse must be called within ~20 seconds of the request, so you can't feasibly read more than 20 lines from a notecard at a time.
I'm not sure how this would work for non-DOM filetypes. All files would need to be embed-able in the HTML using the Javascript DOM. To my knowledge, Javascript can't arbitrarily create an external file and serve it to itself. Obviously it would not work for non-text filetypes, but you could certainly load in the rest of the HTML, CSS, and HTML5 SVG. Basically, if it can go in a single HTML file, you could load it in through Javascript.
I have no experience with React but it gives a good example of what is possible on the UI side with loading things in purely through Javascript.
So less than 64 thousand characters in memory at most per script. I will give you some advise that might make your task feasable:
External resources
Minimize the amount of code you have to have in your notecards by sourcing popular libraries from the web Bootstrap, React and such.
You will have to rely on their mirror's availability thought. But it will greatly reduce the amount of memory needed to provide pretty and functional pages.
Minify your code
Use tools like Uglify or Closure Compiler to make your javascript lighter. Though you must be careful, as these tools will fit all your code a single long line by the default, and you can't read lines longer than 255 characters with LSL. Luckily you can customize your options in these tools to limit the amount of characters per line.
Divide and conquer
Since a single script can't handle much memory, make dedicated scripts. One could serve resources (act as a file server, providing your html and js) while the other would receive API request calls, to handle the application's logic.
I have been shown a trick - instead of having the data in datafile.json and load it with ajax, the data is encapsulated in a single object in a datafile.js such as var Data = { //all data goes here }. Then the datafile.js is just loaded as external script in the html head
It works well just as if the objects were loaded with ajax, are there any drawbacks to this?
JSON is JavaScript. (Back in the day, the idea was that you could simply eval it ...) Therefore, the file that you speak of is simply ... "a JavaScript assignment-statement, stored in a file."
The only potential issue with storing this as a separate file might be "a timing hole." The source-code must be separately retrieved. I'm not sure if the browser would wait to do that, so it might be possible for other JavaScript code to execute that does not see var Data because that block of code hasn't been retrieved and executed yet.
When you have "lots of invariant fixed data," I customarily put everything including the data into one ("yeah, it's big ...") JS file, so that I know "it's all there" before any of it tries to be executed. Yes, there are definite advantages to simply including fixed data directly into your source-file, as you're effectively doing here, but I'm not sure I see an advantage (and, I might see a hole ...) in using several JS files.
I have 3 questions, but I think the first 2 are very simple, so I'll ask them all here.
I normally work in C++ with SQL (and sometimes with VBA), and I'm trying to figure out the basics of JS, PHP & HTML (I've mostly got the jist of HTML and CSS).
I have 5 different reference books plus the net, but one thing I can't seem to find anything about are the file exts (.js, .php, .html).
From my tests I have come to realize that you can usually run JS scripts in other file types, but PHP seems to require the .php ext.
So the questions are:
Do I always have to use *.php for PHP scripting?
In a SINGLE file, can I delay PHP execution by simply putting the code into a function?
eg
<?php
function test() {echo "hello world";}
//as opposed to:
echo "hello world";
?>
When using multiple files, are there any compelling reasons to (or not to) always put scripts in their corresponding file types (e.g. JS in *.js). Obviously this would make it easier to understand / read, especially as it grows BUT can this create problems?
No, you can use any extension you want. Even if you want, don't use extension at all. But then, tell your server what interpreter to use when he founds he has to parse a *.wtf file. I mean, you're running a the script "file.wtf" from the command line you can do it like this:
$>php file.wtf
but if the script is to be parsed by your favorite web server (like Apache) because it is part of (say) a web page, then you have to configure it to interpret .wtf files with the PHP library.
By simply putting it in a function:no. But you really want to delay execution, use the sleep function
Just what you said: You can mix html and javascript code in your php files, but that is very messy.
I have some code that reads from an ini file in Javascript, using activex filesystem objects.
This isn't particularly efficient but does the job, reading the whole file into an array, appending any changes and writing back.
The problem i'm having is that another process, a C# XBAP application is reading from this ini file (using getprivateprofilestring) at the same time as I could potentially be trying to write to it in the JS.
The javascript fails as the file is locked, or part of it, and the file ends up getting corrupted or even totally cleared - as I am trying to write back the whole file each time.
Preferably, what I need is a way to determine if a file is locked in javascript, as the writes are not urgent and I want to let any reads finish first.
Just can't seem to find anyway of syncing these two completely seperate ways of accessing the file.
May be you could use try/catch. If you open the file for appending (OpenTextFile([filename],8)) it should raise an exception. Same should be true for writing/saving the file (if the file is locked try raises an exception).