This page provides tips for using Newton Toolkit as well as information about undocumented bugs and other details.
NTK officially requires a Macintosh with at least a 25 MHz 68030 processor and 8 MB of RAM. I do not know whether it will run with anything less. It also runs fine with Classic on OS X, but see the Newton FAQ for details.
NTK requires Windows 95 or newer. It can also run on Windows 3.x if Win32s is installed.
NTK seems to not run on 64-bit Windows versions (it closes right after starting up), but runs fine on 32-bit Windows XP and Windows Vista. The only problem is that downloading packages causes errors for packages larger than about 5 kilobytes. This can be worked around by using another package downloader, such as Newton Press, but it makes debugging harder because then you have to frequently connect and disconnect the Inspector. It is good enough for development of NSM-compatible packages though.
For serious Newton OS development, I recommend using Windows 98 in a virtual machine, or a Macintosh emulator.
ReactOS, as of version 0.3.17, seems to run NTK just fine.
Probably the easiest way is to download the NewtonDev archive. Warning: the GlobalData file in that distribution is quite bloated; see below.
You can get NTK from UNNA (version 1.6.1 is the last for Windows). There is also example code for it.
NTK is not just a NewtonScript compiler. It is an interpreter as well. However, this functionality is not exposed by default.
See the NTK manual on page 5-29 for information on the GlobalData file. Personally, I use {key: 36, control: true} (Ctrl-Enter); {key: $e, command: true} (Command-E) is also a good choice.
Create a file called GlblData.f in the folder where you installed NTK and paste the following code into it:
protoEditor:DefineKey({key: 0x6B /* numpad + */}, 'EvaluateSelection);
Restart NTK and you will now be able to execute NewtonScript code by selecting it and pressing the + key on the numeric keypad. The output will appear in the Inspector window.
(Source: Bob Ebert in comp.sys.newton.programmer)
This works because NTK compiles and executes the contents of that file each time it starts. You can also, for example, set printDepth to 0 to get nice compact listings of arrays and frames:
printDepth := 0;
Or, if, like me, you want to use NTK for text processing in NewtonScript until NSM is more mature, you can also define functions inside it:
vars.LoadTextFile := func(Filename)
begin
// Takes a filename of an ASCII text file and returns a string with its contents.
// Windows-only because Macintosh NTK doesn't have LoadDataFile.
local ASCII := LoadDataFile(Filename, nil);
local Len := Length(ASCII);
local String := MakeBinary(Len * 2 + 2 /* NUL terminator */, 'string);
for i := 0 to Len - 1 do
String[i] := ExtractChar(ASCII, i);
return String;
end;
You can also execute NewtonScript code directly from a file with the global function Load.
Native functions are actually first translated to C and then compiled to machine code. Walter Smith explains this in comp.sys.newton.programmer.
NTK's implementation of the bit-not instruction has a bug: it says "Wrong number of arguments" whenever you try to use it. This is impossible, as calls to primitive functions (through the freq-func instruction) do not even tell the function how many are being passed to it. My guess is that NTK's implementation of bit-not calls the global function BNot (which is implemented correctly) and gives it an incorrect number of parameters while doing so.
Regardless of the cause, this bug is very hard to encounter; it turns out that NTK never generates the instruction at all, but rather generates a call to BNot.
NTK's implementation of the get-path instruction has a bug: when accessing an array, it checks whether the index is too high (and returns nil if it is, which is correct), but not whether it is too low.
Executing [1, 2, 3].(-1) will return 'Array, which is the class of the array and immediately precedes its elements. It is also possible to crash NTK with this.
The NewtonScript virtual machine in the Newton OS behaves correctly in this case and returns nil.
It is possible to crash NTK by calling the global function RemoveSlot if the first parameter is a frame and the second parameter is not a symbol. This bug seems to be only in the Windows version (1.6.1). In the Macintosh version, it does nothing. In Newton OS, it throws an exception.