Page 1 of 1

[done] Launcher for newLisp

PostPosted: Fri Sep 12, 2008 9:30 pm
by noiv
Editra is out of the box ready for newLisp with project management and syntax highlighting.
Would you mind to spend the launcher the capability to launch these kind of scripts?

PostPosted: Fri Sep 12, 2008 10:09 pm
by cody
Ok, I just added a simple handler for it. If you can help me with a few other things I can add better support.

1) Is there any docs on the kind of exception traceback formats if any, so I can add support for clicking on the error to jump in the file where it happened.

2) Is the only common command line usage of it to call 'newlisp'?

3) Are you using the current svn, because it has better newLisp support. The current release version is using the standard lisp support for newLisp. But the latest svn has a separate handler for newLisp.

Also note Launch currently only supports running and displaying output, so interactive command line programs that read from stdin are not currently supported.



PostPosted: Sat Sep 13, 2008 10:31 am
by noiv
Thanks for responding!

Found the handler for newLisp, already using it.

Command line + exit codes are described here:

No problem with displaying output only in launcher.

PostPosted: Sun Sep 14, 2008 1:11 pm
by noiv
Could you add a bit more program control like killing zombies with the abort button
and displaying the output to the launcher?

However, the look and feel is already great, I'm now considering to switch
to Editra for the Internet duties....

PostPosted: Sun Sep 14, 2008 5:37 pm
by cody

The abort button sends a SIGKILL (on Linux/OSX) and a TerminateProccess on Windows to terminate the process that was started in Launch. What problem are you seeing and what operating system are you on?

Any output that the running process writes to stdout/stderr should be getting displayed in the output buffer.

If I am missing something here, please explain more clearly and in detail about what you want to see and what you are currently seeing.


PostPosted: Sun Sep 14, 2008 7:42 pm
by noiv
The system runs Ubuntu 8.04. I assume newLisp is installed.

Execution in console:
Code: Select all
$ newlisp  /usr/share/newlisp/guiserver/button-demo.lsp
newLISP-GS v.1.22 on Linux
 double buffering supported.
 listening on 47011
 accepted connection from
 connecting to
 retrying to connect
server connected
-> frame MAIN:ButtonDemo 100 100 400 300 Q2xpY2sgb24gYnV0dG9uIG9yIGNvbG9yIHBhbmVs nil
-> set-resizable MAIN:ButtonDemo nil
-> panel MAIN:ColorPanel 360 200
-> set-color MAIN:ColorPanel 0 1 0 0.2
-> button MAIN:aButton MAIN:button-action Y29sb3I=
-> set-flow-layout MAIN:ButtonDemo center 2 15
-> add-to MAIN:ButtonDemo MAIN:ColorPanel MAIN:aButton
-> set-visible MAIN:ButtonDemo true
-> mouse-event MAIN:ColorPanel MAIN:mouse-action

Execution with launcher:
Code: Select all
>>> newlisp button-demo.lsp

Run button turned to Abort button
In both cases a window appears with the button demo.
Clicking Abort does not closes demo window, button turns to Run status, launcher output emptyed, no change on manual closure of demo window. Clicking again opens another window.

Manual closure of window opened by console command adds one line to output:
Code: Select all
server shut down

After clicking three times the Run button the system-monitor looks like this:


I hope the description helps. Useful would be same information like executed in console and Abort should kill everything started as child.

PostPosted: Mon Sep 15, 2008 1:38 am
by cody

There was a bug in the process killing code. I made and checked in a fix, if you could update your svn and retry to see if its fixed that would be great.


PostPosted: Tue Sep 16, 2008 6:05 pm
by noiv
I've updated to head, installed, deselected plugin, restarted and re-selected the launcher.
No change in behavior.

Should I check something else?

PostPosted: Tue Sep 16, 2008 11:13 pm
by cody

Let me check into a few more things and I will get back to you.


PostPosted: Wed Sep 17, 2008 12:04 am
by cody
Well I made one more small change to do a more aggressive kill. Update and try with this change, I would hope that this would at least kill the process at the top of the tree. I have a few more ideas about what is going on but will need to free up some more time for debugging before I can confirm.



P.S) You don't need to disable/reload the plugin to test this. Just starting up Editra is sufficient.

PostPosted: Wed Sep 17, 2008 5:40 pm
by noiv
I failed to reproduce a change in the behavior.

Any more ideas?

PostPosted: Wed Sep 17, 2008 7:08 pm
by cody

I got some testing in yesterday evening and can see the issue. I am having some trouble correcting it though.

On my machine the current code will kill off the process spawned by the Run but not any of that processes children, but from your screen shot I can still see that the shell for the subprocess was still running on yours. From your remarks I can guess that this is still the case?

Looks like I will need to do some research and I will add some debugging output so errors can hopefully be caught in the log output.


PostPosted: Fri Sep 19, 2008 3:16 am
by cody

Added a much more aggressive killing scheme. If it doesn't work this time I am not sure what to try next.

So if you could svn update and try it out again that would be great. The code is outside of the plugin so just doing an update and starting editra is enough to test it out.



PostPosted: Sat Sep 20, 2008 11:54 am
by noiv
I've asked for some more input here in the newLisp forum.

PostPosted: Mon Sep 22, 2008 2:19 pm
by cody

Thanks, looks like has gotten some replies. I will look into them.

For reference here is what Editra does for launching scripts.

1) Starts a new Thread for reading from the proces in
2) Starts the process through a new shell in a subprocess
3) Calls setsid on the new process to set it as the group leader

For killing here is what is tried currently.

1) Call os.killpg (Kill Process Group) I pass it the pid of the group leader and send it a SIGKILL.
2) If the above fails then I try an os.kill, with the -pid of the group leader sending it a SIGKILL
3) Call waitpid on the process in question

I have tried variations of many things including using SIGTERM instead of SIGKILL but all seem to behave the same.