Second Beta Release

Besides some bug fixes, this second beta release adds two new features: duplicating programs and searching for text.

While working on a specific program or script you might want to save the current state the program is in and continue on another copy for some breaking changes. Perhaps you wish to experiment without affecting the original file. During workshops, for instance, we would often develop programs step by step whereby some of the intermediary programs might be interesting in their own rights. Participants therefore asked for a way to keep those intermediary programs.

TigerJython's new feature allows you to quickly and conveniently duplicate the current program and thus effectively fork development. To this end, there is a new button in the toolbar, right next to the download button.

Beta-Version 1

TigerJython 3 offers a more modern user interface and allows you to use different Python interpreters. With the core functionality in place, we welcome feedback on the new version and possible bug reports.

Some of the functionality found in TigerJython 2 has not yet been reimplemented, such as the debugger, say. Nonetheless, any (constructive) feedback is welcome, also to guide us in settting priorities for implementing features.

Early Access Preview 12

This release contains mostly bug fixes, particularly in the syntax highlighter. It also has an updated JavaFX and Jython core. Most of the TigerJython functionality should now be included and readily available.

Early Access Preview 11

This release adds syntax highlighting and support for Micro:bit and Calliope Mini. It also includes various changes to the user interface due to early feedback.

Syntax Highlighting

The syntax highlighting for Python goes farther than usual syntax highlighting in distinguishing various components of the code. For instance, when a name is followed by parentheses (...) to make it a call, the name will change colour. While the colour scheme is a tentative draft and only implemented in the TigerJython-theme, it is hoped that the enhanced syntax colouring helps educators point out various elements of the code and gives students valuable clues to the structure of their programs.

BBC Micro:bit and Calliope Mini

Both the BBC Micro:bit (V1 and V2) and the Calliope Mini can be selected from the menu of execution targets. TigerJython then creates a hex-file and searches for the device's USB-drive to download the hex-file directly to the device. If your program imports another of your programs as a module, both will be packed together and sent to the device.

Various other changes

• TigerJython will no longer run with Java/JRE 8. While the class files would be compatible, there are issues with the libraries used, which require a newer version of Java (we tested it with Java 11 and 14 so far).
• The Preferences now include a tab displaying some basic system information. This is also intended to contain system error messages so as to provide a template for bug reports.

Early Access Preview 7

This EA preview includes the following changes:

• Document handling is now fully implemented (programs can be imported from files, exported/downloaded and deleted);
• By saving all documents, programs can now import other documents as modules;
• TigerJython starts an executor instance ahead of time for faster response and quicker execution;
• Various bug fixes (thanks for all the feedback!).

Early Access Preview 6

This release includes three major changes:

• Execution of programs is done through a client-server model;
• The executing interpreter is selected on a per-document basis;
• Updated to the interface and document handling.

Please keep in mind that this preview is work in progress without various implementation details undergoing constant changes.

Client-Server Model

TigerJython instances to execute programs and evaluate expressions are now run in a client-server model. This allows for much finer grained interaction and control and opens up possibilities such as a debugger. It also allows to start an instance ahead of time and send it the script to execute later on, which will speed up the process of starting scripts.

Although there is hardly anything visible of this, this is a crucial step forward, as it lays the groundwork for, e.g.:

• Monitoring an application during execution and allowing to report on memory usage, thread count, etc.;
• Implementing a debugger that allows to run a program step-by-step and report on variables;
• Returning values other than strings from an interactive session (notebook);
• Discerning between output and results in the interactive mode.

Executing Interpreter

The interpreter to execute a program is now chosen on a per-document basis rather than globally. This is done through a small menu on the top right corner of the editor window. This is step towards running program on external devices such as a micro:bit, a robot, etc. The menu for selecting the executing interpreter/device will contain entries for those devices as well (although this is currently not implemented, yet).

Document Handling

Up to now, documents (such as Python programs) have been cached internally in a database, which has been automatically synchronised with the file on the disc—if one exists and is attached. This has allowed for making documents persistent even before they are saved or have a preview available without the need to access the file on disc.

In this release, the cache has been extended to an internal storage that also captures the undo history of a document. It is now possible to undo any edits of a document across sessions.

