Newt Change History

NewtDevEnv 3.5 (?? 98)

3.5j,-2 (30 May 99)

fixed a problem (introduced in h?) where :DefConst failed to substitute symbol values; there are still problems with initializing constant 'objects'
to avoid some problems with Newt's overriding (during development) of system Notify method (its return value is undefined/undocumented, but some system functions expect it to return a frame), there is now a Prefs:Notify picker:

Newt only
(default) as before, Newt prints error message, but no error box; return value unspecified
Newt & System
prints to Newt, and also shows Notify box/returns frame
System only
shows Notify box/returns frame (w/o printing to Newt EvalLog)

3.5i,-2 (26 Sep 98)

init discards constants before running
MetaDot works in Eval Controls input field and in Eval Log
MetaDot 3.5a,-2 includes parameters for Newt development-time methods: addApp, addPage, addSlot, addStep, addView, buildFolderLib, copyFolderNewtWorks(2.x), DeclareUnit(2.x), DefConst, deferredPackageObject, DefineUnit(2.x), doObj, GetNamedResource, GetPictAsBits, GetSound, helpBookTemplate, installApp, LocObj, printVal, readEvalPrint, removeApp, removePackage, removeSlot, removeStep, removeView, saveApp, setLanguage, setLocalizationFrame, UnitReference(2.x), UR(2.x), version
2.1: :copyFolderNewtWorks adds two additional parameters: erase, multiple (same as 3.5g with erase=nil, multiple=nil)

erase
true: erases entire folder before storing
"string": erases only entries in folder whose first line matches this. e.g., "myapp"
nil: no entries erased
multiple
true: each Note is stored as a separate NewtWorks entry (this could be useful if "NewtWorks doc menu?" preference is on); 2nd title parameter is ignored
nil: entries appened in a single document (2nd parameter is title)

3.5h,-2 (27 Aug 98)

