sfos/eql5
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update Slime docu

Browse source
This commit is contained in:
polos 2017-02-28 22:43:02 +01:00
parent a45fb83120
commit 7c0cd4f1fb
1 changed files with 2 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
doc/Slime.htm
View file

@ -41,13 +41,14 @@
<br>
<h3>Loading files</h3>
<p>You should <b>always</b> use <code>qload</code> instead of <code>load</code>, if the file contains any EQL code.</p>
<p>It's not strictly necessary in every case, but not doing so may result in slow loading (many thread switches, one for every EQL function call), or may not even work (e.g. if the loaded code uses Qt threads internally).</p>
<p>It's not strictly necessary in every case, but not doing so may result in slow loading (many thread switches, for each EQL function call), or may not even work (e.g. if the loaded code uses Qt threads internally).</p>
<br>
<h3>Help</h3>
<p>For help see the <code>qapropos</code>, <code>qfind-bound</code>, <code>qproperties</code> and <code>qgui</code> functions.</p>
<p>To kill the swank process (Slime), use function <code>qquit</code> / <code>qq</code> (since quitting Emacs will not kill it).</p>
<br>
<h3>Notes</h3>
<p>If you notice slow execution of a function called from the REPL, try to wrap it in <code>qrun</code>/<code>qrun*</code>, as this will reduce eventual, multiple thread switches (for each EQL function call) to a single one.</p>
<p>All EQL functions are wrapped in <code>qrun*</code> (see <code>eql5/slime/thread-safe.lisp</code>), so it's safe to call them either directly from the REPL or using 'eval region' (or from any other ECL thread).</p>
<p>If the Slime REPL hangs, you can simply try to connect again (losing the old connection): no need to restart Lisp.</p>
<p>This Slime mode is both convenient and simple to use, but conses a little more for every EQL function call.