newspeaklanguage / newspeak

Newspeak is a live object-capability language in the Smalltalk tradition

1. Newspeak

Newspeak is a new programming language in the tradition of Self and Smalltalk.

The Newspeak IDE is delivered via the web at https://www.newspeaklanguage.org/webIDE/ as a Progressive Web App (PWA). This means that you can install it locally on your device, and then run it without needing an internet connection. Updates are delivered automatically whenever you are online - this is enabled by the PWA.

If you are testing or developing in Newspeak, the online version is all you need. You could stop here and consult the Newspeak resources linked above.

But you may decide to build and serve Newspeak or your own Newspeak application locally. The sections explain how to do so.

Note: below, the terms 'serve', 'server' refer to 'serve in a HTTP server', 'HTTP server' or similar.

2. How to build, deploy, and serve Newspeak applications

This is only a terse introduction to creating and serving Newspeak applications.

A Newspeak application is a Newspeak object which adheres to a few specific API naming conventions. Its class can be saved to a .ns source file, and used to create an instance that is serialized into a binary .vfuel, which is deployed and served.

Note:: You can usually run the application inside the IDE for purposes of testing and development, provided you have the source code loaded in the IDE. We won't discuss that here - this document is focused on application deployment.

A .vfuel file can be created from its source class in one of two ways:

1. From the locally served or online Newspeak IDE by clicking the [deploy] link beside the application class. This process is not described in this document.

2. From a command line, by first saving the application class to a .ns source file, then running the build.sh script described below. To use this command line method, you need to install several items. This process is described in the Building Newspeak from scratch section and its subsections.

To serve a Newspeak application in a HTTP server, you need a binary file with .vfuel extension, one or more HTML files, and at least two files, 'primordialsoup.js' and 'primordialsoup.wasm' (both created by build.sh), and potentially other application specific resources.

3. Building Newspeak from scratch

TL;DR: If you want to build the Newspeak IDE or any Newspeak application from scratch, follow the installation steps in section 3.1 and subsection 3.1.1 (each only needs to be performed once). Then follow the steps in section 4.1 (for the Newspeak IDE running as a PWA) or 4.2 (for any application, running as a website). The steps in section 4.1 or 4.2 are repeated after after any change in the application.

In addition to using the online version of the Newspeak IDE, you can build, deploy, and serve the Newspeak system, or any Newspeak application, on your computer. There may be a few reasons to build and use the Newspeak system this way:

• You just want to learn how to do it.
• You want to write, build, and serve your own Newspeak application (a .vfuel file), or serve the Newspeak IDE from your own HTTP server for local or public consumption.

Read and follow the steps below to build Newspeak locally (on your computer) from scratch.

3.1 Building Newspeak: installing required software

This is needed one-time only.

Building Newspeak locally requires some software to be downloaded, cloned from Github, or installed: Newspeak, Primordialsoup and it's dependencies and targets: Emscripten, Scons, and g++-multilib. Details of how to install the required software are below.

The default directories for installing Newspeak, Primordialsoup and Emscripten are determined by environment variables set in newspeak/tool/newspeak_env.sh. These variables and their default values are

export EMSDK=~/software/emsdk                           # Emscripten directory
export NEWSPEAK=~/software/nswasm/newspeak              # Newspeak directory
export PRIMORDIALSOUP=~/software/nswasm/primordialsoup  # Primordialsoup directory

We use these defaults throughout the rest of this document. If you wish to use different directories, you will need to do two things:

• Adjust references to the above directory names in this document
• After cloning Newspeak in the steps below, edit the file newspeak/tool/newspeak_env.sh and adjust the directory names to your situation.

The installation steps:

1. Start with creating a directory for Newspeak and Primordialsoup, ~/software/nswasm and then clone this repo under it.
2. In ~/software/nswasm, also clone https://github.com/newspeaklanguage/primordialsoup and switch to the branch called extraRevs.

You can use the following commands to execute 1. and 2. just above:

mkdir --parent ~/software/nswasm
cd ~/software/nswasm # Adjust to your directory path
git clone https://github.com/newspeaklanguage/newspeak.git
git clone https://github.com/newspeaklanguage/primordialsoup.git
cd primordialsoup
git checkout extraRevs