2.1: new preference: NewtWorks doc menu? if off (default), entire folder is used as library (as in 3.5g-2); if on, after selecting a folder, you can choose an individual document to be the library for Copy Source/All
:DefConst earlier allowed use of any constant in a frame definition, and "immediate" constants like integers, symbols and strings in the bodies of methods. You can now use "object" constants like frames, functions, arrays and binary objects inside methods. As before Newt substitutes immediate constants in the method source, but it also now substitutes object constants after the method (or function) has been compiled. See objconst.nwt example. Ongoing limitation: a constant symbol must not match another symbol, e.g., 'kFoo and 'kFoo2 would conflict; 'kFoo1 and 'kFoo2 would be ok. A new limitation: a function constant, i.e, :DefConst('myfunc, func(... , can't use other constants, though methods (and embedded functions inside methods) can use any constants.

3.5g-2 (4 Jun 98)

2.1: initial support for copying Newt items from/to Newtworks

from Newtworks
Use Select Library to choose a Newtworks folder. then Copy Source (and pick from the menu of items) to copy one item, or Copy All for all Newt items. note: after you select a folder, there will be a delay while Newt extracts the text from each Newtworks document in the folder to check which are valid Newt items (a Newtworks document can contain a single Newt item, or multiple Newt items delimited by -----. (if the multiple Newt items per document is the preferred usage, I might introduce another level of hierarchy, i.e., select a folder, select a document, then item(s); currently, you'd need to create doc from scratch or transfer from desktop with another tool since Sloup would break doc up into multiple items -- should Sloup have an option to xfer as a single doc, treating ----- as content rather than delimiter?)
to Newtworks
:copyFolderNewtworks -- analogous to :buildFolderLib. export current Notes folder as a single Newtworks doc, with ----- lines in between items. e.g., :copyFolderNewtworks('Business, "my project"), where 1st parameter is symbol for folder (nil for Unfiled), 2nd parameter is title of document. [see 3.5i-2 for 3rd and 4th paramters]

3.5f,-2 (2 May 98)

help books (created via :helpBookTemplate) should now allow selection (for copying) on content pages
2.x: minor :unitReference fix for some packages (with non-standard export tables, e.g., NIE)

3.5e-2 (22 Apr 98)

2.x: fixes a bug if Handwriting(Casual) was the newtFont in pre-d version (<d); note: if you installed d and selected Casual, you'll have to re-select Prefs:newtFont in e. alternatively, you can workaround bug and continue to use d by removing the Newt preference frame (entry tag: NewtDevEnv:TKnollSys in System soup)

3.5d,-2 (21 Apr 98)

newtFont preference now lists other installed fonts (Casual, Monaco, etc.) in 9,10,12 sizes; fixed 1.x problem where text lost. note: if you go back to an earlier version of Newt, be sure to either change the font back to a standard font (espy,new york, geneva) or remove preference frame.
MetaDot does not activate if there is a highlighted selection

NewtPack 3.5c-2 (21 Apr 98)

2.x: unit reference fixes. subtle bug related to saving VBOs (thanks Richard Li)

3.5c,-2 (21 Mar 98)

Remove Packages now groups packages by store; 1.x: omits built-in 2.x apps
tentatively removing Personal Media support -- let me know if you use this and would like it to remain
this version should be compatible with latest Sloup 2.2a-2 (as well as older versions) for Inspect?

3.5b-2 (24 Feb 98)

fixes problem in protoAboutText if title slot not defined as string in app
2.x: when saving, existing (but frozen) package now appears in removal prompt (older version did not notice/prompt, resulting in install error after save)
native code/C++/unit background:
- in earlier versions, it was possible to access native (compiled to RISC) NewtonScript code via a constant library autopart created in NTK (e.g., LifeCnst.pkg/life.nwt example).
- C++ generated code can be accessed in the same way also (though this was not documented/tested earlier). I will continue to investigate whether it is possible to transfer native and C++ code modules via Sloup (and avoid NTK step), though since these are frame structures rather than simple binary objects, this may not be feasible; in the meanwhile, I can provide a skeletal NTK project so you can create a constant library, or as time permits, create the actual library for you from native code or stream modules.
- "Unit references" (exported 2.x objects from other packages) too can be accessed this way in Newt (3.4) by importing these references into an NTK constant library -- but when NewtPack (3.4) saved these, it copied entire objects (not just refs) into your package. In Newt 3.5b-2, you can access unit references directly from exporting packages (without having to use an intermediatary NTK-created constant package); and NewtPack 3.5b-2 allows these to be saved as references (rather than by copying), which results in smaller packages that are easier to update. For example, in moounit.nwt, MooUnit creates an autopart that exports several objects (a graphic and sound); the MooUser app imports these objects, but when that package is saved, it saves only references to the objects (just as if they were in ROM); handles situation of MooUnit not present when MooUser starts, or if MooUnit removed/frozen while MooUser running.
2.x: Newt now supports two _package slots for NewtPack:

_ImportTable
array -- normally value of UnitsImport (which is created by :DeclareUnit). set this for an application that uses (imports) objects from other (exporting) packages, e.g., MooUser. NewtPack uses this information to save appropriate object references; if _ImportTable is missing or nil, NewtPack copies the entire object into the new package (just like older NewtPack) rather than create a reference (to the original object). (Note: if _ImportTable is [], NewtPack generates an import table as it discovers imported objects -- this might be useful if you access constant objects via a a regular Newt library, e.g., created in NTK from a developer's stream file; you know the names of the objects from documentation, but not the unit information (like unit name or object mapping)).
_ExportTable
array -- normally value of :DefineUnit. set this for an autopart (or application) that exports objects for use by other (importing) packages, e.g., MooUnit. If this is in an autopart, you do not need to include partData since NewtPack saves the object references within the export table.

2.x: Newt provides the following new development-time methods (see moounit.txt for further documentation):

:DeclareUnit(unitName, majorVersion, minorVersion, memberIndexes, pkgStr)
this declares unit information for both import and export. same as NTK except unitName=nil to reset (erase) all import info; pkgStr (name of the package containing the exported units) must be provided for UnitReference to work. this adds an entry to the "UnitsImport" array; you can import multiple units into a single package.
:UnitReference(unitName, memberName) //or :UR(...)
returns (imported) object reference (assumes DeclareUnit ran after exported package is installed). in Newt, these would typically occur to initialize slot values at build-time (not used inside run-time methods)
:DefineUnit(unitName, members)
sets up export array. value typically assigned to _ExportTable. If your package has multiple parts, each can have its own export.

NewtPack 3.5b-2 (24 Feb 98)

2.x: if _package.compressed = 'faster, faster (though less space-efficient) compression is used
2.x: saves "unit references" (see Newt) rather than copying objects: exports units if _package._ExportTable is an array; imports units if _package._ImportTable is an array

3.5a,-2 (9 Feb 98)

1.x: popup menu for slot editor now uses full screen width when on 2.x
:buildFolderLib now works with '|symbol| (containing non-alphanumerics)