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/develo ... tml#toc-23
and a new chapter:
24 newLISP as a shared library
http://www.newlisp.org/downloads/develo ... tml#toc-24
In the Users Manual the chapters:
6. Extending newLISP with shared libraries:
http://www.newlisp.org/downloads/develo ... shared-lib
and
7. newLISP as a shared library:
http://www.newlisp.org/downloads/develo ... ewlisp-lib
Any help improving language, grammar and punctuation is much appreciated.
Documentation for upcoming v.10.3.3
Re: Documentation for upcoming v.10.3.3
Interesting new command in the doc:
Will make registering callbacks even more easier!
Great addition.
Code: Select all
(import LIBRARY "newlispCallback")
Great addition.
Hans-Peter
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Re: Documentation for upcoming v.10.3.3
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.
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.
Re: Documentation for upcoming v.10.3.3
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.
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.
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Re: Documentation for upcoming v.10.3.3
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.
But you're probably right, it's overkill for a project as small as newLISP.
Re: Documentation for upcoming v.10.3.3
A question to the doc of the new command newlispCallback:
The command is imported from there so it sould know itself.
Or what do I miss ?
Why is there the last param LIBRARY ?; register the callback with newLISP library
(newlispCallback "callme" (callback 0 'callme) LIBRARY)
The command is imported from there so it sould know itself.
Or what do I miss ?
Hans-Peter
Re: Documentation for upcoming v.10.3.3
That is a typo, should be:
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.
Code: Select all
(newlispCallback "callme" (callback 0 'callme) CALLTYPE)