* error check, developers with V7

[Ron Melby]

can you please find one of your plugins that does an io.open that you can quickly debug, and change it to io.popen and debug on and just after it please? Obvs, fh is not fixing errors in v6, so I need to know if your fh quietly strangles and blacks out and goes casters up when you execute the statement, so I can turn in a ticket.

let me know, thank you.

seems to me if they won't allow it, then they should throw an error instead of leaving the building.

[tatewise]

The statement local handle = io.open("C:\\...\\ZZZ.txt","r") in both FH v6.2 and FH v7.0 returns a valid handle.
Then local text = handle:read() allows the text file to be read.

I've tried local handle = io.popen("C:\\...\\ZZZ.txt","r") in both FH v6.2 and FH v7.0 without any major problem.
In both cases, it opens a CMD Prompt black window and opens the text file in Notepad as well as returning a handle.
That is what io.popen() is intended to do, i.e. open the file. It is a modal operation.
The handle should let you read or write, but handle:read() locks the Plugin and FH with (Not responding).
The Plugin will not complete until the CMD Prompt window or the Notepad window are closed.

If the file is an executable program then the program should get run, but the ones I have tried don't run.

[ColeValleyGirl]

I'll add that the io library is part of lua and not fh, so the people who won't be fixing it are the lua authors.

[Ron Melby]

it may be that mine strangles and dies because my default is EditPadLite.

[tatewise]

What exactly are you trying to achieve?
Are you trying to open a text file in your default editor EditPadLite?

[Ron Melby]

no, I did not understand the meaning of opens in another process as I read the documentation for it.

what I had hoped it meant, was that I could write files using another memory space with Io buffers allocated there and separately, thereby giving me more lua memory space in my program, I was trying to cheat.

nevertheless, I am using (largest I saw on the task monitor) around 974K max to write that table that chill code crashed on (integer size too large) and can store it in 92,244KB down from 188,173 KB which I was doing before we went thru that exercise in running thru _G. Took some lessons from there and---- rather than saving in minutes, saves in less than a computer minute. realtime-- maybe a minute and a half, to two. I write it, so that it results in one string to file, but write in pieces. I am now fretting about whether is it less overhead to put the string on a tower of hanoi stack, and then glue and write the stack at '},' writing time (lvl = lvl -1) in that code referenced before. do you have a feel, save up the string like:
(global) local line = ''
function string:append(str)
line = ('%s%s'):format(self, str)
end
(ignore the tower of hanoi for the moment) just glue it.
so
var:append(line)
var:append(line)
key:append(line)
and so on in the table loop


then at end of table entry:
lvl = lvl - 1
'},':append(line)
_outf:write(line')
line = ''
end



as opposed to many (but the same number of:

_outf:write(('%s%s%s'):format(_pre, _var, _post))
_outf:write(('%s%s%s'):format(_pre, _var, _post))

if valtyp ~= 'table' then
-- wrt_fmt(lvl)
wrt_var('[' , key, ']=' )
wrt_var('' , val, ',' )
end

do you have a feel for whether or not it it worth it?

[tatewise]

To write to a file simply use:
local _outf = io.open("C:\\...\\outfile.txt","w")
_outf:write(('%s%s%s'):format(_pre, _var, _post))

I suspect that is more efficient than appending text strings, which is known to be very resource hungry.
Every time the line is appended, another chunk of memory is needed for the longer text and the old memory chunk has to be garbage collected later.

That is why it is better to use table.insert(t,line) which only adds a memory chunk for each new line of text until the final table.concat(t) grabs a chunk for the entire text.

See https://www.dannyguo.com/blog/how-to-co ... gs-in-lua/
See http://lua-users.org/wiki/StringsTutorial under Concatenation last 3 examples -- slow, -- fast, -- fast, but uses more memory