Re: [Bug-apl] Remaining APserver issues

2014-07-31 Thread Juergen Sauermann
Hi Elias, thanks - that explains a lot. I changed the code to use popen() rather than fork() + execve(). That way I can see when APserver has bound its socket. SVN 409. /// Jürgen On 07/31/2014 12:24 PM, Elias Mårtenson wrote: I did another test and added a two-second sleep after attempting t

Re: [Bug-apl] Remaining APserver issues

2014-07-31 Thread Elias Mårtenson
A typo in the above email. The two-second delay was added *before* the connection attempt, of course. Regards, Elias On 31 July 2014 18:24, Elias Mårtenson wrote: > I did another test and added a two-second sleep after attempting to > connect to the APserver, and that removed the problem. Thus

Re: [Bug-apl] Remaining APserver issues

2014-07-31 Thread Elias Mårtenson
I did another test and added a two-second sleep after attempting to connect to the APserver, and that removed the problem. Thus, I conclude that the issue is that the APserver doesn't have time to initialise before the parent tries to connect. I'd like to propose that APserver sends a message to t

Re: [Bug-apl] Remaining APserver issues

2014-07-30 Thread Elias Mårtenson
I've checked, and here are the results. I noticed that sometimes the APserver gets killed when I )OFF the interpreter, and sometimes it doesn't. $ *dist/bin/apl --silent -l 37* sizeof(Svar_record) is328 sizeof(Svar_partner) is 28 initializing paths from argv[0] = dist/bin/apl initializing p

Re: [Bug-apl] Remaining APserver issues

2014-07-29 Thread Elias Mårtenson
I will definitely check this when I get back to the office tomorrow. I'll keep you posted. Thanks and regards, Elias On 29 July 2014 21:13, Juergen Sauermann wrote: > Hi, > > that makes me think that APserver is listening on a different socket type > than the one apl is using. > Therefore, ne

Re: [Bug-apl] Remaining APserver issues

2014-07-29 Thread Juergen Sauermann
Hi, that makes me think that APserver is listening on a different socket type than the one apl is using. Therefore, netstat -l -p to see where APserver listens and apl -l 37 to see where apl tries to connect. /// Jürgen On 07/29/2014 03:07 PM, Elias Mårtenson wrote: I don't think so. The

Re: [Bug-apl] Remaining APserver issues

2014-07-29 Thread Elias Mårtenson
I don't think so. The APserver is definitely started. Also, if I start another apl it's able to connect to the previous one. My theory is the same as before, I think that apl attempts to connect to APserver before it's ready to accept connections. Also, given the fact that apl never connects to A

Re: [Bug-apl] Remaining APserver issues

2014-07-29 Thread Juergen Sauermann
Hi Elias, looks like either no APserver is running or the APserver listens on another socket. Check with netstat -l -p. That should show a line like: tcp0 0 localhost:16366 *:* LISTEN 2631/APserver If the APserver does not get killed then this is the pr

[Bug-apl] Remaining APserver issues

2014-07-28 Thread Elias Mårtenson
The following happens on my Arch Linux system. When I start the apl binary (without Emacs) I'm getting a "connection refused" error. The log with *-l 37* is reproduced below. The APserver is properly started (I can see it in the process listing), but after I call )OFF, it doesn't get killed. Not