[ANN] ProjecturEd 0.1.0: look at your data frames in a window, and edit them there

Package Announcements
1

Hi all,

I’ve just released the first version of ProjecturEd. Here’s the first thing it’s useful for: let’s say you have a DataFrame in the REPL, and you want to look at it, you want to scroll through it, sort it, filter it, and fix a value, without leaving Julia.

This is how you can install it and give it a try:

pkg> registry add General
pkg> registry add https://github.com/projectured/ProjecturedRegistry
pkg> add Projectured ProjecturedSDL ProjecturedDataFrames DataFrames SimpleDirectMediaLayer

julia> using Projectured, DataFrames, SimpleDirectMediaLayer
julia> df = DataFrame(n = 1:100_000, square = (1:100_000) .^ 2)
julia> display_in_editor(df)

A window opens with your frame as a table, and the REPL stays free (starting Julia with more than one thread helps but not necessary). In the table you can:

  • scroll through big frames (millions of rows/columns, both directions are lazy): the view doesn’t copy the frame, and it only builds the rows that are on screen
  • sort by a click on the arrows in a column header (Shift+click adds the next key)
  • filter out rows: type in the field under a column name or write a Julia expression like age > 30 && startswith(city, "B") for the whole row
  • filter out columns using the type-in field at corner of the table
  • find a value with Ctrl+F
  • edit a cell: the new value goes straight into your df, and Ctrl+Z takes it back
  • use Ctrl+Shift+P for context sensitive help

Each data frame that you display gets its own tab, and you can have multiple of them and drag them around splitting the screen, etc. If your code changes a frame later, refresh_display_editor!() shows the change.

Fair warning: the first window of a session takes half a minute or more even on my powerful computer, because Julia compiles most of the editor on the fly. Add AutoPrecompile.jl and put it in your using line. It builds the compiled code in the background, and in the next session the window opens in well under a second.

Data frames are just the start. ProjecturEd is a projectional editor: where the data is the source, every view is computed from it, and an edit in a view changes the data itself. About twenty other domains come as packages, for example JSON, YAML, XML, Markdown, SQL, Julia code, basic math formulas, a few charts, and you can add your own. Domains are in different states of completeness though.

The packages are in their own registry for now, not in General, and you need Julia 1.12 or newer (if using 1.13 make sure you are using 1.13.1).

A note on how it’s made: ProjecturEd started in Common Lisp in 2013, and I wrote that version by hand. I started this Julia port in May 2026 for a discrete event simulation tool for communication networks, and Claude Code writes most of its code. The design and the decisions are mine, if you are interested see the plans folder in the development repository.

It’s an early release, so expect rough edges, and names can still change. Issues and questions on GitHub are very welcome!

Here is a screenshot:

image
image1050×687 86.8 KB

2

If these are the numbers, this solution should be to integrate AutoPrecompile in the standard workflow, i.e. add AutoPrecomile.jl in the project dependences and using it in the background when one uses the ProjecturEd package …

3

In the AutoPrecompile.jl[GitHub - projectured/AutoPrecompile.jl: One package image for the packages that a session loads, built from recorded precompile statements · GitHub] readme I read:

“A Julia session compiles much of the code that it runs, and it keeps that code only until the process ends. A package can cache compiled code in its own package image with a precompile workload, but that workload holds only what the package itself runs. Code that joins several packages, such as a table view of a data frame drawn in a native window, belongs to no single package, so each new session compiles it again.”

I strongly believe this not to be true, at least if you consider the widely used PrecompileTools package.. when a package use PrecompileTools.jl and make calls to external packages in its @compile_workload macros, these packages are precompiled too. Indeed they write:

` ` `julia
@compile_workload begin
        # all calls in this block will be precompiled, regardless of whether
        # they belong to your package or not (on Julia 1.8 and higher)
[...]
4

You’re right, the readme is wrong.

The problem is that a workload can only run code from its own package and its dependencies. The data frame view in ProjecturedDataFrames and the native window support in ProjecturedSDL don’t depend on each other, so neither one’s workload can run “show a data frame in a window”.

Edit: the other issue is method invalidation when new packages are loaded.

But maybe I’m doing this wrong, I’ll dig a bit deeper and see if I can get rid of the AutoPrecompile.jl package because I would happily do that.

5

Thanks you again, your comment lead to something useful.

It turned out that only 1 method (from 2,600) needs both packages. The compilation time was mostly the editor’s own code, which no package cached, and the dependencies of DataFrames and SDL invalidated a lot of compiled code. Now each package has a proper workload, and the call sites no longer let those methods invalidate it. With the new release the first display_in_editor for a large data frame after simply using Projectured, DataFrames, SimpleDirectMediaLayer opens in about 0.7s (down from about 50s).

AutoPrecompile isn’t needed for this anymore, and I’ve corrected its README.