Reading in REALLY long text lines

[shadow008]

So while writing my Collada loader, I've ran into some problems - most of which were worked out, but one I have no idea how to fix. Also I'm not sure it CAN be fixed.

Basically Collada writes it's mesh data in a very VBO friendly way. HOWEVER, it includes all verticies/normals/texture map coords on a SINGLE line (with spaces between values). Heres an example:

<float_array id="Sphere-mesh-mesh-positions-array" count="1470">0.1913415 0.03806012 -0.9807854 0.3753301 0.07465779 -0.9238796 0.5448951 0.1083863 -0.8314697 0.6935199 0.1379497 -0.7071068 0.8154932 0.1622117 -0.5555701 0.9061275 0.1802399 -0.3826833 0.9619398 0.1913416 -0.1950901 ...

Thats all a single line. It includes 1470 individual floating data values. Which approximates to about 14700 characters before the next EOL value. I think I read somewhere that a single line in b4gl is broken up into individual lines of 4096 characters each, allowing huge strings to be stored. NOT SURE if this is a problem with memory being massed so quickly, or some internal problem with the language itself. I guess the work around would be to read individual words up to spaces and store data that way, but that breaks the flow of my code After i read in that line, the program stalls, then I get a pop-up saying "Abnormal program termination" and the IDE crashes, taking any modifications with it.

Any thoughts?

Edit:

Weird, I can read the file in a separate program that just reads the line THE SAME WAY AS IN MY LOADER, assigns it to a variable string LIKE IN MY LOADER, then prints it (not in my loader) Hmmm...

[DJLinux]

Is it a local string var in your loader (function or sub) or a var from main code ?

Joshy

[Supermonkey]

Is the simple answer to just not read it all at once?

[shadow008]

DJLinux:

Thats what I immediately looked at. It WAS a local string variable in my function, but that WASNT the issue. Because I was able to replicate it in another program using local variables with no issues at all.

Supermonkey:

Long time, no see As for your question, the answer is no. The way of reading it character by character is just WAY too slow. Besides, I would have had to write a whole new method of reading the file.

Never the less, I have found the culprit. Using the debugger "stop" thing in the IDE line just after I read in the file line is the problem. When reading in large amounts of file text, then pausing the program, it always seems to crash. Might have to be that the file hasn't yet been closed, then just simply pressing the "stop" button in the IDE while the program is paused keeps the file "open" according to the VM, then all hell breaks loose?

Regardless, I have fixed that just by writing that part of the code then waiting to read in another line before using the "stop" for debugging. Works great, and I hope this helps with anyone else that might encounter this particular issue.