development version newLISP v.8.5.9

[Lutz]

• 'nil' and 'true' are allowed in memory shares
• new flavor osx_lib for newlisp.so on Mac OSX
• new flavor tru64 for Compaq/HP Alpha 64bit CPU
• 'timer' now has millisecond resolution
• 'read-buffer' can take a wait string similar to 'net-receive'
• Mac OSX installer package for 10.3
• flushing buffers for non terminal STD I/O lets newLISP be UNIX inetd server

For files and change notes see http://newlisp.org/downloads/development

Lutz

ps: this is the last release before v.8.6 in mid June

[HPW]

timer in newLISP for windows:

There is a 'SetTimer' function in Windows, but I have not come around yet to try it out for newLISP.

Any plans to get this in 8.6?

;-)

[Lutz]

The code is already done, see win32-util.c. Volunteers please step forward and make it work ;-)

Lutz

ps: needs the right link flags

[pjot]

After adding the macro -DWIN32_TIMER to the makefile, commenting the WINCC macro in primes.h, and adding this line

Code: Select all

#define TRACE_SIGALRM 0x8000

...to 'newlisp.h' the make mingw target compiles and links with no problems - no extra linkflag required, it seems?

However, it is the p_timerEvent in 'newlisp.c' which does not do anything, right...? The story at MSDN about timers is very big and requires some fundamental decisions... :-(

Peter

[Lutz]

Instead of TRACE_SIGALRM, it should now be TRACE_TIMER. I wrote the Win timer stuff before making the change from using alarm() to setitimer() for the UNIX timer function.

It compiles and links but the callback function timerFunc() is never called, the reason is that the application has to be linked as a Windows application with one or more of the Win libraries like ws2_32 and perhaps a .def file is needed exporting timerFunc(). May be it also needs a WinMain(), the main callback function in a Windows application receiving events.

Lutz

[pjot]

In the MSDN docs the following remark is shown:

When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER.

This text was really a riddle to me. But the demo program below shows a working SetTimer function:

Code: Select all

#include <windows.h>

void timer_proc(HWND a,unsigned int b, unsigned int c, unsigned long d) {

		MessageBox(0, "Hello", "MessageBox", 0);
}

int main(int argc, char *argv[])
{
int iTimerID = SetTimer(0, 0, 300, (TIMERPROC)timer_proc);

MSG m;

while (GetMessage(&m,0,0,0)) {
	TranslateMessage(&m);
	DispatchMessage(&m);
}

return 1;
}

Compile with 'gcc -o demo demo.c'. Pretty useless program but to get the idea. The timerevent is processed to the program itself, which must fetch it from the event queue.

So your "CELL * p_timerEvent(CELL * params)" must get the message of the event queue and dispatch it by itself. Probably you want to do this in a separate thread to let the newLisp programmer use the prompt.

Peter

[Lutz]

Thanks Peter, for digging this out, looks like I don't need WinMain() as long as I use GetMessage().

Lutz

[pjot]

Volunteers please step forward and make it work ;-)

I know you were only joking but I couldn't resist the challenge!

Hope it helps.

Peter

[Lutz]

Turns out that GetMessage() blocks when no message is received, which is none if you filter for WM_TIMER.

In the end I just created a thread using _beginthread() from the Win32 runtime library and watch the time in it, which turned out to be a very short solution with very little code added in the Windows compile.

But GetMessage() could be an interesting function for 'import', and then a Win GUI could be built fetching messages for the keyboard, mouse etc.. Not a single code change would be required in newLISP, in fact it could be done with any of the previous versions. But I leave that to the volunteers ;-)

Lutz

[pjot]

Sounds like a lot of work to me... Besides the GUI API of Win32 is a bit foggy. My focus is Unix anyway! ;-)

Peter

[Lutz]

Actually it came out pretty short (look for it in the next release). The Win32 _beginthread() doesn't need much stuff around it. The resulting 'timer' funtion works similar to the 'timer' in the Linux/UNIX versions.

But I agree, having the 'timer' and fork you can do so much more. Unfortunately I dont's see a UNIX style fork (which creates an exact copy of the parent process) any time soon. The only version I ever saw is the one in cygwin, but I didn't find it to be reliable enough. Its just something Windows isn't build for. The Win32 thread facility turned out nice for the timer, but else doesn't have much use in newLISP.

Lutz

[rickyboy]

Hey Lutz,

Sorry to see you dropped cygwin support. I was one of the (few?) cygwin users.

Say, has anyone approached you about supporting/porting to SGI IRIX 6.5 (mips, n32)? We have several here at work on which I'd love to run newlisp. I really don't know where to start; however, if (1) you don't have anyone else, (2) you can suggest how to start (i.e. which makefile I could start from), I could give it a shot in my spare time.

