Documentation for upcoming v.10.3.3

Notices and updates
Locked
Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Documentation for upcoming v.10.3.3

Post by 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/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.

HPW
Posts: 1390
Joined: Thu Sep 26, 2002 9:15 am
Location: Germany
Contact:

Re: Documentation for upcoming v.10.3.3

Post by HPW »

Interesting new command in the doc:

Code: Select all

(import LIBRARY "newlispCallback")
Will make registering callbacks even more easier!

Great addition.
Hans-Peter

cormullion
Posts: 2038
Joined: Tue Nov 29, 2005 8:28 pm
Location: latiitude 50N longitude 3W
Contact:

Re: Documentation for upcoming v.10.3.3

Post by 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
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Re: Documentation for upcoming v.10.3.3

Post by 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
Posts: 2038
Joined: Tue Nov 29, 2005 8:28 pm
Location: latiitude 50N longitude 3W
Contact:

Re: Documentation for upcoming v.10.3.3

Post by 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
Posts: 1390
Joined: Thu Sep 26, 2002 9:15 am
Location: Germany
Contact:

Re: Documentation for upcoming v.10.3.3

Post by 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 ?
Hans-Peter

Lutz
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Re: Documentation for upcoming v.10.3.3

Post by Lutz »

That is a typo, should be:

Code: Select all

(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.

Locked