We are now switching to a slightly different model where all documents are entirely stored and managed in an internal database without automatic file synchronisation—however, this new model is not yet completely implemented. It will be possible to import any file from disc, just as the new user interface already features a 'download' button to export any document to a file on disc. The internal database will be extended to offer various options, i.e: (1) local internal storage, (2) automatic synchronisation with files in a local directory, (3) automatic synchronisation with an online cloud, (4) backed up by a git engine. In order to keep the overall interface simple, the option for which of these options is chosen will be globally and not on a per-document basis.

The terminology of 'download' etc. is chosen based on the belief that it is closer to the mental models of young users these days, rather than the classic 'save as file'.

One consequence of this new design is that we no longer need a menu with options for 'open', 'save', etc.

Further Changes

There is a number of smaller changes in this release:

• A new 'log' window (besides the output and error windows at the bottom of the editor) records various information that persist during a session. This is primarily meant to help educators understand the steps students took in case of a problem. For instance, it records which interpreter has actually been used to run the script.
• The classic menu has been (temporarily) removed. There will not be such a menu in the main window, anymore. On systems such as Mac OS X, we will keep the systems menu, of course. And we will offer an option in the preferences for displaying the menu. However, the entire interface is geared towards working entirely without the main menu.
• The name of a document can now be easily changed through something like a navigator bar at the top of the editor window. This is accompanied by a 'download' button.

Early Access Preview 5

This release includes three major changes:

• Switched to Jython "Standalone", which includes all the libraries;
• First support for existing TigerJython libraries;
• New file management system.

TigerJython Libraries

The libraries included in this preview are the same as in TigerJython 2.18, with a few minor adaptions due to missing support functions in TigerJython itself. The current preview also supports repeat loops, as well as some of TigerJython's built-in functions (such as makeColor()).

In contrast to TigerJython 2.x, programs are now launched and executed in a separate process. Some existing libraries like turtle graphics do not honour this change and do not properly shutdown when a window is closed. It might be necessary to manually stop a program in that case (using the "stop" button).

Support for TigerJython will still be limited for a while. First priority at the moment is on the editor itself. Once the editor works well enough, the runtime system itself will be overhauled, including proper support for all the built-in functions and repear loops. Right now, repeat loops are emulated by replacing them in the Python-file on the disk just moments before execution. Once the program has been started, the code in the file is changed back. Due to this trick, the Python interpreters never see a repeat statements, but only common for loops—however in some cases of unfortunate timing, the change back to the version with repeat loop happens before the program has actually been started, resulting in an error stating that repeat is illegal. As mentioned above, this is only a temporary solution and will be fully amended once we complete work on the runtime system.

File Management

In line with the model of persistency that TigerJython 3 strives for, files/documents are fully restored when the application is started again, with both the text and the position within the file preserved. The idea is that each user creates a "personal" collection of Python files and modules, which might be physically located at various places, but are always readily accessible from within the application itself. Opening a file in the classical way thus amounts to adding a new external document to this collection.

As a second step, this should eventually allow to connect TigerJython to user accounts in the cloud so that students can not only interrupt their work at school at any time and resume a week later, say, but also resume their work from home, for instance, or even use WebTigerJython.

Nonetheless, the new file management system is not and never will be as powerful as project-based management, Git, or similar. Given that it is an educational tool, however, that is neither its purpose nor its intent. There are already excellent tools and IDEs available that are more oriented towards professionals.

Be careful when working on your projects: TigerJython will manipulate and rewrite your original files without warning!

User Identity

TigerJython now generates a quasi-unique "user number" the first time it is run on a new system. This user number is a sequence of 48 (pseudo-)randomly generated bytes, encoded as base64. Its purpose is to allow assigning submissions in scientific studies to different users without identifying the users themselves. TigerJython itself does not collect any personal information (however, we are working on a possibility to send anonymous usage statistics on an opt-in basis).

The generated pseudo-random number is not guaranteed to be unique and is not suited to act as an identifier for individual users. The name "user number" instead of "user identity" or similar is meant to reflect that it is just number and nothing more.

4th Preview

We used the 4th preview only internally for various test purposes, but did not upload it to GitHub. That's why it looks like there was a jump in versioning.

Early Access Preview 3

This release includes some bug fixes and various improvements in user preferences and settings, such as selecting a theme or error checking.