0

I want to set a cursor in javascript so when I use regex, it recognizes what data it has already parsed, and continues from that point. Below is a snippet of code that shows what the file is like.

# vtk DataFile Version 4.0

-3659.0757       3746.6780       3628.1143    
-3659.6714       3746.2517       3627.9539    
-3660.1450       3745.8142       3627.9270    
-3660.4631       3745.3735       3628.0605    
-3660.6931       3745.0708       3628.1416    

LINES 207 31529

581 0 1 2 3 4 ... 579 580

Currently I pick up the float float float pattern correctly, and I want my code to continue to LINES 207 31529 and then 581. This code picks up LINES, but instead of going to the 581 it goes back to the top of the file and takes 4 for numLines.

var LINES = /(LINES)[ ]+[\d]+[ ]+[\d]+[\n]/;
var recogLines = /[\d]+/;
var numLines = parseInt(recogLines.exec(data));

I saw something online about \G, but I don't think javascript recognizes that (or I'm just not using it correctly). How do I keep a cursor so the same data isn't iterated over and over again? Thanks!

  • JS does not support `\G`. Do you need to match `LINES 207 31529 581'? [Something like this?](https://regex101.com/r/eE3cE4/1) – Wiktor Stribiżew Jun 02 '15 at 15:28
  • I want the 581 but in a more general case, so without having to go off the LINES 207 31529 directly. –  Jun 02 '15 at 15:32
  • I'm not sure why people say javascript doesn't support global: /g – Jacob S Jun 02 '15 at 15:50
  • Are \G and /g the same thing? –  Jun 02 '15 at 16:02
  • Fair enough -- no, it isn't and I should have recognized that. I assumed you intended to parse all lines in the input since you want to start again from the end of the last match with the same pattern. Using /g (global) would provide an array of all matches in the file rather than re-using the pattern. I guess more info on what the "goal" is would help. – Jacob S Jun 02 '15 at 16:04
  • Rather than looking for all the matches, how do I look for matches in certain boundaries? –  Jun 02 '15 at 16:07
  • 1
    Unfortunately, javascript doesn't support matching beginning with a specific index. You could, however, use something like substring(result.index + result[0].length) to pass in everything after the last match. – Jacob S Jun 02 '15 at 16:11

1 Answers1

0

I would suggest something along the lines of (may not be exactly syntactically correct):

var LINES = '/(LINES)[ ]+([\d]+)[ ]+([\d]+)\n/';
var data = <input>;
var output = new Array();

result = LINES.exec(data);
while(result) {
   output.push([result[1], result[2], result[3]]);
   result = LINES.exec(data.substring(result.index + result[0].length);
}

but at that point, I would use the global modifier:

var LINES = '/^(LINES)[ ]+([\d]+)[ ]+([\d]+)$/gm';
result = LINES.exec(data);

would give you an array: 

array[0][2] // first LINE, first set of numbers
array[0][3] // first LINE, second set of numbers
array[1][2] // second LINE, first set of numbers
array[1][3] // second LINE, second set of numbers

Just my 2 cents.

Edit:

If you are writing a parse, I could see the reason for the first. Just add your code to parse the lines (and keep track of your cursor position) before running your pattern match again, and pass that to the substring instead of the index of the previous match plus the length of the match.

Jacob S
  • 1,693
  • 1
  • 11
  • 12
  • Alternatively, you could simply locate all the keywords in the file, since it gives you the index of the match, and you'll know that the data follows it `/^(POINTS|LINES|VERTICES|...)/gm`. Each match will give you the index, and substring(result[x].index, result[x+1].index - result[x].index) will give you each "group" which you can then parse. Throw in a condition for reaching the end of the matches (assumedly end of file ends from previous match). For huge datasets the first option will still be best. – Jacob S Jun 02 '15 at 16:39
  • [For a number of reasons, it is better](http://stackoverflow.com/a/6047611/778975) to use the array literal `[]` to create a new arrays instead of the constructor function `Array`. – Useless Code Jun 03 '15 at 04:03
  • For a number of generally subjective, assumption-based, opinion-based and "what if" reasons, as well as a "possible" performance difference, I completely agree. Good of you to point it out in case he needs to squeak out a few extra CPU instructions. – Jacob S Jun 03 '15 at 13:28