#atomique — Public Fediverse posts

#atomique includes treesitter (used in browser and in text editor) . I finally decided to put it in a library. The code is vendored in a folder but at least I can keep my runtime at 630kb and have the 15M in a libtreesitter.so in another file.

It  avoids rebuilding it each time I clean up the whole project. On the Pi one it brings the compilation time to 20 mins..

Tired of fighting bugs I am rethinking the h1 font. That sovietski font was cool but really readability suffers. Toned it down a bit while keeping some of the old USSR style. Added manual anti-aliasing too.

Work in Progress. #atomique

@santi On the other hand my plan about #atomique is that I want it to be out "complete".  Not that it would have all apps ready by 1.0 time but that the basic activities should indeed work in the most simple way possible and that requires a lot of featurs to be ready.

Probably the first target of useabiliyt will be a) the builtin "IDE" (a text editor with compilation and syntax highlighting that is)   and b) the same Text Editor useable to edit confortably the .gmi files

I want atomique to have a builtin capsule editor. Edit your .gmi blog/site and a local .lua engine converts to all static formats possible that just gets synced to server.

@riffer A hobby pixel-precise OS made of C+SDL+ Lua/Teal. I post about it with the #atomique hashtag and it will be on atomique.org when ready for public use and released under MIT license.

Disclaimer: contains LLM generated code, which is why I don't release it to the public until I consider it clean enough.

@santi what is #atomique?

#atomique at 480x320 with small font with stuff moving around

Should be fun to use on one of these small screens (if you have a magnifier 😂)

https://www.youtube.com/watch?is=wWQhkoVzaPs60-oL&v=QdcWbzWOGsA&feature=youtu.be

#atomique in an Amiga-like mode cycling through screens. Since every app is a LuaJIT VM the system simply pauses the VM when it is offscreen, as seen in (grayed out in Radar, the task manager).

https://www.youtube.com/watch?v=ufWY8Mb2OZg&list=PLbyvlANRGLcQ

At least this one is at 60 fps since I filmed from my phone instead of trying to capture from Asahi Linux (has no GPU video encoding support on my Air).

Added a centralized Teal+Lua compiler service to #atomique to avoid multiple simultaneous compilations.

Most apps usually run their main code and moduls from precompiled .luac files for instant startup and low memory usage. But if Cache: disk is emptied all needs to be compiled into bytecode at launch.

With Teal and all components and JIT enabled this could grow up to 25 mb per app (each one building in its own VM when cache invalidated). This means starting 10 apps  simultaneously (eg. in a benchmark script) could explode to 250mb during a brief instant.

Not an issue unless you only have one core and 256 or 512Mb like GrandPaPi (my trusty raspberry Pi 1).

Each app's Lua VMs runs in a coroutine so you can just suspend it , wait for the .luac to be precompiled and resume it.

@kirtai In #atomique every thing is a disk (disk are jsut folders of course). They appear like disks though. Think of assign on Amiga except behind it could be remote WebDAV, a Zip or whatever.

A base system now has these “diskettes”:
System: (swap it to upgrade)
User: (Your own files)
Cache: (one folder writable per appid)
Logs: (same as cache, one folder per appid)
Trash: (guess what)