To be clear: at this point, you should now have a directory named ~/software/nswasm, with two subdirectories; newspeak, containing this repository, and primordialsoup, containing the extraRevs branch of https://github.com/newspeaklanguage/primordialsoup.

Important: If you are using 'non default' directories for your installation, now edit the file newspeak/tool/newspeak_env.sh, change the exported variables there, and save the file.

3.1.1 Building Newspeak: installing Primordialsoup dependencies

Next, you will need to install software needed by the Primordialsoup build.

Unless you are targetting Fuchsia, follow steps 1 to 3 in this section to install and build Primordialsoup and its dependencies.

1. Install and configure Emscripten and Primordialsoup dependencies: building Primordial Soup requires a C++ compiler and SCons.

   • On Debian/Ubuntu:

     sudo apt-get install g++-multilib scons

   • On Opensuse:

     sudo zypper install scons
     sudo zypper install -t pattern devel_basis   devel_C_C++   32bit 

   • On macOS, install XCode and SCons.

   • On Windows, install Visual Studio and SCons.

2. Install and configure the Emscripten SDK (emsdk): Emscripten is a compiler that compiles C and C++ sources to WebAssembly, which can then be executed by browsers.

   Clone the Emscripten SDK (emsdk) using these steps

   # Set the Newspeak environment.
   cd ~/software/nswasm/newspeak # Adjust to your directory path
   . ./tool/newspeak_env.sh      # The '. ' at the beginning is required
   
   # Clone the emsdk
   cd $EMSDK/..
   git clone https://github.com/emscripten-core/emsdk.git
   
   # Install the emsdk version 2.0.0
   cd emsdk
   ./emsdk install 2.0.0
   ./emsdk activate 2.0.0
   . ./emsdk_env.sh
   
   # List the emsdk installed
   ./emsdk list

   Note: '2.0.0' is the default supported version of emsdk. To use the latest Emscripten SDK, you can replace '2.0.0' with 'latest' in the script above. BUT, if you do that, you also have to edit the scons build file named SConstruct in the $PRIMORDIALSOUP directory, and replace the following line

      '-s', 'EXPORTED_FUNCTIONS=["_load_snapshot", "_handle_message", "_handle_signal"]',

   with

      '-s', 'EXPORTED_FUNCTIONS=["_load_snapshot", "_handle_message", "_handle_signal", "_free", "_malloc"]',
      '-s', 'EXPORTED_RUNTIME_METHODS=["stringToUTF8"]',

   to be clear, the first (default) works with emsdk version '2.0.0', the second with 'latest'. As of February 12 2024, 'latest' emsdk corresponds to version '3.1.53'.

3. Build Primordialsoup (optional): You can now build primordialsoup to make sure everything installed. This step is not necessary as Primordialsoup build is part of the Newspeak build in the next section - but running it should catch any dependencies issues early.

   cd ~/software/nswasm/primordialsoup # Adjust to your directory path
   . ../newspeak/tool/newspeak_env.sh  # Set EMSDK var for next line
   . $EMSDK/emsdk_env.sh               # Setup emsdk's environment
   ./build os=emscripten arch=wasm     # Build wasm using emscripten

   There should be no errors in the last step, and you should see directories in the out directory under primordialsoup, notably there should be files primordialsoup/out/ReleaseEmscriptenWASM/{primordialsoup.html,primordialsoup.js,primordialsoup.wasm} and primordialsoup/out/snapshots/WebCompiler.vfuel which are used in the Newspeak build. If there are errors, you may be missing some primordialsoup dependencies described in the section above.

Note: For original instructions of Primordialsoup dependencies that include Fuchsia as a target, follow the instructions at https://github.com/newspeaklanguage/primordialsoup/blob/master/docs/building.md.

3.2 Building and deploying Newspeak applications: lifecycle

The above section Building Newspeak: installing required software including its subsection Building Newspeak: installing Primordialsoup dependencies only needs to be performed once during installation.

This section and sections below describe the repeated 'build', 'deploy', 'serve' lifecycle of Newspeak applications.

Important: All scripts to build and deploy a Newspeak application are in the newspeak/tool directory, and must be executed from the newspeak/tool directory. The Newspeak IDE is only one possible Newspeak application.

The term build refers to the process which creates the .vfuel binary files from the application source .ns files. The script newspeak/tool/build.sh is the build script. You need to run a 'build' to regenerate the application's .vfuel file.