BTW, any IRIX users out there who have newlisp running on an IRIX box, or who are interested in a port to IRIX?

--Rick

[pjot]

Hi rickyboy,

I just finished a port of newLisp to Tru64Unix starting with the Makefile for Solaris.

The biggest trouble came from the fact that Tru64 Unix is a 64-bit operating system. NewLisp however expects pointers to be of 32-bit size. How about Irix?

I have a list of changes which I needed to put into the newLisp sources, would you be interested to see them, just to get an idea where you may run into?

Peter

[Lutz]

Good to hear from you rickyboy,

About CYGWIN, sorry that had to hit you rickybody ;( with the drop of CYGWIN. I don't maintain a full CYGWIN environment on my Wintel machine anymore, using the MinGW compiler exclusively when in Cygwin, the next flavor to drop will be Borland BCC, I only keep it because of the nice turbo debugger helping me out.

If you have any problems compiling the Cygwin flavor let me know and I try to help. There could be some problems, because since introduction of signals and timers I have not compiled that flavor.

About an Irix port, I love those machines, having used them more then a decade ago. I would just start with the Solaris or BSD make file and go from there. Most likely one of the two will get you there quickly. These are the areas where you might run into tweaking:

signals 'signal'

timers 'timer'

shared memory 'share'

time date stuff (several newLISP functions)

sleep 'sleep' (no big deal -DNANOSLEEP or not)

vasprintf(), vsnprintf(), my_vasprintf() 'C' functions: read man pages for vasprintf() and vsnprint(). If you don't have vasprintf() take my_vasprintf() in nl-filesys.c. In that case check return value of vsnprintf() on your platform, see my_vasprintf() source for details.

Most of that stuff is in nl-filesys.c. Probably one of the other flavors has already what you want. If you have GCC for 32bits on your machine things will go smoothest. If you can give me an account on one of your IRIX machines I can help you. I can sign NDAs or whatever you might need for your employer.

The tru64 port Peter/pjot did was probably one of the toughest, and even that post was done in a few days in Peter's spare time.

Lutz

[Lutz]

Oh, and I almost forgot the most important thing:

Compile and run types.c from the newLISP source distribution and compare with CYGWIN/MingW/Linux output and it will tell you quickly if problems are to be expected!

Lutz

[rickyboy]

Thanks Peter! Thanks Lutz!

I will try to find some time tomorrow to start on the port.

--Rick

[HPW]

the next flavor to drop will be Borland BCC, I only keep it because of the nice turbo debugger helping me out.

You forgot that the BCC-DLL is the only one which runs under .NET as unmanaged code! Should we loose this ability? Could you think of other options for .NET?

[Lutz]

Oh yes, I forgot, then it stays, BTW timer doesn't work in with BCC.

Lutz

[pjot]

Unfortunately I dont's see a UNIX style fork (which creates an exact copy of the parent process) any time soon. The only version I ever saw is the one in cygwin, but I didn't find it to be reliable enough. Its just something Windows isn't build for. The Win32 thread facility turned out nice for the timer, but else doesn't have much use in newLISP.

1) Indeed the Win32 platform just does not have something like 'fork', it's not part of the OS. Still I wonder: is it not possible to simulate a 'fork' using threads, similar to the 'timer' function?

2) The Cygwin implementation is also a simulation, but is it really that bad? At least there is the possibility to use the 'fork' command in Windows. Besides Cygwin, also Perl uses a 'fork' emulation in a Win32 environment:

http://www.xav.com/perl/lib/Pod/perlfork.html

Though it has certain limitations, it will make newLisp more complete.

Peter

[Lutz]

UNIX fork gives you a copy of all the whole parent process, which is what I need. For that reason simple threads won't work.

Lutz

[pjot]

So what do you think about an implementation similar to Perl?

[Lutz]

I believe Perl and newLISP are doing the same thing, using a UNIX fork().

Lutz

[pjot]

Yes, in Unix probably. But how about the Windows emulation for a 'fork'...? Could you use the Windows emulation of 'fork' for Perl also for newLisp? It will make newLisp more complete... :-)

[Lutz]

They seem to do a similar thing CYGWIN is doing, Perl has a 'perl-clone' function copying all memory from the parent process when simulating fork() on Win32.

Lutz

[pjot]

Well, so that is good news! :-)

...but serious, I am a little bit confused here... because a few messages back, you say:

UNIX fork gives you a copy of all the whole parent process, which is what I need.

And here you say:

Perl has a 'perl-clone' function copying all memory from the parent process when simulating fork() on Win32.

So isn't this exactly what you want for Windows then? Or do I misunderstand you somewhere?

Sorry to be so nagging, but it seems that a Cygwin-like 'fork' seems to work for many other Unix tools ported to Windows, including Perl. So why not use it for newLisp as well?

Peter