newlispEvalStr - enable printing to console?

[TedWalther]

I looked at the source for newlispEvalStr and just like the documentation says, it disables all printing to console.  I didn't see an option to turn it back on.  Is this a possible future feature?  I'd like my eval'd code to interact with the console just like native newlisp code.  Does newlisp have a different idiom for doing this?

[Lutz]

The library version of newLISP processes the string passed by char * newlispEvalStr(char * command) like a REPL command string. This is useful for writing newLISP IDE's using the newLISP library. All output from return values and error messages and other output directed to the console goes into the string returned by newlispEvalStr().



But this does not include output to file handles, even if stdout. You could use write-line instead of println to direct output directly to stdout and not show up in the string returned by newlispEvalStr():

Code Select Expand


newLISP v.10.6.3 64-bit on OSX IPv4/6 UTF-8 libffi, options: newlisp -h

> (import "newlisp.dylib" "newlispEvalStr")
newlispEvalStr@108D230B0
> (get-string (newlispEvalStr {(write-line 1 "hello world")}))
hello world
"12n"
> (get-string (newlispEvalStr {(silent (write-line 1 "hello world"))}))
hello world
""
>

or when using extended import with libffi without using get-string:

Code Select Expand


newLISP v.10.6.3 64-bit on OSX IPv4/6 UTF-8 libffi, options: newlisp -h

> (import "newlisp.dylib" "newlispEvalStr" "char*" "char*")
newlispEvalStr@1085E00B0
> (newlispEvalStr {(write-line 1 "hello world")})
hello world
"12n"
>


So you could bracket expressions to evaluate with (write-line 1 expr) and output goes directly to the current console via stdout and not into the returned string.

[TedWalther]

I'd like to be able to run an app natively, debug it, then later on pass it to newlispEvalStr without having to modify it in any way.  println, device, etc, are convenience functions.  I hate to give up convenience.



Could we have that as a flag to newlispEvalStr?



Keep the call pattern of newlispEvalStr, but have it call the new function, say,

Code Select Expand


enum nlEvalStr_flags_t { noconsole, console };
char* newlispEval(char* str, int flags);


Then newlispEvalStr becomes a wrapper like this:

Code Select Expand


char* newlispEvalStr(char* str) { return newlispEval(str, noconsole); }


Also I notice the shared library isn't shipped with Mac OS by default.  Are there some bugs with it?  I modified the makefile to also include ffi support in the shared library.  Any known issues with that combination?

[Lutz]

A new library call (newlispLibConsole 1) enables stdio when using newlispEvalStr. Before stdout was inserted into the return string.



http://www.newlisp.org/downloads/development/inprogress/">http://www.newlisp.org/downloads/develo ... nprogress/">http://www.newlisp.org/downloads/development/inprogress/



If it not were for MS Windows, newLISP as a library would have been dropped a long time ago. Better launch newLISP as a process with pipes or a server with stdio or network communications and take advantage of multi core CPUs or distributed applications at the same time. newLISP as a library shares the process stack with the caller and runs in the same thread, which limits it for certain tasks. Very few people use it on OSX, Linux or other Unix.



On Windows, shared library usage is more prominent importing the newLISP DLL from Excel, VisualBasic or .NET applications.



There are no issues known combining the lib-flavor with any other compile options.

[TedWalther]

Thank you Lutz!  My current application that uses the newlisp shared library functionality, is potentially crossplatform to all of newlisps supported platforms.



Also, nanomsg seems to be stable; any chance of revisiting the threads/actor/agent stuff for being supported on Windows?



Are the limitations of library mode, documented in the Manual?  I'm interested to know more about them; hopefully they are straightforward limitations, not subtle ones that take a lot of brainpower to understand.

[Lutz]

For 1 1/2 years the Windows version of newLISP was distributed as a Cygwin compiled version including a Unix fork() implementation by RedHat and newLISP was using this. It turned out to be slow and unreliable. The Cilk API with 'spawn' and 'sync' is built on top of Unix fork(). The actor type of messaging with 'send' and 'receive' is using Unix socket-pairs. I don't like threads for newLISP, but that is another story, don't have the time to get in to that right now.



The problem seen with the lib-mode are stack overruns. You might see these perhaps when tasks get longer and more complex.

[TedWalther]

That makes sense.



About the Cilk API, Wikipedia says this:

Cilk Plus was first implemented in the Intel C++ Compiler with the release of the Intel compiler in Intel Composer XE 2010.[citation needed] An open source (BSD-licensed) implementation was contributed by Intel to the GNU Compiler Collection (GCC), which shipped Cilk Plus support in version 4.9,[7] except for the _Cilk_for keyword, which was added in GCC 5.0. In February 2013, Intel announced a Clang fork with Cilk Plus support.

So, the Cygwin gcc version was giving you the Cilk API, but it was using underlying fork calls from the Cygwin DLL instead of native Windows calls.  I wonder if MingW would be much better, since it tries to do native Windows calls?

[Lutz]

The Cilk API was developed inspired by the original MIT Cilk Reference Manual documentation and was not dependent on any gcc Intel Cilk code, which wasn't introduced until 2009, a year later. The 2008 newLISP implementation needed Unix fork(), which is not available natively in Windows, only in Cygwin.