Before creating a .vfuel, you should ensure that you have saved any modified source code it depends upon, be it one of the Newspeak core classes, or a class that is a part of your application.

The term deploy refers to the process of copying the Newspeak application .vfuel file and other files and resources (.html, .js, .png) to the 'deploy directory' where an HTTP server is or will be running. The 'deploy' step also copies scripts that can start an HTTP server to the 'deploy directory'. Newspeak applications can be deployed in two ways: as a regular website or as a Progressive Web App (PWA).

• Deploying as a website: is performed by the script deploy-all-vfuels-as-website.sh. Running this script deploys all .vfuel files built by the script newspeak/tool/build.sh.
• Deploying as a PWA: Currently, only the Newspeak IDE application binary HopscotchWebIDE.vfuel (referred to as webIDE) can be deployed and served as a PWA out of the box. This deployment of the webIDE is performed by the script newspeak/tool/deploy-webide-vfuel-as-pwa.sh.

Note: If you want to deploy other application's .vfuel as a PWA, you can clone the directory structure under webIDE, rename it, make changes to index.html, manifest.json, sw.js, primordialsoup-setup.js, remove files not applicable to your application, and replace HopscotchWebIDE.vfuel with your application's .vfuel.

Refer to section [4. Building, deploying, and serving Newspeak application(s)](4.-Building,-deploying,-and-serving-Newspeak applications) for more details regarding the two deployment methods.

The term serve refers to running the HTTP server in a directory where the Newspeak application was 'deploy'ed. You also need to start the HTTP server in the 'deployment directory' in order to run the application outside the development environment.

3.3 Building Newspeak applications: the build.sh script

The script newspeak/tool/build.sh builds primordialsoup, followed by building the .vfuel files listed in the script, then copies the .vfuel files to the newspeak/out directory along with other files needed to serve the application in the .vfuel binary. It must be executed from the newspeak/tool directory.

Below are two examples of building:

1. The default build: This works out of the box, as described above. Use this if you are starting to build Newspeak.

   cd ~/software/nswasm/newspeak # Adjust to your directory path
   cd tool
   ./build.sh

2. The extended build: Can be used to build your own application's .vfuel. As an example, your application is in class 'CheckedItemApp' (saved to the file 'CheckedItemApp.ns'). You can build its .vfuel either by editing the 'build.sh' and adding the appropriate line, or using this extended method. The arguments are one or more 3-tuples describing the runtime, the application class, and the vfuel name. Here is the example build.

   cd ~/software/nswasm/newspeak # Adjust to your directory path
   cd tool
   ./build.sh RuntimeForHopscotchForHTML CheckedItemApp CheckedItemApp.vfuel

4. Building, deploying, and serving Newspeak applications

As described in Building and deploying Newspeak: lifecycle, Newspeak applications can be deployed and served as a Progressive Web App (PWA), or a 'regular' website. Currently, only the Newspeak IDE application, the webIDE, can be deployed and served as a PWA out of the box.

Reflecting the above, there are two 'deploy' scripts, deploy-webide-vfuel-as-pwa.sh and deploy-all-vfuels-as-website.sh. Both require an argument containing a name of the directory from which the Newspeak applications are served by the script serve-newspeak.sh. The first (PWA) deploy script also requires a name of the PWA version file (usually 'localhost'; otherwise 'newspeaklanguage.org', 'myApp.com' or similar).

4.1 Building, deploying, and serving Newspeak IDE as a Progressive Web Application (PWA)

Currently, only the Newspeak IDE application binary HopscotchWebIDE.vfuel can be deployed and served as a PWA out of the box (any other .vfuel application you have can be deployed as a website, see later items).

The PWA deployment of the HopscotchWebIDE.vfuel is performed by the script newspeak/tool/deploy-webide-vfuel-as-pwa.sh.

Read and run the following script steps to build, deploy, and serve the HopscotchWebIDE.vfuel as a PWA.

Assuming you started the application server for the PWA app on port 8081 in the script steps below, the application can be accessed at a URL http://localhost:8081/webIDE.

