Documentation for upcoming v.10.3.3

[Lutz]

The following chapters in the documentation have been added or rewritten:



In Code Patterns the last subchapter "Registering callbacks in external libraries" of chapter:



23: Extending newLISP

http://www.newlisp.org/downloads/development/inprogress/CodePatterns.html#toc-23">http://www.newlisp.org/downloads/develo ... tml#toc-23">http://www.newlisp.org/downloads/development/inprogress/CodePatterns.html#toc-23



and a new chapter:



24 newLISP as a shared library

http://www.newlisp.org/downloads/development/inprogress/CodePatterns.html#toc-24">http://www.newlisp.org/downloads/develo ... tml#toc-24">http://www.newlisp.org/downloads/development/inprogress/CodePatterns.html#toc-24





In the Users Manual the chapters:



6. Extending newLISP with shared libraries:

http://www.newlisp.org/downloads/development/inprogress/newlisp_manual.html#shared-lib">http://www.newlisp.org/downloads/develo ... shared-lib">http://www.newlisp.org/downloads/development/inprogress/newlisp_manual.html#shared-lib



and



7. newLISP as a shared library:

http://www.newlisp.org/downloads/development/inprogress/newlisp_manual.html#newlisp-lib">http://www.newlisp.org/downloads/develo ... ewlisp-lib">http://www.newlisp.org/downloads/development/inprogress/newlisp_manual.html#newlisp-lib



Any help improving language, grammar and punctuation is much appreciated.

[HPW]

Interesting new command in the doc:

Code Select Expand

(import LIBRARY "newlispCallback")

Will make registering callbacks even more easier!



Great addition.

[cormullion]

Hey, Lutz, you're still working on newLISP - cool.



Why don't you put the documentation on Github or somewhere? Then we could all work on it together and you could incorporate the changes into the final build. Haven't tried it, but its probably about time newLISP went githubbing.

[Lutz]

Cooperation on source and documentation has worked fine in the past. No need for an additional layer in-between. A small project project of the size of newLISP would only be burdened by additional overhead. Github just doesn't fit the newLISP project and philosophy.



A few months ago I thought about using Fossil (from the SQLite folks, web based source control with integrated bug tracking and wiki) as an alternative more suitable to newLISP's philosophy. But then again, I thought: "What step in the work flow would get easier?" and: "What problems does it solve?" - and decided not to do it.

[cormullion]

If you're not already using git or similar (there are a few newLISP users on github already) there is indeed a small overhead involved in setting up (ssh keys I seem to remember). After that's done, though, it seems better than some of the  alternative ways of working, and there are presumably some obvious benefits as regards managing multiple edits from multiple individuals, easier handling of many smaller updates, audit trails, backups, and so on. Less work for you too, of course, if you don't have to repeat all the editing work that others have done on your master copy.



But you're probably right, it's overkill for a project as small as newLISP.

[HPW]

A question to the doc of the new command newlispCallback:

; register the callback with newLISP library

(newlispCallback "callme" (callback 0 'callme) LIBRARY)

Why is there the last param LIBRARY ?

The command is imported from there so it sould know itself.

Or what do I miss ?

[Lutz]

That is a typo, should be:

Code Select Expand

(newlispCallback "callme" (callback 0 'callme) CALLTYPE)

CALLTYPE was earlier defined as either "stdcall" or "cdecl"; or you can leave the parameter out, and it will assume the call type of the platform.