nightcraft

Thanks!

Thanks!

That's correct: 2, 3, and 5 are currently available. This initial set was intended as a minimal (albeit limited) set that demonstrates the UI capabilities. More widgets/controls (including the ones you've mentioned) are definitely coming.

7 is something I've considered (along the lines of a redistributable "Scripton runtime" that packages up the scripts and bundles a portable Python distribution). However, that's currently much further down on the todo list.

Thanks! The C++ bit comes in for the IPC (inter-process communication) between the IDE and Python.

There are a few different ways for the Python process to communicate (send data over for visualization, receive/transmit commands, etc) with the IDE. For instance, you could communicate over HTTP. Depending on the use case, that can have an appreciable performance overhead. Instead, Scripton uses a lower-level mechanism with a protocol optimized for sending binary payloads (eg: large numpy arrays, images, etc). This communication and processing is implemented in C++ as a native multithreaded node module. It effectively enables very low latency and high throughput visualizations.

Some folks do like hold-to-quit to avoid accidentally quitting (similar to Chrome's default behavior). However, point taken - it'll be configurable in the next update.

IMO, VSCode's codebase is excellent and quite well designed with most functionality abstracted out into injectable services. However, the interaction of these services and other bits of architecture do impose certain limitations that are tricky to workaround. One option is to fork vscode, write your own services, alter the architecture as necessary. You're then faced with keeping this in sync with the rapidly changing upstream code. Another alternative is to implement it as an extension, but that has a fair number of restrictions.

For certain projects, forking/extending may be the right call. However, for the degree of customization required for Scripton, writing from scratch turned out to be the more viable path (vs attempting to workaround/rewrite yet another component in vscode). The trade off here, of course, is that you lose out on the familiarity and ecosystem that VSCode has built over nearly a decade. The hope is that Scripton remains sufficiently familiar (eg: Search / CMD+P / etc work similar to vscode) while being compelling enough in its own right.

Thanks, appreciate the feedback!

While the initial focus is on visualization capabilities, the missing IDE features are actively under development. Beyond cross-platform support, which PyCharm features would you consider essential and would like to see the most?

The vscode extensions path, unfortunately, would have been too restrictive for many of Scripton's features/technical requirements (tightly coupled REPL, minimal IPC overhead, ...)

Yup, it was written from scratch. Yeah, having a flexible virtualized table certainly makes it easier to build more complex things on top (a lesson I initially learned from NSTableView/UITableView).

Currently, it's not user extendable. While it does support some IPython features (eg: Python classes that implement IPython's rich outputs also work in Scripton), ipywidgets are currently not supported.

Thanks! GitHub Copilot support is actively under development.

The plan for now is just subscriptions.

However, I would like to eventually have something like Jetbrains' "perpetual fallback license" where you can keep using up to a particular version after, say, a year of subscription.

Coincidentally, one of the first components I wrote for Scripton was a virtualized table for handling million+ row dataframes with Tufte-esque inline visualizations (in a much evolved form, it currently backs the REPL).

The data table got deferred to focus on the visualization bits for the initial release, but it's definitely planned!

Not yet. Some internal prototypes did try using IOSurfaces on macOS to go with the zero copy route, but there were a fair number of limitations.

That said, the IPC minimizes copies and is actually fairly efficient at handling large numerical arrays.

Thanks!

The initial prototype did use React, but the overhead in certain cases soon became an issue. It got replaced by a custom virtual dom implementation (coincidentally quite similar to Atom's Etch), but debugging complex updates remained an issue. Eventually, it ended up in a place quite similar to vscode: no frameworks and a handful of "core components" (eg: a virtualized list view)