# Build Step: 
#   Should be run at least once, and after any change to a Newspeak source file.
#   Builds all '.vfuel' files listed in the 'build.sh' 
#   and places them to the 'out' directory. 
#   Note: The listed '.vfuel' files include the 'HopscotchWebIDE.vfuel'.

cd ~/software/nswasm/newspeak # Adjust to your directory path
cd tool
./build.sh
   
# Deploy Step:
#
#   Deploys the 'HopscotchWebIDE.vfuel' as a Progressive Web App (PWA) (as opposed to a website).
#   Copies all built files to the Newspeak HTTPs server directory
#   specified in the first argument, and updates the PWA Service Worker version file
#   specified in the second argument. The updated version is used as the PWA cache version.
#   By 'All built files' we mean the 'HopscotchWebIDE.vfuel' and miscellaneous js and html files
#   supporting the PWA, as well as the script 'serve-newspeak.sh', which starts the HTTP server.
#
# Arguments:
#
#   1. http-server-dir
#   2. pwa-version-file 
#   See function 'args_parse_for_deploy_as_pwa' for details
#
# Usage Examples:
#
#   1. Deploy files to server running from
#      the '~/servers/newspeak-http-server' directory, serving as 'localhost'
#      - cd tool
#      - ./deploy-webide-vfuel-as-pwa.sh  ~/servers/newspeak-http-server  localhost
#
#   2. Deploy files to server running from
#      the '~/servers/newspeak-http-server' directory, serving as 'newspeaklanguage.org'
#      - cd tool
#      - ./deploy-webide-vfuel-as-pwa.sh  ~/servers/newspeak-http-server  newspeaklanguage.org
#
#      'newspeaklanguage.org' is a special case in the sense that git does NOT ignore
#      it's version file, the '$NEWSPEAK/pwa-deployed-versions/newspeaklanguage.org.version'.
#      This ensures the global uniqueness of the PWA version served from 'https://newspeaklanguage.org'.
#
#   3. Deploy files to server running from
#      the '../out' directory, serving as 'localhost'. 
#      This mimicks how the server was originally used, serving from the '../out' directory.
#      The advantage of serving from the '../out' directory is that 
#      *you ONLY need to run the 'deploy' script once, after, just keep running the 'build.sh' script.*
#      - cd tool
#      - ./deploy-webide-vfuel-as-pwa.sh  ../out  localhost

httpServerRunPath=~/servers/newspeak-http-server # Adjust to where you want HTTP server running

./deploy-webide-vfuel-as-pwa.sh $httpServerRunPath localhost

# Start HTTP server: 
# 
#   One time only - rerunning the above 'Build step' and 'Deploy step' does not
#                    require server restart

cd "$httpServerRunPath"
./serve-newspeak.sh 8081

# Next: If your './serve-newspeak.sh 8081' serves 'localhost', (then your second argument 
#       to './deploy-webide-vfuel-as-pwa.sh' should also be 'localhost'), and you can 
#       access the webIDE binary `HopscotchWebIDE.vfuel` from the browser as:
#
#     http://localhost:8081/webIDE
#

Running the above commands would build, deploy, and serve the HopscotchWebIDE.vfuel as a PWA.

4.2 Building, deploying, and serving any Newspeak application (.vfuel) as a website

The script newspeak/tool/deploy-all-vfuels-as-website.sh deploys all .vfuel files built and copied into the newspeak/out directory as a website.

Read and run the following script steps to build, deploy, and serve any .vfuel application as a website.

Assuming you started the application server for the website on port 8081 in the script steps below, each built .vfuel file can be accessed similar to http://localhost:8081/primordialsoup.html?snapshot=HopscotchWebIDE.vfuel, http://localhost:8081/primordialsoup.html?snapshot=CounterApp.vfuel, etc.

# Build Step: 
#   Should be run at least once, and after any change to a Newspeak source file.
#   Builds all '.vfuel' files listed in the 'build.sh' 
#   and places them to the 'out' directory. 

cd ~/software/nswasm/newspeak # Adjust to your directory path
cd tool
./build.sh
   
