Cleaning up in logout() is ok. Sending emit loginDone() in readOutput() is not very clean. Everything login related should be done in login(). What do you mean with "we emit this signal before we real finish preparation"? Is m_process->waitForReadyRead(); in OctaveSession::login() not enough to collect and to parse the initial output of octave?

In D12565#255055, @asemke wrote:

Cleaning up in logout() is ok. Sending emit loginDone() in readOutput() is not very clean. Everything login related should be done in login(). What do you mean with "we emit this signal before we real finish preparation"? Is m_process->waitForReadyRead(); in OctaveSession::login() not enough to collect and to parse the initial output of octave?

Acording to Qt documentation

waitForReadyRead(): Blocks until new data is available for reading and the readyRead() signal has been emitted

And we have connect ( m_process, SIGNAL ( readyReadStandardOutput() ), SLOT ( readOutput() ) );
But we wait only for readyRead() signal and qt don't garantee, that the slot, connected to this signal, already have be executed.
So, we could emit loginDone before backend set m_prompt and m_tempDir. Now it doesn't happends, but it could be possible or I am wrong with it and it's not a problem.

I was thinking about getting the octave prompt like lua backend: connect output to special function for reading prompt, which at the end of work reconnect output to parsing functions and emit loginDone signal.
Well, now lua emit loginDone signal in login function, so sometimes I loose first comand in the lua tests, because the backend run expression before reading the prompt and I got something like this:
reading the intro message "Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio\n> print(2+2)\n4\n> "

But maybe I have made a mistake, when have move the signal emit statement in this patch.

In D12565#255166, @sirgienko wrote:

In D12565#255055, @asemke wrote:

Cleaning up in logout() is ok. Sending emit loginDone() in readOutput() is not very clean. Everything login related should be done in login(). What do you mean with "we emit this signal before we real finish preparation"? Is m_process->waitForReadyRead(); in OctaveSession::login() not enough to collect and to parse the initial output of octave?

Acording to Qt documentation

waitForReadyRead(): Blocks until new data is available for reading and the readyRead() signal has been emitted

And we have connect ( m_process, SIGNAL ( readyReadStandardOutput() ), SLOT ( readOutput() ) );
But we wait only for readyRead() signal and qt don't garantee, that the slot, connected to this signal, already have be executed.
So, we could emit loginDone before backend set m_prompt and m_tempDir. Now it doesn't happends, but it could be possible or I am wrong with it and it's not a problem.

I was thinking about getting the octave prompt like lua backend: connect output to special function for reading prompt, which at the end of work reconnect output to parsing functions and emit loginDone signal.
Well, now lua emit loginDone signal in login function, so sometimes I loose first comand in the lua tests, because the backend run expression before reading the prompt and I got something like this:
reading the intro message "Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio\n> print(2+2)\n4\n> "

But maybe I have made a mistake, when have move the signal emit statement in this patch.

Yes, this all is a bit inconsistent in Cantor for different backends. I'd rather go for a solution where all the initial stuff is done in login() only. So, parsing of the promt, if required, emitting of signals etc. should be done in login(). This is the case for example in juliasession.cpp where the output is read until "ready" comes. parseOutput() should be used for parsing of the expression outputs only. This would lead to a more clear and consistent architecture in Cantor. Once this is done in octavesession, this should also solve the problem you propose to fix here.

In D12565#255334, @asemke wrote:

Yes, this all is a bit inconsistent in Cantor for different backends. I'd rather go for a solution where all the initial stuff is done in login() only. So, parsing of the promt, if required, emitting of signals etc. should be done in login(). This is the case for example in juliasession.cpp where the output is read until "ready" comes. parseOutput() should be used for parsing of the expression outputs only. This would lead to a more clear and consistent architecture in Cantor. Once this is done in octavesession, this should also solve the problem you propose to fix here.

Well, I think I have understood you now, so I remove the emit changes and will start to work on solution, which have all init logic in login and don't return, until all preparation will be done.