NeinCloud: (also one folder per appID, just another folder but the idea is you sync it on the host OS (SyncThing will have a native atomique UI to manage the host OS backend shares). Apps executed at sandbox level zero (online source) can only read and write their own data in there.

Clipboard is an app and data with its appid is already saved to NeinCloud folder so thinking about it you can effectively share clipboard with another machine this way.

If Shelf is an app it can also just save to NeinCloud. Just need to make and UI to make this clear.

-Like on Amiga (*) #atomique will support multiple per-app screens on different resolutions. You just click on that icon in the right corner to switch between different full screen apps. The desktop (which has all other windows apps on top) is just one of these apps that has a dedicated screen.

* but faking it  with pixel perfect scaling really

Introducing the concept of UIScale for UI elements into #atomique. Kinda like Apple introduced @2x for retina screens but adding @0x for low resolution below 600 pixels

0: aimed at like 320x200  uses of minimal pixel font for UI, padding/margin 1pixel.

1: the "normal" current scale aimed at ~72-100 dpi screens, still pure pixel fonts

2: And later @2x or @3x  from apple aimed at usage with TTF fonts, likely useful for chinese/japanese complex characters. (will work on that later). Thiking I might just have pixelated scaled UI but highly detailed font, after all all the scaling is fake.

Editing the smallest fonts in #atomique to  have alpha for a nice hand-made blending.

I know there's no real target hardware at that res but I want the UI to be Useable at very low resolutions.

Also croc was one one the native tools I wanted to bundle with #atomique. This should really be part of every operating system but easily exchanging files without a large corporation is rarely pushed forward by these same corps.

It has NetBSD etc but no Haiku because as usual the lack of a recent Go is the problem (one reason not to use Go for me)

TIL croc has builds for armv5 ! The Pi One is armV6l , no idea what board had armv5
https://github.com/schollz/croc/releases/tag/v11.1.0

Anyway I am happy I can easily exchange files with the #atomique build for pi one. The build takes ages so I  only test from time to time.

Current situation: the watchdog froze apps that took 5 seconds to respond and it was a bit to ambitious for the little machine on boot. The only machine I think wont need to be slowed  0.25s per icon  to show the lovely icons on boot .

At some point you will be able to mount .atdsk disk images (technically a folder) and run .atapp Apps (a folder too) from any origin. That is web apps that are actual apps.

#atomique will therefore have a basic, (not annoying I swear) permissions system to enable functions and relax the sandbox.

All Lua/Teal exposed system functions are defined in atm.* tables that the underlying C engine decides to populate or not in each apps's Lua VM.

So if you want to capture the screen in you AppInfo.lua  you just add permissions { "capture"} and the atm.capture.* functions will be enabled. or if you add "pandora", it adds everything, including the atmsys table with acesss to the hostOS functions.

Still thinking about the least anoying UI to show this. I think just a table with prechecked checkboxes on first launch so you are just conscious of what you are doing, not annoying the user all the time as iOS does with multiple popups.

I know the dominant idea is that if you want do something well you just can't do everything. You have to do one thing well and focus on it.

The thing is this is quite the opposite of the way I function / dysfunction.

Do I do everything badly ? Could be. But for me the important thing is the global "vision" (what a pretentious word). I mean that I want #atomique to feel, work and look the way I dream about it and there's just no way I will focus on just one architecture first and then grow progressively on a solid base. So , it is chaotic by nature as a process. I need to draw my little icons in the middle of debugging process to know where I want to go.

I want to test stuff, to experiment if it feels like I want it to and then evolve in that direction or scratch it and start over even if that means the foundation (big word again) changes below the building.

Started the day with 51 tasks open on #atomique and I am now at 81 so I *think* I am making progress.

 I was interrupted by other issues but yesterday I saw  I am at a stable ~59.9 FPS with a few things aninmating on screen on the Pi 4. Wasn't so perfectly smooth a pair of weeks ago before I started moving more essential things to C and optimizing the drawing mechanisms.

I was interrupted before I dared test on the Pi One... maybe later today but I will have to finish some other tasks before I get there.

#atomique

Having protocols in Teal really makes it natural to aim for a cleaner API.

Implemented a  Bindable protocol here so I can just bind a ColorSwatch to a prefs  value in one line. Also added a Serializable protocol to get and store colors.

 mySwatch:bind("desktopBackgroundColor", { onViewChange = apply })

#atomique

So yes converting most of #atomique to #Teal  was a _very_ good idea. Thanks @cochise for reminding me of its existence !

All "serious" apps that use  Views now use it. You can still build Games/Demos using plain Lua if you want to with the usual _init() / _update() _draw() model.

If you don't know already:
"Teal is a statically-typed dialect of Lua. It extends Lua with type annotations, allowing you to specify arrays, maps and records, as well as interfaces, union types and generics. "

https://teal-language.org/

And in case you missed that fact LuaJIT makes Lua astonishingly fast.  Combining LuaJIT + Teal is a great combination. Each app in its own little VM, but fast.

#atomique is getting a rudimentary automate framework because it helps a lot for tests / dev/  and for our friendly communist robots to do their share.

So today´s re-re-re-re-factor is about realizing treesitter is indeed fast and well-tested and should be the model to follow and integrate everywhere there is a selection in #atomique .

I never took time to learn about how treesitter worked before. Turns out people use js and all crap to *generate grammars* but the end result is a clean parser.c file per language.

Which means you can integrate it in your project as is, with just C (MIT License). So now Nucleon, the Gemini Browser, just like Text the text/code editor of #atomique have native treesitter support (so far for .c, lua and teal). Just trashed the previous handmade syntax coloring I had as there's no way it would be as fast/complete.

No need to have a javascript engine just for syntax coloring when your browser has it natively.

Looks like LuaJIT now has a port for RISC-V !

https://github.com/IgnotaYun/LJRV

Means I should be able (later…) to try running #atomique on my #VisionFive2 .

Hope it hasn’t rotten. Can’t leave hardware turned off too much time in the forest.

And here I am again doing a large refactor in preparation of the move of #atomique from plain lua to teal.

Teal compiles to Lua 5.1, so from a (yet non existing) end-user perspective it will be transparent.

But adding proper types as an afterthought is kind of a big tedious job. The communist robots will be very helpful for this.

Another laggy capture of a not laggy #atomique (trust me the FPS counters are real, I swear!).  This time showing how Task Manager  can pause and resume apps easily since each one has its own LuaJIT VM.

https://youtu.be/o6T-fXToSWY

Capture is not 60 FPS but this is #atomique showing how .c files are compiled on startup of app into Cache: disk . And the Precompiler app which scans all disks and compiles all changed .lua (and soon .tl) to .luac

https://www.youtube.com/watch?v=KDxhtrO9mvY

You  can see how the C loop still beats by a little the full screen fractal from 15 FPS on full screen in Lua  to 22 FPS in C.   Anyway, not a benchmark for the most optimized Mandebrot but a comparison of same code in LuaJIT vs C (and Lua without Jit for those of you who like to suffer). Lua is pretty fast in JIT !

C modules will make sense for filters once I rewrite Photoshop 3 for the platform (next year).

#atomique now has both C & Lua support. Each app package can have its Lua files in src.Lua , and C code in src.C .  The C code, is compiled in  a .so file in Cache: disk and the Lua code into .luac bytecode in the same Cache: disk.

Well, since I can't post a 60 FPS 2560x1600 video from this machine, it'll be a screenshot of #atomique in 1280x800  (at 2x on this retina M1 Air it is the workstation resolution for a 17" screen really).

You can see the system and the Pulse app knows which cores are the Fire cores (performance) on the M1 and assigns UI apps to them and BG tasks to the Ice cores (economy).

The system can now enable / disable JIT on individual apps which is what you see here on this mandelbrot app at 5 FPS without  JIT and 59 FPS (at 300x300) with it.

Someone just brought to my attention that using Teal would solve a lot of the issues that basing #atomique on Lua brought. Notably the lack of types.  So  I will definitely add support for it soon.

I had read about teal in the past actually but it was at a time when I didn't have any particular interest in Lua.

https://teal-language.org/