# Deploy Step:
#
#   Deploys all '.vfuel' files listed in 'build.sh' as a website (as opposed to PWA).  
#   Copies all built files to the Newspeak HTTPs server directory
#   specified in the first argument.
#   By 'All built files' we mean all '.vfuel' files built by 'build.sh',
#   and miscellaneous js and html files supporting the website.
#
# Arguments:
#
#   1. http-server-dir
#   Note: there is no need for the second argument as in the PWA script -
#         we do not need a PWA version number.
#   See function 'args_parse_for_deploy_as_website' for details
#
# Usage Examples:
#   1. Deploy files to server running from
#      the '~/servers/newspeak-http-server' directory
#     - cd tool
#     - ./deploy-all-vfuels-as-website.sh  ~/servers/newspeak-http-server
#   2. Deploy files to server running from
#      the '../out' directory.
#      This mimicks how the server was originally used, serving from the '../out' directory.
#      The advantage of serving from the '../out' directory is that 
#      *You ONLY need to run this 'deploy' script once, after, just keep running the 'build.sh' script.*
#     - cd tool
#     - ./deploy-all-vfuels-as-website.sh  ../out

httpServerRunPath=~/servers/newspeak-http-server # Adjust to where you want HTTP server running

./deploy-all-vfuels-as-website.sh $httpServerRunPath

# Start HTTP server: 
# 
#   One time only - rerunning the above 'Build step' and 'Deploy step' does not
#                    require server restart

cd "$httpServerRunPath"
./serve-newspeak.sh 8081

# Next: If your './serve-newspeak.sh 8081' serves 'localhost',
#       you can access the '.vfuel' application from the browser as:
#
#     http://localhost:8081/primordialsoup.html?snapshot=HopscotchWebIDE.vfuel
#     http://localhost:8081/primordialsoup.html?snapshot=CounterApp.vfuel
#     etc
#

newspeak's Issues

Searches for sends to methods that have no definition do not find anything

Unimplemented messages that are sent do not show up in search results - we don't have a good way to find these, as we don't have a fixed selector to ask for senders of. We would need to scan all sends (as opposed to just all definitions) and pattern match against them. Might be very costly. Could be mitigated by searching for senders of a fixed selector, but won't handle wildcards. Unless we get all instances of symbols used in sends and store them, and pattern match against those.

Deployment via the IDE creates excessively large vfuel files

There seems to be a leak somewhere. The size of the deployed vfuel varies depending on how large the IDE memory footprint is somehow. The time to deploy will likewise vary.

Test results twice in the history

The progress bar leaves an extra entry?

Highlight implicit sends whose selector is not lexically visible

As the old Squeak version did.

Restore black market access in debugger

Squeak-based Newspeak had a feature that allows one to access elements that are not in scope while debugging. We need to support this in the web version. Indeed, this mechanism has uses throughout the IDE, in object presenters and methd evaluators, when defining exemplars etc. It may be worth extending it to provide convenient access to non-public members, to pre-existing exemplar data etc.

Display graphical results links in evaluators

Evaluating an image produces textual link; we should be able to use image links in such cases. In general, if a result has a graphical view, we should use produce an image link.

Fast parser accepts junk at the end of an expression

public aMethod = (
messageSelector 66
)

accepts and runs, assuming messageSelector works, and returns self.

Ampleforth needs to support printing

The browser can sort of do this for us, but:

a. This adds unwanted Browser chrome/boilerplate.
b. Doesn't work in standalone app.

Ampleforth needs to support drag/drop of images, videos, audio clips from outside the browser

Senders/implementers/references menus should dispaly only selectors, not literal strings

Any literal string in a method is currently displayed (truncated to length 64). Ideally, non-selectors should not be listed.
One might debate this; it can be useful to search for an occurrence of a literal string (but that doesn't actually work right now either). In any event, this is an exceedingly minor issue and not a priority at all.

Ampleforth needs to support highlighting of corresponding point in dual view

When viewing the raw view, we'd like to be able to click and see the same point in the rendered view, and vice versa (as in TeXShop or Madoko).

Add custom view for JS objects

We should be able to interrogate aliens and show their properties, constructor etc. Even allow them to be modified, just like a Newspeak object.

Ampleforth needs to support search and replace

IDE should protect itself against buggy user views and print methods

User code can contribute object views to inspectors, and user printString methods are used in inspectors as well.
The IDE needs to trap these to avoid crashes.

Add a local transcript presenter, rather than relying on the console

Tool tips

We should add a tool tip abstraction to Hopscotch. Probably build it on top of a separate hover functionality. One use for this might be to replace most of the existing help text, which mostly describes individual UI controls, with tool tips that provide the same explanations in more compact form.

Ampleforth needs WYSIWYG font selection, font size, heading/section type

This is slightly more complex than #105, because we need a menu of options to choose from.

For sections/headings, we could use support for both unnumbered (as in Googledocs) and numbered (as in LaTeX) sections.
Choosing Hn or sub...section, with a * at the end to indicate no numbering would be ok.

Implement MemoryHole in Web IDE

We need a way to access git, and a reactive UI for it.

IDE freezes expanding class

Happy New Year!

I think I found a bug. To reproduce:

1. Open https://newspeaklanguage.org/samples/primordialsoup.html?snapshot=HopscotchWebIDE.vfuel
2. Search for Workspace using the search bar. Two classes are found.
3. Expand one of classes using >. The class expands.
4. Try to expand the second class. The IDE freezes.

It does not matter which of the two classes I expand first.

I tried it on Chrome and Safari on macOS 12.6.2. Both behave the same.

Is there a way to halt execution and enter a debugger?

No catching of exceptions in the IDE

Bugs in IDE code cause the system to crash rather than opening a debugger.

Add custom view for DOM nodes

In the case of aliens that are DOM nodes, we should be able to display them as HTML.
Is there an HTML pretty printer exposed in the browser?

Senders/implementors in factories does not show actual messages other than slots

This is due to a deficiency in the mirror, which Ryan's version corrects this, as well as dealing with magic selectors that are implemented directly by bytecode. Integrate. Unfortunately, this requires the new byte code set so a full reconciliation with Psoup is needed.

Use PWAs instead of Electron

The electron app is huge. We should create a progressive web app utilizing the local browser, rather than having to download all of chromium. This would also mean that every app, not just the IDE, could be plausibly deployed as a standalone app and not just a web page.

Implement transient slots.

As the old Squeak version did. They are needed long term of orthogonal sync, but also for implementing images and most immediately, for improved liveness. Every cached slot should become a transient one, and every time it's code is redefined, the slot should be nil'ed (as with sync) and the data will be be recomputed - ensuring instant live update.

Ampleforth window sizing is problematic

Ampleforth window sizing should adapt dynamically to the available real estate in the OS window. It doesn't, and so instead the solution is to give the rendered view a fixed width (that is resizable). The problem likely goes much deeper, to Hopscotch itself. Intermediate solutions might at least try and adjust to the toggling of the raw view.

Need a way to add custom views from outside the Browsing module.

Exposing the objectViews method so it can be called from the outside (and so onecould add views to it) should be easy, no?

Ampleforth needs WYSIWYG bulleted and numbered lists

Abit more involved, because we need to be able to create individual bullets. Also nice to control bullet scheme, as in LaTeX \item, and number scheme (e.g., (a), (1) or (A)).

"Find references" on methods acts as a toggle after not selecting from the popup (very minor)

Steps to reproduce

Navigate to Browsing>>ClassPresenter

Click the "find references" button on #acceptResponse
Actual = Expected: Popup shows with method name acceptResponse and other messages named inside - this is correct
Click outside the popup
Click the "find references" button on #acceptResponse again
Expected: Popup shows with method name acceptResponse and other messages named inside
ACtual: Nothing happens

Implement metadata

Necessary for many things - including the transition to a fully exemplar based IDE.

Docker build

As a developer, it would be easier to built Newspeak if it had a docker image with everything setup.

Ampleforth needs to evolve into a fully functional GUI builder

Given that we can define documents with widgets, the editor is inherently a GUI builder; simply define a document with widgets, but without text. However, this approach needs to be refined to make it a natural and convenient way of creating UIs.

Add custom view for colors

Icons can lose their intended size on update

In some cases, access control icons appear at giant size after an update.

Adding members in debugger in response to DNU may fail

The debugger has a feature that allows you to immediately add a method/class/slot in response to a DNU. The problem is that it fails in cases where the receiver class has exemplar data. The code operates browsing the receiver class and manipulating the presenter that is active at that point. The code predates the introduction of exemplars. When it was written, browsing a class meant that the current presenter would be a class presenter. Now, however, it may be an object presenter (in cases where the class has exemplar metadata). Object presenters do not respond to the same messages as class presenters, and so things go bad.
We can extend object presenters with the missing methods, or change the code to check what the current presenter is and act accordingly. I think the former is cleaner.

Test results do not update correctly when new tests are added

Presumably model captures old test suite?

Ampleforth reactive update doesn't work across distinct presentations of the same document

If one has multiple presenters on a given document - perhaps due to transclusion, or debugging or whatever other cause - changes in one presenter are not automatically propagated to others. This is because most changes to a document do not invoke updateGUI: . Rather, they cause instant live updates to the presentation by modifying the raw HTML (possibly driven by DOM updates) and recomputing the presentation. This works well, and is much more efficient than updateGUI:, which is much too slow to be invoked on every keystroke as required. However, it leads to the problem this bug describes. The fix should be to have document presenters explicitly connect via ducts.

Long strings mess up messages menu

Strings show up in the messages menu of methods (and factories). If the strings are very long, the menu formatting goes out of control.

Ampleforth could use reference/footnote/citation/bibliography support

This may be start our as a variant of HTML links or HyperlinkFragments referencing a list of papers, but we'd want nice naming or numbering automatically, and transcluding individual entries from something akin to bib files . Importing .bib files would be super nice.
You'd want to expand the citation in place on demand, as well as a(n optional) list the complete Bibliography at the end as in print (the latter is good for having a complete list of references, and for printing versions for submitting papers. Submitting has other issues though - page numbers, and generally the requirements venues have for mainstream formats.

Likewise, footnotes. In principle they make no sense in an online format, just as page numbers don't. But they make sense when printing out.

Complete Exemplar support

Class presenters now support exemplars, but we need to:

a. Add metadata for most classes.
b. Automatically generate exemplars for classes with unary factory selectors.
c. Add exemplar support for methods.

Ampleforth needs WYSIWYG Bold, Italics, Underline, Strike-through, center, right/left justify, super/subscripting

All of these features are essentially trivial variations on each other. They should all be relatively simple to create as variations of "Make it an Amplet", where the selected text is replaced by a suitable DOM node whose contents are the selected text.

System crash in workspace when message widget is closed after syntax error

Steps to duplicate:

• Go to https://newspeaklanguage.org/samples/primordialsoup.html?snapshot=HopscotchWebIDE.vfuel
• Click "Workspaces" link
• In the input field, type something syntactically invalid, for example: 1+
• Shift-Enter to attempt evaluation
• An error shows
• Click the "x" beside the error
• After this, Shift+Enter no longer functions to evaluate, the Shift modifier seems to be not sent to the input field

From a follow up by Gilad on the google group, this is a system crash:

What happens is that, when we have a syntax error, clearing the result list gets to deal with a parse error instead of a thread, which is what it expects. And, because we have a longstanding problem that crashes within the IDE don't go to the debugger, the result is a complete crash :-(. The system is dead; the editor is a CodeMirror editor, and it's javascript code keeps responding to events, so you can still type into it - so it may not be obvious that the system actually crashed.

Ampleforth needs to support HTML links in WYSIWYG view

A bit more involved than #106 , because we need a dialog to get the URI (except in the trivial case).

Search & senders/implementors should highlight the search term in the editor

both search and regular senders/implementors should highlight the search term in the editor of the method they find.

Import and Export slides from Telescreen

One should be able to import or export slides as documents. One should also be able to do this with groups of slides to be exported (to new presentations) and also import groups of documents. Ideally drag and drop.

Ampleforth needs WYSIWYG text & background color controls

Very similar to #106, except we should use the color selection fragment instead of a menu.

The object view scheme doesn't always update reactively very well

Except for the exposed view, the rest are not in the fragment tree. All views are recomputed at each update. So only the exposed one retains its state.

Search results do not maintain their expansion state if there is an update.

May require tagging the individual mirror groups. But the problem may be with the fact that elements are deferred, and DeferredContentComposer doesn't update the deferred fragments.
Indeed, when it updates, it never compares the results of the old deferred computation to the new ones - it just installs the new ones when they are ready. Presumably it should update the old deferred part using the new deferred part. This may be tricky because the visuals may disappear underfoot if we replace them with the initial values.

Debuggers appear twice in the history

Show tests does not work properly

The show tests feature does not list any tests when it displays.

Testing Github Issue tracker

Test