#thingumbrella — Public Fediverse posts

I somehow missed that the Go-rewrite of #TypeScript (v7.0.2) with supposedly 10x performance already had been released two weeks ago[1]. Of course, I immediately had to try it out with https://thi.ng/umbrella and see how this impacts build times. tl;dr It's very impressive and congrats to the team who pulled it off!

For context, the current #ThingUmbrella codebase contains 328k lines of TypeScript source code, of which 218k lines are actual code, 87k lines comments, the rest blanks. There're 216 packages (aka individual libraries) and 188 example projects to demonstrate their usage.

TS v6 build times:

• from scratch (packages only): 5m 44s
• rebuild (packages only): 2m 18s
• examples: 1m 18s

TS v7 build times:

• from scratch (packages only): 1m 50s
• rebuild (packages only): 29s 166ms
• examples: 56s 193ms

This is really cool and means a 3-5x speed up for (re)building all packages. The difference for example projects is much smaller, since there most of the time there is consumed by Vite (TypeScript is only used for type checking prior to building).

Currently (for TS6), my package build steps are actually using esbuild for code generation and here tsc is also only used for type checking and outputting type declaration files. This was done because esbuild is much faster (even in incremental mode). But with the TS7 speedups, I don't need this extra build tool anymore...

Notice for users: I've not yet officially switched to TS7, but will do so in the near future. I'm also grateful that there were only minor code changes (and fair ones) required for switching to the new version. For example, TS7 is catching obsolete generics, which previous versions didn't complain about...

Actually very happy about this new release (usually more of a dread)!

[1] https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

#ThingUmbrella #Build #Performance #Benchmark

I somehow missed that the Go-rewrite of #TypeScript (v7.0.2) with supposedly 10x performance already had been released two weeks ago[1]. Of course, I immediately had to try it out with https://thi.ng/umbrella and see how this impacts build times. tl;dr It's very impressive and congrats to the team who pulled it off!

For context, the current #ThingUmbrella codebase contains 328k lines of TypeScript source code, of which 218k lines are actual code, 87k lines comments, the rest blanks. There're 216 packages (aka individual libraries) and 188 example projects to demonstrate their usage.

TS v6 build times:

• from scratch (packages only): 5m 44s
• rebuild (packages only): 2m 18s
• examples: 1m 18s

TS v7 build times:

• from scratch (packages only): 1m 50s
• rebuild (packages only): 29s 166ms
• examples: 56s 193ms

This is really cool and means a 3-5x speed up for (re)building all packages. The difference for example projects is much smaller, since there most of the time there is consumed by Vite (TypeScript is only used for type checking prior to building).

Currently (for TS6), my package build steps are actually using esbuild for code generation and here tsc is also only used for type checking and outputting type declaration files. This was done because esbuild is much faster (even in incremental mode). But with the TS7 speedups, I don't need this extra build tool anymore...

Notice for users: I've not yet officially switched to TS7, but will do so in the near future. I'm also grateful that there were only minor code changes (and fair ones) required for switching to the new version. For example, TS7 is catching obsolete generics, which previous versions didn't complain about...

Actually very happy about this new release (usually more of a dread)!

[1] https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

#ThingUmbrella #Build #Performance #Benchmark

I somehow missed that the Go-rewrite of #TypeScript (v7.0.2) with supposedly 10x performance already had been released two weeks ago[1]. Of course, I immediately had to try it out with https://thi.ng/umbrella and see how this impacts build times. tl;dr It's very impressive and congrats to the team who pulled it off!

For context, the current #ThingUmbrella codebase contains 328k lines of TypeScript source code, of which 218k lines are actual code, 87k lines comments, the rest blanks. There're 216 packages (aka individual libraries) and 188 example projects to demonstrate their usage.

TS v6 build times:

• from scratch (packages only): 5m 44s
• rebuild (packages only): 2m 18s
• examples: 1m 18s

TS v7 build times:

• from scratch (packages only): 1m 50s
• rebuild (packages only): 29s 166ms
• examples: 56s 193ms

This is really cool and means a 3-5x speed up for (re)building all packages. The difference for example projects is much smaller, since there most of the time there is consumed by Vite (TypeScript is only used for type checking prior to building).

Currently (for TS6), my package build steps are actually using esbuild for code generation and here tsc is also only used for type checking and outputting type declaration files. This was done because esbuild is much faster (even in incremental mode). But with the TS7 speedups, I don't need this extra build tool anymore...

Notice for users: I've not yet officially switched to TS7, but will do so in the near future. I'm also grateful that there were only minor code changes (and fair ones) required for switching to the new version. For example, TS7 is catching obsolete generics, which previous versions didn't complain about...

Actually very happy about this new release (usually more of a dread)!

[1] https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

#ThingUmbrella #Build #Performance #Benchmark

I somehow missed that the Go-rewrite of #TypeScript (v7.0.2) with supposedly 10x performance already had been released two weeks ago[1]. Of course, I immediately had to try it out with https://thi.ng/umbrella and see how this impacts build times. tl;dr It's very impressive and congrats to the team who pulled it off!

For context, the current #ThingUmbrella codebase contains 328k lines of TypeScript source code, of which 218k lines are actual code, 87k lines comments, the rest blanks. There're 216 packages (aka individual libraries) and 188 example projects to demonstrate their usage.

TS v6 build times:

• from scratch (packages only): 5m 44s
• rebuild (packages only): 2m 18s
• examples: 1m 18s

TS v7 build times:

• from scratch (packages only): 1m 50s
• rebuild (packages only): 29s 166ms
• examples: 56s 193ms

This is really cool and means a 3-5x speed up for (re)building all packages. The difference for example projects is much smaller, since there most of the time there is consumed by Vite (TypeScript is only used for type checking prior to building).

Currently (for TS6), my package build steps are actually using esbuild for code generation and here tsc is also only used for type checking and outputting type declaration files. This was done because esbuild is much faster (even in incremental mode). But with the TS7 speedups, I don't need this extra build tool anymore...

Notice for users: I've not yet officially switched to TS7, but will do so in the near future. I'm also grateful that there were only minor code changes (and fair ones) required for switching to the new version. For example, TS7 is catching obsolete generics, which previous versions didn't complain about...

Actually very happy about this new release (usually more of a dread)!

[1] https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

#ThingUmbrella #Build #Performance #Benchmark

I somehow missed that the Go-rewrite of #TypeScript (v7.0.2) with supposedly 10x performance already had been released two weeks ago[1]. Of course, I immediately had to try it out with https://thi.ng/umbrella and see how this impacts build times. tl;dr It's very impressive and congrats to the team who pulled it off!

For context, the current #ThingUmbrella codebase contains 328k lines of TypeScript source code, of which 218k lines are actual code, 87k lines comments, the rest blanks. There're 216 packages (aka individual libraries) and 188 example projects to demonstrate their usage.

TS v6 build times:

• from scratch (packages only): 5m 44s
• rebuild (packages only): 2m 18s
• examples: 1m 18s

TS v7 build times:

• from scratch (packages only): 1m 50s
• rebuild (packages only): 29s 166ms
• examples: 56s 193ms

This is really cool and means a 3-5x speed up for (re)building all packages. The difference for example projects is much smaller, since there most of the time there is consumed by Vite (TypeScript is only used for type checking prior to building).

Currently (for TS6), my package build steps are actually using esbuild for code generation and here tsc is also only used for type checking and outputting type declaration files. This was done because esbuild is much faster (even in incremental mode). But with the TS7 speedups, I don't need this extra build tool anymore...

Notice for users: I've not yet officially switched to TS7, but will do so in the near future. I'm also grateful that there were only minor code changes (and fair ones) required for switching to the new version. For example, TS7 is catching obsolete generics, which previous versions didn't complain about...

Actually very happy about this new release (usually more of a dread)!

[1] https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

#ThingUmbrella #Build #Performance #Benchmark

With Firefox 153 officially supporting WebAssembly.promising and its counterpart WebAssembly.Suspending[1], I've updated https://thi.ng/wasm-api to simplify the integration of hybrid JS/WASM async function calls, so you don't have to worry about manually creating these wrappers:

• JavaScript async functions declared in a module's WASM imports will be auto-wrapped using WebAssembly.Suspending
• WASM exports declared/listed via WasmModuleOpts.asyncExports will be auto-wrapped using WebAssembly.promising

However, since that WASM feature isn't yet supported by Safari (no surprise there) and various mobile browsers, it's best to check for and selectively limit features relying on this mechanism...

Happy coding! :)

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/153

#ReleaseAnnouncement #ThingUmbrella #OpenSource #WASM #WebAssembly #TypeScript #JavaScript #Async

With Firefox 153 officially supporting WebAssembly.promising and its counterpart WebAssembly.Suspending[1], I've updated https://thi.ng/wasm-api to simplify the integration of hybrid JS/WASM async function calls, so you don't have to worry about manually creating these wrappers:

• JavaScript async functions declared in a module's WASM imports will be auto-wrapped using WebAssembly.Suspending
• WASM exports declared/listed via WasmModuleOpts.asyncExports will be auto-wrapped using WebAssembly.promising

However, since that WASM feature isn't yet supported by Safari (no surprise there) and various mobile browsers, it's best to check for and selectively limit features relying on this mechanism...

Happy coding! :)

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/153

#ReleaseAnnouncement #ThingUmbrella #OpenSource #WASM #WebAssembly #TypeScript #JavaScript #Async

With Firefox 153 officially supporting WebAssembly.promising and its counterpart WebAssembly.Suspending[1], I've updated https://thi.ng/wasm-api to simplify the integration of hybrid JS/WASM async function calls, so you don't have to worry about manually creating these wrappers:

• JavaScript async functions declared in a module's WASM imports will be auto-wrapped using WebAssembly.Suspending
• WASM exports declared/listed via WasmModuleOpts.asyncExports will be auto-wrapped using WebAssembly.promising

However, since that WASM feature isn't yet supported by Safari (no surprise there) and various mobile browsers, it's best to check for and selectively limit features relying on this mechanism...

Happy coding! :)

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/153

#ReleaseAnnouncement #ThingUmbrella #OpenSource #WASM #WebAssembly #TypeScript #JavaScript #Async

With Firefox 153 officially supporting WebAssembly.promising and its counterpart WebAssembly.Suspending[1], I've updated https://thi.ng/wasm-api to simplify the integration of hybrid JS/WASM async function calls, so you don't have to worry about manually creating these wrappers:

• JavaScript async functions declared in a module's WASM imports will be auto-wrapped using WebAssembly.Suspending
• WASM exports declared/listed via WasmModuleOpts.asyncExports will be auto-wrapped using WebAssembly.promising

However, since that WASM feature isn't yet supported by Safari (no surprise there) and various mobile browsers, it's best to check for and selectively limit features relying on this mechanism...

Happy coding! :)

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/153

#ReleaseAnnouncement #ThingUmbrella #OpenSource #WASM #WebAssembly #TypeScript #JavaScript #Async

With Firefox 153 officially supporting WebAssembly.promising and its counterpart WebAssembly.Suspending[1], I've updated https://thi.ng/wasm-api to simplify the integration of hybrid JS/WASM async function calls, so you don't have to worry about manually creating these wrappers:

• JavaScript async functions declared in a module's WASM imports will be auto-wrapped using WebAssembly.Suspending
• WASM exports declared/listed via WasmModuleOpts.asyncExports will be auto-wrapped using WebAssembly.promising

However, since that WASM feature isn't yet supported by Safari (no surprise there) and various mobile browsers, it's best to check for and selectively limit features relying on this mechanism...

Happy coding! :)

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/153

#ReleaseAnnouncement #ThingUmbrella #OpenSource #WASM #WebAssembly #TypeScript #JavaScript #Async

Another #ThingUmbrella release cycle this AM:

• fixed yesterday's https://thi.ng/geom-io-obj stream parser update to also support #Safari (aka the modern IE6-like browser problem child), which in the release notes for Safari v26.4 claims[1] that ReadableStream can (finally) be iterated via for await(...) syntax, but then turns out it's still only planned for v27 [2]... 🙄
• added async versions of all timing & benchmarking functions in https://thi.ng/bench to support benchmarking async functions

[1] https://webkit.org/blog/17862/webkit-features-for-safari-26-4/#web-api
[2] https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream#browser_compatibility

#OpenSource #ReleaseDay #TypeScript #JavaScript #Async

Another #ThingUmbrella release cycle this AM:

• fixed yesterday's https://thi.ng/geom-io-obj stream parser update to also support #Safari (aka the modern IE6-like browser problem child), which in the release notes for Safari v26.4 claims[1] that ReadableStream can (finally) be iterated via for await(...) syntax, but then turns out it's still only planned for v27 [2]... 🙄
• added async versions of all timing & benchmarking functions in https://thi.ng/bench to support benchmarking async functions

[1] https://webkit.org/blog/17862/webkit-features-for-safari-26-4/#web-api
[2] https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream#browser_compatibility

#OpenSource #ReleaseDay #TypeScript #JavaScript #Async

Another #ThingUmbrella release cycle this AM:

• fixed yesterday's https://thi.ng/geom-io-obj stream parser update to also support #Safari (aka the modern IE6-like browser problem child), which in the release notes for Safari v26.4 claims[1] that ReadableStream can (finally) be iterated via for await(...) syntax, but then turns out it's still only planned for v27 [2]... 🙄
• added async versions of all timing & benchmarking functions in https://thi.ng/bench to support benchmarking async functions

[1] https://webkit.org/blog/17862/webkit-features-for-safari-26-4/#web-api
[2] https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream#browser_compatibility

#OpenSource #ReleaseDay #TypeScript #JavaScript #Async

Another #ThingUmbrella release cycle this AM:

• fixed yesterday's https://thi.ng/geom-io-obj stream parser update to also support #Safari (aka the modern IE6-like browser problem child), which in the release notes for Safari v26.4 claims[1] that ReadableStream can (finally) be iterated via for await(...) syntax, but then turns out it's still only planned for v27 [2]... 🙄
• added async versions of all timing & benchmarking functions in https://thi.ng/bench to support benchmarking async functions

[1] https://webkit.org/blog/17862/webkit-features-for-safari-26-4/#web-api
[2] https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream#browser_compatibility

#OpenSource #ReleaseDay #TypeScript #JavaScript #Async

Another #ThingUmbrella release cycle this AM:

• fixed yesterday's https://thi.ng/geom-io-obj stream parser update to also support #Safari (aka the modern IE6-like browser problem child), which in the release notes for Safari v26.4 claims[1] that ReadableStream can (finally) be iterated via for await(...) syntax, but then turns out it's still only planned for v27 [2]... 🙄
• added async versions of all timing & benchmarking functions in https://thi.ng/bench to support benchmarking async functions

[1] https://webkit.org/blog/17862/webkit-features-for-safari-26-4/#web-api
[2] https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream#browser_compatibility

#OpenSource #ReleaseDay #TypeScript #JavaScript #Async

New #ThingUmbrella release(s): Updated the https://thi.ng/geom-io-obj OBJ mesh parser to support stream parsing using async iterables. This allows direct piping fetch() responses to the parser.

const response = await fetch(MODEL_URL);
const objModel = await parseOBJFromStream(response.body);

Also polished and published a related small example project for it (incl. arcball camera controller, which had an update too):

Demo (Click & drag to rotate view, touchpad/mousewheel to zoom):
https://demo.thi.ng/umbrella/webgl-obj/

Source:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/webgl-obj/src/index.ts

Alternatively to stream parsing, there's also a generator/co-routine based version. This can be used standalone or together with https://thi.ng/fibers to better control the time slicing behavior when parsing large model files (tens or hundreds of MB) and so gives fine-grained control to avoid blocking the main UI thread:

import { timeSlice } from "@thi.ng/fibers";

const response = await fetch(MODEL_URL);
const src = await response.text();
// parse in 10 millisecond time slices
const model = await timeSlice(parseOBJGenerator(src), 10).run().promise();

More background info & discussion for those interested:
https://codeberg.org/thi.ng/umbrella/pulls/405

#OpenSource #Stream #Mesh #OBJ #WebGL #TypeScript #JavaScript

New #ThingUmbrella release(s): Updated the https://thi.ng/geom-io-obj OBJ mesh parser to support stream parsing using async iterables. This allows direct piping fetch() responses to the parser.

const response = await fetch(MODEL_URL);
const objModel = await parseOBJFromStream(response.body);

Also polished and published a related small example project for it (incl. arcball camera controller, which had an update too):

Demo (Click & drag to rotate view, touchpad/mousewheel to zoom):
https://demo.thi.ng/umbrella/webgl-obj/

Source:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/webgl-obj/src/index.ts

Alternatively to stream parsing, there's also a generator/co-routine based version. This can be used standalone or together with https://thi.ng/fibers to better control the time slicing behavior when parsing large model files (tens or hundreds of MB) and so gives fine-grained control to avoid blocking the main UI thread:

import { timeSlice } from "@thi.ng/fibers";

const response = await fetch(MODEL_URL);
const src = await response.text();
// parse in 10 millisecond time slices
const model = await timeSlice(parseOBJGenerator(src), 10).run().promise();

More background info & discussion for those interested:
https://codeberg.org/thi.ng/umbrella/pulls/405

#OpenSource #Stream #Mesh #OBJ #WebGL #TypeScript #JavaScript

New #ThingUmbrella release(s): Updated the https://thi.ng/geom-io-obj OBJ mesh parser to support stream parsing using async iterables. This allows direct piping fetch() responses to the parser.

const response = await fetch(MODEL_URL);
const objModel = await parseOBJFromStream(response.body);

Also polished and published a related small example project for it (incl. arcball camera controller, which had an update too):

Demo (Click & drag to rotate view, touchpad/mousewheel to zoom):
https://demo.thi.ng/umbrella/webgl-obj/

Source:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/webgl-obj/src/index.ts

Alternatively to stream parsing, there's also a generator/co-routine based version. This can be used standalone or together with https://thi.ng/fibers to better control the time slicing behavior when parsing large model files (tens or hundreds of MB) and so gives fine-grained control to avoid blocking the main UI thread:

import { timeSlice } from "@thi.ng/fibers";

const response = await fetch(MODEL_URL);
const src = await response.text();
// parse in 10 millisecond time slices
const model = await timeSlice(parseOBJGenerator(src), 10).run().promise();

More background info & discussion for those interested:
https://codeberg.org/thi.ng/umbrella/pulls/405

#OpenSource #Stream #Mesh #OBJ #WebGL #TypeScript #JavaScript

New #ThingUmbrella release(s): Updated the https://thi.ng/geom-io-obj OBJ mesh parser to support stream parsing using async iterables. This allows direct piping fetch() responses to the parser.

const response = await fetch(MODEL_URL);
const objModel = await parseOBJFromStream(response.body);

Also polished and published a related small example project for it (incl. arcball camera controller, which had an update too):

Demo (Click & drag to rotate view, touchpad/mousewheel to zoom):
https://demo.thi.ng/umbrella/webgl-obj/

Source:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/webgl-obj/src/index.ts

Alternatively to stream parsing, there's also a generator/co-routine based version. This can be used standalone or together with https://thi.ng/fibers to better control the time slicing behavior when parsing large model files (tens or hundreds of MB) and so gives fine-grained control to avoid blocking the main UI thread:

import { timeSlice } from "@thi.ng/fibers";

const response = await fetch(MODEL_URL);
const src = await response.text();
// parse in 10 millisecond time slices
const model = await timeSlice(parseOBJGenerator(src), 10).run().promise();

More background info & discussion for those interested:
https://codeberg.org/thi.ng/umbrella/pulls/405

#OpenSource #Stream #Mesh #OBJ #WebGL #TypeScript #JavaScript

New #ThingUmbrella release(s): Updated the https://thi.ng/geom-io-obj OBJ mesh parser to support stream parsing using async iterables. This allows direct piping fetch() responses to the parser.

const response = await fetch(MODEL_URL);
const objModel = await parseOBJFromStream(response.body);

Also polished and published a related small example project for it (incl. arcball camera controller, which had an update too):

Demo (Click & drag to rotate view, touchpad/mousewheel to zoom):
https://demo.thi.ng/umbrella/webgl-obj/

Source:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/webgl-obj/src/index.ts

Alternatively to stream parsing, there's also a generator/co-routine based version. This can be used standalone or together with https://thi.ng/fibers to better control the time slicing behavior when parsing large model files (tens or hundreds of MB) and so gives fine-grained control to avoid blocking the main UI thread:

import { timeSlice } from "@thi.ng/fibers";

const response = await fetch(MODEL_URL);
const src = await response.text();
// parse in 10 millisecond time slices
const model = await timeSlice(parseOBJGenerator(src), 10).run().promise();

More background info & discussion for those interested:
https://codeberg.org/thi.ng/umbrella/pulls/405

#OpenSource #Stream #Mesh #OBJ #WebGL #TypeScript #JavaScript

Some weeks ago I got a cheap and fast TTArtisan 50mm/f1.2 prime lens to take better indoor pictures and close ups. Since it's fixed length and manual focus only, it's a very different kind of taking pictures, selecting/framing motifs, and often feels like a throwback to my first camera in the 1980s. I love it!

Since the lens has quite noticeable vignetting, I found it interesting how that effect is showing up as curve in the image waveform...

You can visualize your own images here:
https://demo.thi.ng/umbrella/pixel-waveform/

#TTArtisan #ThingUmbrella #DataViz #Photography

Some weeks ago I got a cheap and fast TTArtisan 50mm/f1.2 prime lens to take better indoor pictures and close ups. Since it's fixed length and manual focus only, it's a very different kind of taking pictures, selecting/framing motifs, and often feels like a throwback to my first camera in the 1980s. I love it!

Since the lens has quite noticeable vignetting, I found it interesting how that effect is showing up as curve in the image waveform...

You can visualize your own images here:
https://demo.thi.ng/umbrella/pixel-waveform/

#TTArtisan #ThingUmbrella #DataViz #Photography

Remembering dear Roman Verostko, who died this month two years ago, aged 94. An highly influential figure, not just for algorithmic art in general, but also for younger me personally, after meeting him during a panel discussion at the Victoria & Albert Museum in London and then corresponding for several years after...

Living as a monk and ordained priest in the 1950/60s, he absolutely cherished his limited computer time which he had first access to as student. The more he learned about automata, automatic drawing, algorithms, rule-based methods, natural processes etc. the more his belief in religion (vs. spirituality) and in an omniscient creator was fundamentally challenged, causing years of deep internal turmoil and eventually leading him to leave the monastery to lead a secular life dedicated to making art as means to finding/reconciling answers.

Even though both of our lives (and works) couldn't have been more different, we quickly found a kindred spirit and shared an awe of nature as primary source of inspiration. I'm sad we never met again in person, but his story and insights have stayed with me...

(Remembering him today as I'm sorting through older pieces of mine, and it was him who originally encouraged me to investigate more plotter-based art forms/techniques, an advice I only heeded over a decade later... 🫶)

RIP 🖤

#TextureTuesday #AlgorithmicArt #PlotterArt #PenPlotter #Axidraw #ThingUmbrella

Remembering dear Roman Verostko, who died this month two years ago, aged 94. An highly influential figure, not just for algorithmic art in general, but also for younger me personally, after meeting him during a panel discussion at the Victoria & Albert Museum in London and then corresponding for several years after...

Living as a monk and ordained priest in the 1950/60s, he absolutely cherished his limited computer time which he had first access to as student. The more he learned about automata, automatic drawing, algorithms, rule-based methods, natural processes etc. the more his belief in religion (vs. spirituality) and in an omniscient creator was fundamentally challenged, causing years of deep internal turmoil and eventually leading him to leave the monastery to lead a secular life dedicated to making art as means to finding/reconciling answers.

Even though both of our lives (and works) couldn't have been more different, we quickly found a kindred spirit and shared an awe of nature as primary source of inspiration. I'm sad we never met again in person, but his story and insights have stayed with me...

(Remembering him today as I'm sorting through older pieces of mine, and it was him who originally encouraged me to investigate more plotter-based art forms/techniques, an advice I only heeded over a decade later... 🫶)

RIP 🖤

#TextureTuesday #AlgorithmicArt #PlotterArt #PenPlotter #Axidraw #ThingUmbrella

Remembering dear Roman Verostko, who died this month two years ago, aged 94. An highly influential figure, not just for algorithmic art in general, but also for younger me personally, after meeting him during a panel discussion at the Victoria & Albert Museum in London and then corresponding for several years after...

Living as a monk and ordained priest in the 1950/60s, he absolutely cherished his limited computer time which he had first access to as student. The more he learned about automata, automatic drawing, algorithms, rule-based methods, natural processes etc. the more his belief in religion (vs. spirituality) and in an omniscient creator was fundamentally challenged, causing years of deep internal turmoil and eventually leading him to leave the monastery to lead a secular life dedicated to making art as means to finding/reconciling answers.

Even though both of our lives (and works) couldn't have been more different, we quickly found a kindred spirit and shared an awe of nature as primary source of inspiration. I'm sad we never met again in person, but his story and insights have stayed with me...

(Remembering him today as I'm sorting through older pieces of mine, and it was him who originally encouraged me to investigate more plotter-based art forms/techniques, an advice I only heeded over a decade later... 🫶)

RIP 🖤

#TextureTuesday #AlgorithmicArt #PlotterArt #PenPlotter #Axidraw #ThingUmbrella

Remembering dear Roman Verostko, who died this month two years ago, aged 94. An highly influential figure, not just for algorithmic art in general, but also for younger me personally, after meeting him during a panel discussion at the Victoria & Albert Museum in London and then corresponding for several years after...

Living as a monk and ordained priest in the 1950/60s, he absolutely cherished his limited computer time which he had first access to as student. The more he learned about automata, automatic drawing, algorithms, rule-based methods, natural processes etc. the more his belief in religion (vs. spirituality) and in an omniscient creator was fundamentally challenged, causing years of deep internal turmoil and eventually leading him to leave the monastery to lead a secular life dedicated to making art as means to finding/reconciling answers.

Even though both of our lives (and works) couldn't have been more different, we quickly found a kindred spirit and shared an awe of nature as primary source of inspiration. I'm sad we never met again in person, but his story and insights have stayed with me...

(Remembering him today as I'm sorting through older pieces of mine, and it was him who originally encouraged me to investigate more plotter-based art forms/techniques, an advice I only heeded over a decade later... 🫶)

RIP 🖤

#TextureTuesday #AlgorithmicArt #PlotterArt #PenPlotter #Axidraw #ThingUmbrella

Remembering dear Roman Verostko, who died this month two years ago, aged 94. An highly influential figure, not just for algorithmic art in general, but also for younger me personally, after meeting him during a panel discussion at the Victoria & Albert Museum in London and then corresponding for several years after...

Living as a monk and ordained priest in the 1950/60s, he absolutely cherished his limited computer time which he had first access to as student. The more he learned about automata, automatic drawing, algorithms, rule-based methods, natural processes etc. the more his belief in religion (vs. spirituality) and in an omniscient creator was fundamentally challenged, causing years of deep internal turmoil and eventually leading him to leave the monastery to lead a secular life dedicated to making art as means to finding/reconciling answers.

Even though both of our lives (and works) couldn't have been more different, we quickly found a kindred spirit and shared an awe of nature as primary source of inspiration. I'm sad we never met again in person, but his story and insights have stayed with me...

(Remembering him today as I'm sorting through older pieces of mine, and it was him who originally encouraged me to investigate more plotter-based art forms/techniques, an advice I only heeded over a decade later... 🫶)

RIP 🖤

#TextureTuesday #AlgorithmicArt #PlotterArt #PenPlotter #Axidraw #ThingUmbrella

Since it seems to come up every single time thi.ng is mentioned on HN or Reddit: Here's another partial clarification why and when the transition from originally mostly Clojure/ClojureScript to mostly TypeScript occurred:

https://news.ycombinator.com/item?id=48468029

It's not a comprehensive answer, but thi.ng always was a polyglot project. There're also parts written in (and for):

• OpenCL interop (e.g. https://thi.ng/raymarchcl, https://thi.ng/simplecl)
• GLSL (e.g. https://thi.ng/shader-ast)
• C11 (https://github.com/thi-ng/c-thing, https://thi.ng/synstack)
• Zig (https://github.com/thi-ng/zig-thing, https://thi.ng/wasm-api)
• Forth (https://thi.ng/charlie)

There are infrastructure packages to simplify creation of ad hoc DSLs, their transpilation or interpretation, but also interop with WASM (so far mostly geared towards & tested with Zig), for example:

• https://thi.ng/parse
• https://thi.ng/pointfree
• https://thi.ng/lispy
• https://thi.ng/sexpr

In general, thi.ng projects range from super high level computational design concepts to low-level primitives like memory allocators and memory/data layout management (e.g. http://thi.ng/tinyalloc, https://thi.ng/malloc, https://thi.ng/simd, https://thi.ng/soa) and a huge spectrum of other things in between...

#ThingUmbrella

Since it seems to come up every single time thi.ng is mentioned on HN or Reddit: Here's another partial clarification why and when the transition from originally mostly Clojure/ClojureScript to mostly TypeScript occurred:

https://news.ycombinator.com/item?id=48468029

It's not a comprehensive answer, but thi.ng always was a polyglot project. There're also parts written in (and for):

• OpenCL interop (e.g. https://thi.ng/raymarchcl, https://thi.ng/simplecl)
• GLSL (e.g. https://thi.ng/shader-ast)
• C11 (https://github.com/thi-ng/c-thing, https://thi.ng/synstack)
• Zig (https://github.com/thi-ng/zig-thing, https://thi.ng/wasm-api)
• Forth (https://thi.ng/charlie)

There are infrastructure packages to simplify creation of ad hoc DSLs, their transpilation or interpretation, but also interop with WASM (so far mostly geared towards & tested with Zig), for example:

• https://thi.ng/parse
• https://thi.ng/pointfree
• https://thi.ng/lispy
• https://thi.ng/sexpr

In general, thi.ng projects range from super high level computational design concepts to low-level primitives like memory allocators and memory/data layout management (e.g. http://thi.ng/tinyalloc, https://thi.ng/malloc, https://thi.ng/simd, https://thi.ng/soa) and a huge spectrum of other things in between...

#ThingUmbrella

Three years ago, I was busy finishing Marblemania, an endless algorithmic/generative realtime animation piece inspired by marbling, using softbody physics (but no actual fluid sim) and with thousands of variations and stylistic options...

This video shows stills of a small sampling of these variations.

More variations here (and in the #Marblemania hashtag):

https://mastodon.thi.ng/@toxi/110688682293173253
https://mastodon.thi.ng/@toxi/110667570347783712

#TextureTuesday #Marblemania #AlgorithmicArt #GenerativeArt #Art #Marbling #Animation #ThingUmbrella

@eniko @TomF @Moosader If you want to go even more meta, here's the repo for a workshop I ran with design students at Augsburg uni a few years ago to build a TIC-80 inspired fantasy console ourselves:

https://github.com/thi-ng/fantasy-console/

Written in TypeScript, includes custom DSL, runs in the browser, includes six demos (incl. bitmap font editor). More details in readme

#FantasyConsole #Workshop #ThingUmbrella #TypeScript #TIC80 #RetroComputing #BitmapFont

@eniko @TomF @Moosader If you want to go even more meta, here's the repo for a workshop I ran with design students at Augsburg uni a few years ago to build a TIC-80 inspired fantasy console ourselves:

https://github.com/thi-ng/fantasy-console/

Written in TypeScript, includes custom DSL, runs in the browser, includes six demos (incl. bitmap font editor). More details in readme

#FantasyConsole #Workshop #ThingUmbrella #TypeScript #TIC80 #RetroComputing #BitmapFont

Just installed the latest Zig master branch to check how much breakage (if any) the upcoming v0.17.0 release will cause in https://thi.ng/umbrella. Happy to report that it's only very few minor syntax changes:

• std.fmt.bufPrintZ() => std.fmt.bufPrintSentinel() (w/ manually specified sentinel)
• std.mem.Allocator.dupeZ() => std.mem.Allocator.dupeSentinel()
• @Type(.EnumLiteral) => @EnumLiteral() (dynamic type creation)

So far so good! 🤩

#Zig #ThingUmbrella

Just installed the latest Zig master branch to check how much breakage (if any) the upcoming v0.17.0 release will cause in https://thi.ng/umbrella. Happy to report that it's only very few minor syntax changes:

• std.fmt.bufPrintZ() => std.fmt.bufPrintSentinel() (w/ manually specified sentinel)
• std.mem.Allocator.dupeZ() => std.mem.Allocator.dupeSentinel()
• @Type(.EnumLiteral) => @EnumLiteral() (dynamic type creation)

So far so good! 🤩

#Zig #ThingUmbrella

#ReleaseDay The new version of https://thi.ng/geom-sdf is automatically preprocessing the vertices given for 2D polygons & polylines to remove any coincident and colinear ones (using Douglas-Peucker algorithm). This avoids some degenerate cases, but can also speed up the SDF evaluation of converted shapes in some other cases...

Thanks to @made for reporting the issue! 🙏

(To clarify: This package is for converting 2D shapes/geometries/SVG to composable SDF JavaScript/TypeScript functions, not for shader-based SDF use cases. For the latter, the https://thi.ng/shader-ast-stdlib package provides similar SDF functions/operators, for use with https://thi.ng/shader-ast and transpilation to GLSL)

Some examples:

thi.ng logo as SDF:
https://demo.thi.ng/umbrella/geom-sdf-logo/

SVG smiley deformation:
https://demo.thi.ng/umbrella/geom-sdf-path/

#ThingUmbrella #SDF #SVG #Geometry #Shapes #TypeScript #JavaScript

#ReleaseDay The new version of https://thi.ng/geom-sdf is automatically preprocessing the vertices given for 2D polygons & polylines to remove any coincident and colinear ones (using Douglas-Peucker algorithm). This avoids some degenerate cases, but can also speed up the SDF evaluation of converted shapes in some other cases...

Thanks to @made for reporting the issue! 🙏

(To clarify: This package is for converting 2D shapes/geometries/SVG to composable SDF JavaScript/TypeScript functions, not for shader-based SDF use cases. For the latter, the https://thi.ng/shader-ast-stdlib package provides similar SDF functions/operators, for use with https://thi.ng/shader-ast and transpilation to GLSL)

Some examples:

thi.ng logo as SDF:
https://demo.thi.ng/umbrella/geom-sdf-logo/

SVG smiley deformation:
https://demo.thi.ng/umbrella/geom-sdf-path/

#ThingUmbrella #SDF #SVG #Geometry #Shapes #TypeScript #JavaScript

Recently, at the library...

"Have you got their new book 'Silk switch system problem'?"
"No. Is that the sequel to 'Equiconnected nanosky oasis'?"
"What's that?"
"Oh, you've never read the 'Magnetic haze cycle' series? That's just too bad. It's full of cool ideas like the ultra-iridescent opcode sentinel, infraconnected division boundary, or even beige frontier mirror..."
"Dude!"
"Yeah, it's real porcelain ultra-peak! Absolutely life changing epoch omnicurve vision!"
"I did like 'Supraviolet ring department'..."
"Well, in that case, I'd recommend 'Macroluminous shimmer facet' instead. It's a good intro to all the abundant assembly craft."

In preparation for some name/passphrase generator and LLM-poisoning projects/tools, I updated my online procedural text editor to be able to export generator specs/recipes directly as TypeScript source code for easy integration into your own projects...

The above generator is here (the entire recipe is part of this super long URL):

https://demo.thi.ng/umbrella/procedural-text/#W25vdW5dCmFtYWxnYW0KYXJlYQphc3NlbWJseQpiYW5kCmJlYWNoCmJsYXN0CmJvdW5kYXJ5CmJ1cmVhdQpjYW1wCmNhbnlvbgpjYXJ0ZWxsCmNhc3RsZQpjaGFzbQpjaXR5CmNsb3VkCmNvYXN0CmNvZGUKY29tcGxleApjb21wb3NpdGlvbgpjb25zdHJhaW50CmNvbnN0cnVjdApjb3JuZXIKY291bnRyeQpjb3ZlcgpjcmFmdApjcnlzdGFsCmN1cnZlCmN5Y2xlCmRhdGEKZGF3bgpkZWx1c2lvbgpkZW5zaXR5CmRlcGFydG1lbnQKZGVyaXZhdGl2ZQpkZXNlcnQKZGlzYwpkaXZpc2lvbgpkb21haW4KZHJpdmUKZHVzawplZGdlCmVsaXhpcgplbXBpcmUKZXBvY2gKZXJhCmVzY2FwZQpleGNoYW5nZQpmYWNldApmYWxsCmZhbnRhc3kKZmFybQpmZWFyCmZpY3Rpb24KZmlzc3VyZQpmb2FtCmZvY3VzCmZvcmVzdApmb3JtCmZvcnRyZXNzCmZyYWN0dXJlCmZyZXF1ZW5jeQpmcm9udGllcgpnZW5lc2lzCmdsYXNzCmdsb3cKZ3JhcGgKZ3JvdW5kCmdyb3VwCmhhemUKaGVhZAppc2xhbmQKaXNsZQpqb3VybmV5CmxhbmQKbGFrZQpsYXJrCmxlYXAKbGluZQpsaW5hZ2UKbG9jYXRvcgpsb2NhdGlvbgpsb29wCm1ldGhvZAptaXJyb3IKbW9kdWxlCm1vdW50YWluCm5lYnVsYQpuZW1lc2lzCm5ldApuZXR3b3JrCm9hc2lzCm9ibGl2aW9uCm9ic2lkaWFuCm9jZWFuCm9keXNzZXkKb3Bjb2RlCm9wZXJhdGlvbgpwZWFrCnBoYXNlCnBpdGNoCnBsYW5ldApwbGF0ZWF1CnBsb3QKcG9zaXRpb24KcG90aW9uCnBvd2VyCnByb2JsZW0KcHJvdGVjdGlvbgpxdWFkcmFudApxdWVzdApyYWRpdXMKcmFpbgpyYW5nZQpyZWFsbQpyZWdpb24KcmVsYXRpdml0eQpyZXBhaXIKcmlmdApyaW5nCnJpdmVyCnJvYWQKcm9ja2V0CnNjaWVuY2UKc2VhCnNlbnRpbmVsCnNldHVwCnNoaW1tZXIKc2lsawpzaXRlCnNreQpzb25nCnNwYWNlCnN0YXRlCnN0b3JtCnN0b3J5CnN1YnN0aXR1dGUKc3Vydml2YWwKc3dhbXAKc3dlbGwKc3dpdGNoCnN5bWJpb3NpcwpzeXN0ZW0KdGVuZGVuY3kKdGVhbQp0aW1lCnRoZW9yeQp0cmFuc2Zlcgp0cmF1bWEKdmFsbGV5CnZhcG9yCnZpc2lvbgp3YWxsCndhc3RlCndlbGwKem9uZQoKW2NvbG9yXQphenVyZQpiZWlnZQpibGFjawpicm9uemUKY3lhbgplbWVyYWxkCmdvbGQKaXJpZGVzY2VudApuYXZ5Cm5vaXIKcGxhdGludW0KcHVycGxlCnRyYW5zbHVjZW50CnZpb2xldAoKW2FkamVjdGl2ZV0KPGNvbG9yPgphYnVuZGFudAphbGllbgphc2NldGljCmF0b21pYwpiYXJvcXVlCmJhc2ljCmJvcmVhbApicmlsbGlhbnQKY29sZApjb25uZWN0ZWQKY3JpdGljYWwKZGFyawpkZWVwCmRyeQplbWluZW50CmV4dGFudApmZXJhbApmbGF0CmZsb29kCmZyYWdpbGUKZnJvbnRhbApmcm96ZW4KZnJ1Z2FsCmhhcmRlbmVkCmhpZGRlbgpob3QKaHlwbm90aWMKaW52aXNpYmxlCmx1bWlub3VzCmx1bmFyCm1hZ25ldGljCm1pbmltYWwKbWlycm9yCm15c3RpYwpudWNsZWFyCm5ldXJhbApvcmdhbmljCnBvcmNlbGFpbgpwcm92aW5nCnJhZGlhbnQKcmFkaWNhbApyYXBpZApyYXJlCnJlbW90ZQpyb3VnaApydWdnZWQKc29mdApzb2xhcgpzb25pYwpzcGVjdGFjdWxhcgpzcGVjdHJhbApzeW1tZXRyaWMKdGhlcm1hbAp0aW1lc3RyZXRjaGVkCnVyYmFuCnZpc3VhbAp3ZXQKd2lsZAoKW2NvbG9ycHJlZml4XQpleHRyYQpoeXBlcgpoeXBvCmluZnJhCnN1YgpzdXBlcgpzdXByYQp1bHRyYS0KCltwcmVmaXhdCjxjb2xvcnByZWZpeD4KY28KZGUKZXF1aQptYWNybwptZXRhCm1pY3JvCm5hbm8Kb3J0aG8Kb21uaQpwb3N0LQpwcmUtCgpbcGhyYXNlXQo8bm91bj4gPG5vdW4+Cjxub3VuPiA8bm91bj4gPG5vdW4+Cjxub3VuPiA8cHJlZml4Pjxub3VuPgo8bm91bj4gPHByZWZpeD48bm91bj4gPG5vdW4+Cjxjb2xvcnByZWZpeD48Y29sb3I+IDxub3VuPgo8Y29sb3JwcmVmaXg+PGNvbG9yPiA8bm91bj4gPG5vdW4+Cjxjb2xvcj4gPHByZWZpeD48bm91bj4KPGNvbG9yPiA8cHJlZml4Pjxub3VuPiA8bm91bj4KPGNvbG9yPiA8YWRqZWN0aXZlPiA8bm91bj4KPGFkamVjdGl2ZT4gPG5vdW4+CjxwcmVmaXg+PGFkamVjdGl2ZT4gPG5vdW4+CjxwcmVmaXg+PGFkamVjdGl2ZT4gPG5vdW4+IDxub3VuPgo8cHJlZml4PjxhZGplY3RpdmU+IDxwcmVmaXg+PG5vdW4+IDxub3VuPgo8YWRqZWN0aXZlPiA8cHJlZml4Pjxub3VuPgo8YWRqZWN0aXZlPiA8bm91bj4gPG5vdW4+CjxhZGplY3RpdmU+IDxjb2xvcj4gPG5vdW4+CjxwaHJhc2U+IDxub3VuPgoKW3RpdGxlXQonPHBocmFzZTtjYXA+JwoKIyBtYWluCgoiSGF2ZSB5b3UgZ290IHRoZWlyIG5ldyBib29rIDx0aXRsZT4/IgoiTGV0IG1lIGNoZWNrLiBJcyB0aGF0IHRoZSBzZXF1ZWwgdG8gPHRpdGxlPj8iCiJXaGF0J3MgdGhhdD8iCiJPaCwgeW91J3ZlIG5ldmVyIHJlYWQgdGhlIDx0aXRsZT4gc2VyaWVzPyBUaGF0J3MganVzdCB0b28gYmFkLiBJdCdzIGZ1bGwgb2YgY29vbCBpZGVhcyBsaWtlIHRoZSA8cGhyYXNlPiwgPHBocmFzZT4sIG9yIGV2ZW4gPHBocmFzZT4uLi4iCiJEdWRlISIKIlllYWgsIGl0J3MgcmVhbCA8cGhyYXNlPiEgQWJzb2x1dGVseSBsaWZlIGNoYW5naW5nIDxwaHJhc2U+ISIKIkkgZGlkIGxpa2UgPHRpdGxlPi4uLiIKIldlbGwsIGluIHRoYXQgY2FzZSwgSSdkIHJlY29tbWVuZCA8dGl0bGU+IGluc3RlYWQuIEl0J3MgYSBnb29kIGludHJvIHRvIGFsbCB0aGUgPHBocmFzZT4uIg==

More project & syntax info here:
https://thi.ng/proctext

#Microfiction #ProcGen #ProceduralText #ThingUmbrella #DSL #TypeScript #LLMPoisoning #NoAI

Recently, at the library...

"Have you got their new book 'Silk switch system problem'?"
"No. Is that the sequel to 'Equiconnected nanosky oasis'?"
"What's that?"
"Oh, you've never read the 'Magnetic haze cycle' series? That's just too bad. It's full of cool ideas like the ultra-iridescent opcode sentinel, infraconnected division boundary, or even beige frontier mirror..."
"Dude!"
"Yeah, it's real porcelain ultra-peak! Absolutely life changing epoch omnicurve vision!"
"I did like 'Supraviolet ring department'..."
"Well, in that case, I'd recommend 'Macroluminous shimmer facet' instead. It's a good intro to all the abundant assembly craft."

In preparation for some name/passphrase generator and LLM-poisoning projects/tools, I updated my online procedural text editor to be able to export generator specs/recipes directly as TypeScript source code for easy integration into your own projects...

The above generator is here (the entire recipe is part of this super long URL):

https://demo.thi.ng/umbrella/procedural-text/#W25vdW5dCmFtYWxnYW0KYXJlYQphc3NlbWJseQpiYW5kCmJlYWNoCmJsYXN0CmJvdW5kYXJ5CmJ1cmVhdQpjYW1wCmNhbnlvbgpjYXJ0ZWxsCmNhc3RsZQpjaGFzbQpjaXR5CmNsb3VkCmNvYXN0CmNvZGUKY29tcGxleApjb21wb3NpdGlvbgpjb25zdHJhaW50CmNvbnN0cnVjdApjb3JuZXIKY291bnRyeQpjb3ZlcgpjcmFmdApjcnlzdGFsCmN1cnZlCmN5Y2xlCmRhdGEKZGF3bgpkZWx1c2lvbgpkZW5zaXR5CmRlcGFydG1lbnQKZGVyaXZhdGl2ZQpkZXNlcnQKZGlzYwpkaXZpc2lvbgpkb21haW4KZHJpdmUKZHVzawplZGdlCmVsaXhpcgplbXBpcmUKZXBvY2gKZXJhCmVzY2FwZQpleGNoYW5nZQpmYWNldApmYWxsCmZhbnRhc3kKZmFybQpmZWFyCmZpY3Rpb24KZmlzc3VyZQpmb2FtCmZvY3VzCmZvcmVzdApmb3JtCmZvcnRyZXNzCmZyYWN0dXJlCmZyZXF1ZW5jeQpmcm9udGllcgpnZW5lc2lzCmdsYXNzCmdsb3cKZ3JhcGgKZ3JvdW5kCmdyb3VwCmhhemUKaGVhZAppc2xhbmQKaXNsZQpqb3VybmV5CmxhbmQKbGFrZQpsYXJrCmxlYXAKbGluZQpsaW5hZ2UKbG9jYXRvcgpsb2NhdGlvbgpsb29wCm1ldGhvZAptaXJyb3IKbW9kdWxlCm1vdW50YWluCm5lYnVsYQpuZW1lc2lzCm5ldApuZXR3b3JrCm9hc2lzCm9ibGl2aW9uCm9ic2lkaWFuCm9jZWFuCm9keXNzZXkKb3Bjb2RlCm9wZXJhdGlvbgpwZWFrCnBoYXNlCnBpdGNoCnBsYW5ldApwbGF0ZWF1CnBsb3QKcG9zaXRpb24KcG90aW9uCnBvd2VyCnByb2JsZW0KcHJvdGVjdGlvbgpxdWFkcmFudApxdWVzdApyYWRpdXMKcmFpbgpyYW5nZQpyZWFsbQpyZWdpb24KcmVsYXRpdml0eQpyZXBhaXIKcmlmdApyaW5nCnJpdmVyCnJvYWQKcm9ja2V0CnNjaWVuY2UKc2VhCnNlbnRpbmVsCnNldHVwCnNoaW1tZXIKc2lsawpzaXRlCnNreQpzb25nCnNwYWNlCnN0YXRlCnN0b3JtCnN0b3J5CnN1YnN0aXR1dGUKc3Vydml2YWwKc3dhbXAKc3dlbGwKc3dpdGNoCnN5bWJpb3NpcwpzeXN0ZW0KdGVuZGVuY3kKdGVhbQp0aW1lCnRoZW9yeQp0cmFuc2Zlcgp0cmF1bWEKdmFsbGV5CnZhcG9yCnZpc2lvbgp3YWxsCndhc3RlCndlbGwKem9uZQoKW2NvbG9yXQphenVyZQpiZWlnZQpibGFjawpicm9uemUKY3lhbgplbWVyYWxkCmdvbGQKaXJpZGVzY2VudApuYXZ5Cm5vaXIKcGxhdGludW0KcHVycGxlCnRyYW5zbHVjZW50CnZpb2xldAoKW2FkamVjdGl2ZV0KPGNvbG9yPgphYnVuZGFudAphbGllbgphc2NldGljCmF0b21pYwpiYXJvcXVlCmJhc2ljCmJvcmVhbApicmlsbGlhbnQKY29sZApjb25uZWN0ZWQKY3JpdGljYWwKZGFyawpkZWVwCmRyeQplbWluZW50CmV4dGFudApmZXJhbApmbGF0CmZsb29kCmZyYWdpbGUKZnJvbnRhbApmcm96ZW4KZnJ1Z2FsCmhhcmRlbmVkCmhpZGRlbgpob3QKaHlwbm90aWMKaW52aXNpYmxlCmx1bWlub3VzCmx1bmFyCm1hZ25ldGljCm1pbmltYWwKbWlycm9yCm15c3RpYwpudWNsZWFyCm5ldXJhbApvcmdhbmljCnBvcmNlbGFpbgpwcm92aW5nCnJhZGlhbnQKcmFkaWNhbApyYXBpZApyYXJlCnJlbW90ZQpyb3VnaApydWdnZWQKc29mdApzb2xhcgpzb25pYwpzcGVjdGFjdWxhcgpzcGVjdHJhbApzeW1tZXRyaWMKdGhlcm1hbAp0aW1lc3RyZXRjaGVkCnVyYmFuCnZpc3VhbAp3ZXQKd2lsZAoKW2NvbG9ycHJlZml4XQpleHRyYQpoeXBlcgpoeXBvCmluZnJhCnN1YgpzdXBlcgpzdXByYQp1bHRyYS0KCltwcmVmaXhdCjxjb2xvcnByZWZpeD4KY28KZGUKZXF1aQptYWNybwptZXRhCm1pY3JvCm5hbm8Kb3J0aG8Kb21uaQpwb3N0LQpwcmUtCgpbcGhyYXNlXQo8bm91bj4gPG5vdW4+Cjxub3VuPiA8bm91bj4gPG5vdW4+Cjxub3VuPiA8cHJlZml4Pjxub3VuPgo8bm91bj4gPHByZWZpeD48bm91bj4gPG5vdW4+Cjxjb2xvcnByZWZpeD48Y29sb3I+IDxub3VuPgo8Y29sb3JwcmVmaXg+PGNvbG9yPiA8bm91bj4gPG5vdW4+Cjxjb2xvcj4gPHByZWZpeD48bm91bj4KPGNvbG9yPiA8cHJlZml4Pjxub3VuPiA8bm91bj4KPGNvbG9yPiA8YWRqZWN0aXZlPiA8bm91bj4KPGFkamVjdGl2ZT4gPG5vdW4+CjxwcmVmaXg+PGFkamVjdGl2ZT4gPG5vdW4+CjxwcmVmaXg+PGFkamVjdGl2ZT4gPG5vdW4+IDxub3VuPgo8cHJlZml4PjxhZGplY3RpdmU+IDxwcmVmaXg+PG5vdW4+IDxub3VuPgo8YWRqZWN0aXZlPiA8cHJlZml4Pjxub3VuPgo8YWRqZWN0aXZlPiA8bm91bj4gPG5vdW4+CjxhZGplY3RpdmU+IDxjb2xvcj4gPG5vdW4+CjxwaHJhc2U+IDxub3VuPgoKW3RpdGxlXQonPHBocmFzZTtjYXA+JwoKIyBtYWluCgoiSGF2ZSB5b3UgZ290IHRoZWlyIG5ldyBib29rIDx0aXRsZT4/IgoiTGV0IG1lIGNoZWNrLiBJcyB0aGF0IHRoZSBzZXF1ZWwgdG8gPHRpdGxlPj8iCiJXaGF0J3MgdGhhdD8iCiJPaCwgeW91J3ZlIG5ldmVyIHJlYWQgdGhlIDx0aXRsZT4gc2VyaWVzPyBUaGF0J3MganVzdCB0b28gYmFkLiBJdCdzIGZ1bGwgb2YgY29vbCBpZGVhcyBsaWtlIHRoZSA8cGhyYXNlPiwgPHBocmFzZT4sIG9yIGV2ZW4gPHBocmFzZT4uLi4iCiJEdWRlISIKIlllYWgsIGl0J3MgcmVhbCA8cGhyYXNlPiEgQWJzb2x1dGVseSBsaWZlIGNoYW5naW5nIDxwaHJhc2U+ISIKIkkgZGlkIGxpa2UgPHRpdGxlPi4uLiIKIldlbGwsIGluIHRoYXQgY2FzZSwgSSdkIHJlY29tbWVuZCA8dGl0bGU+IGluc3RlYWQuIEl0J3MgYSBnb29kIGludHJvIHRvIGFsbCB0aGUgPHBocmFzZT4uIg==

More project & syntax info here:
https://thi.ng/proctext

#Microfiction #ProcGen #ProceduralText #ThingUmbrella #DSL #TypeScript #LLMPoisoning #NoAI

Color Therapy. Noisy evolution.

Two snapshots of my piece C-SCAPE, 2022, a multi-organism 1.5D cellular automata simulation. Patterns of symbiosis and annihilation.

Made with https://thi.ng/cellular

#CSCAPE #CellularAutomata #GenerativeArt #AlgorithmicArt #EvolutionaryArt #Abstract #Color #Texture #ThingUmbrella #NoAI

Color Therapy. Noisy evolution.

Two snapshots of my piece C-SCAPE, 2022, a multi-organism 1.5D cellular automata simulation. Patterns of symbiosis and annihilation.

Made with https://thi.ng/cellular

#CSCAPE #CellularAutomata #GenerativeArt #AlgorithmicArt #EvolutionaryArt #Abstract #Color #Texture #ThingUmbrella #NoAI

PSA: Not that it was ambiguous beforehand, but these are times for stating things more clearly...

All #ThingUmbrella package readme files are now clearly stating that these projects are "LLM-free, human-made and cared for software, maintained as part of the https://thi.ng/umbrella ecosystem and anti-framework" 🫡

I cared for and tended this garden of hundreds of projects almost daily for close to 10 years[1] (even if the commit heatmap doesn't always show it). It's a testament to the things I've learned, built, explored and tried to share with the world, things which helped numerous people and companies (big & small) to realize their unique projects/products/services. I'm not gonna sacrifice this body of work and all this cohesion by watering/poisoning it with slopicides[2] and/or making it dependent on the great planetary token machine...

In The Handmaid's Tale, I always found the moment about "freedom from" vs "freedom to" very poignant, albeit in a different/inverted sense to how it was used there: Traditionally, Open Source licenses have granted freedoms "to" certain things, especially unconstrained uses. But if licenses still have any meaning at all (highly debatable in this climate/age), we increasingly need alternative licenses/mechanisms to also grant our creations freedoms "from" certain uses/practices/people/orgs...

[1] ...only the TypeScript/Umbrella parts counted here. Many other thi.ng projects are much older...
[2] Have I just coined a new word?!

#ThingUmbrella #OpenSource #NoAI

PSA: Not that it was ambiguous beforehand, but these are times for stating things more clearly...

All #ThingUmbrella package readme files are now clearly stating that these projects are "LLM-free, human-made and cared for software, maintained as part of the https://thi.ng/umbrella ecosystem and anti-framework" 🫡

I cared for and tended this garden of hundreds of projects almost daily for close to 10 years[1] (even if the commit heatmap doesn't always show it). It's a testament to the things I've learned, built, explored and tried to share with the world, things which helped numerous people and companies (big & small) to realize their unique projects/products/services. I'm not gonna sacrifice this body of work and all this cohesion by watering/poisoning it with slopicides[2] and/or making it dependent on the great planetary token machine...

In The Handmaid's Tale, I always found the moment about "freedom from" vs "freedom to" very poignant, albeit in a different/inverted sense to how it was used there: Traditionally, Open Source licenses have granted freedoms "to" certain things, especially unconstrained uses. But if licenses still have any meaning at all (highly debatable in this climate/age), we increasingly need alternative licenses/mechanisms to also grant our creations freedoms "from" certain uses/practices/people/orgs...

[1] ...only the TypeScript/Umbrella parts counted here. Many other thi.ng projects are much older...
[2] Have I just coined a new word?!

#ThingUmbrella #OpenSource #NoAI

#ReleaseDay https://thi.ng/column-store is an in-memory database with customizable column types, extensible query engine, bitfield indexing for query acceleration, JSON serialization with optional RLE compression.

The new version introduces support for arbitrarily nested queries and merging of sub-query results using a choice of AND (intersection/constraint), OR (union/alternative) or NAND/NOR (negated versions) semantics.

https://docs.thi.ng/umbrella/column-store/#nested-queries

Also without query nesting, each individual query term's results can be merged as union now. The previous behavior only allowed for term result intersections, with each subsequent term further narrowing the total result set. This behavior limited the types of compound queries possible and therefore required multiple separate queries and additional user effort to merge results manually. Well, no more! :)

https://docs.thi.ng/umbrella/column-store/#term-union

Another (intentional) side effect: Since queries are defined declaratively, creating complex queries is much easier (and legible) now via composition and re-use of predefined sub-queries. The support for nesting also simplifies the creation of user-defined query DSLs (domain specific languages).

As before, for columns with bitmap indexing enabled, most of the query operators are extremely fast since only bit masks need to be combined and no actual row or column data is being visited. The latter is only necessary for predicate-based matchXXX() operators...

#ThingUmbrella #OpenSource #Database #QueryEngine #TypeScript #BitField

#ReleaseDay https://thi.ng/column-store is an in-memory database with customizable column types, extensible query engine, bitfield indexing for query acceleration, JSON serialization with optional RLE compression.

The new version introduces support for arbitrarily nested queries and merging of sub-query results using a choice of AND (intersection/constraint), OR (union/alternative) or NAND/NOR (negated versions) semantics.

https://docs.thi.ng/umbrella/column-store/#nested-queries

Also without query nesting, each individual query term's results can be merged as union now. The previous behavior only allowed for term result intersections, with each subsequent term further narrowing the total result set. This behavior limited the types of compound queries possible and therefore required multiple separate queries and additional user effort to merge results manually. Well, no more! :)

https://docs.thi.ng/umbrella/column-store/#term-union

Another (intentional) side effect: Since queries are defined declaratively, creating complex queries is much easier (and legible) now via composition and re-use of predefined sub-queries. The support for nesting also simplifies the creation of user-defined query DSLs (domain specific languages).

As before, for columns with bitmap indexing enabled, most of the query operators are extremely fast since only bit masks need to be combined and no actual row or column data is being visited. The latter is only necessary for predicate-based matchXXX() operators...

#ThingUmbrella #OpenSource #Database #QueryEngine #TypeScript #BitField

#ReleaseFriday Triggered by a recent feature proposal[1], I went ahead and polished & published a closely related, already work-in-progress (but still private) feature in https://thi.ng/rdom to support something I call "bare lists"[2]. I've started working on this for another project last year, but needed to do more testing (which I think have sufficiently done by now).

These "bare" lists are managed reactive control components which attach items directly to the list's parent DOM element instead of first creating a wrapper/container element for the items and so avoid introducing additional nesting.

There're many use cases where this additional nesting was a real problem with the earlier approach, e.g. in containers with CSS grid or flex layout, tables, or generally situations where we want to have static & reactive list items as true siblings...

The new version of thi.ng/rdom is technically a breaking change (sorry!), but the actual changes required (for you) are tiny and purely limited to the $list() and $klist() component function calls, which are now accepting a parameter object instead of positional args for the different possible behaviors. Of course, lists with item wrapper elements can still be created too, just as before (but via new args).

I've updated & tested all existing examples impacted by this change and also created a new fully commented example project (example #187) to illustrate these "bare" lists in situ (check the DOM inspector to see the shallow structure and how updates are applied):

Demo:
https://demo.thi.ng/umbrella/rdom-bare-lists/

Source code:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/rdom-bare-lists/src/index.ts

[1] github.com/thi-ng/umbrella/discussions/562
[2] My use of "list" here is generic, not limited to <ul> or <ol>...

#ThingUmbrella #Reactive #UI #OpenSource #TypeScript #JavaScript #WebDev

#ReleaseFriday Triggered by a recent feature proposal[1], I went ahead and polished & published a closely related, already work-in-progress (but still private) feature in https://thi.ng/rdom to support something I call "bare lists"[2]. I've started working on this for another project last year, but needed to do more testing (which I think have sufficiently done by now).

These "bare" lists are managed reactive control components which attach items directly to the list's parent DOM element instead of first creating a wrapper/container element for the items and so avoid introducing additional nesting.

There're many use cases where this additional nesting was a real problem with the earlier approach, e.g. in containers with CSS grid or flex layout, tables, or generally situations where we want to have static & reactive list items as true siblings...

The new version of thi.ng/rdom is technically a breaking change (sorry!), but the actual changes required (for you) are tiny and purely limited to the $list() and $klist() component function calls, which are now accepting a parameter object instead of positional args for the different possible behaviors. Of course, lists with item wrapper elements can still be created too, just as before (but via new args).

I've updated & tested all existing examples impacted by this change and also created a new fully commented example project (example #187) to illustrate these "bare" lists in situ (check the DOM inspector to see the shallow structure and how updates are applied):

Demo:
https://demo.thi.ng/umbrella/rdom-bare-lists/

Source code:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/rdom-bare-lists/src/index.ts

[1] github.com/thi-ng/umbrella/discussions/562
[2] My use of "list" here is generic, not limited to <ul> or <ol>...

#ThingUmbrella #Reactive #UI #OpenSource #TypeScript #JavaScript #WebDev

#ReleaseFriday Triggered by a recent feature proposal[1], I went ahead and polished & published a closely related, already work-in-progress (but still private) feature in https://thi.ng/rdom to support something I call "bare lists"[2]. I've started working on this for another project last year, but needed to do more testing (which I think have sufficiently done by now).

These "bare" lists are managed reactive control components which attach items directly to the list's parent DOM element instead of first creating a wrapper/container element for the items and so avoid introducing additional nesting.

There're many use cases where this additional nesting was a real problem with the earlier approach, e.g. in containers with CSS grid or flex layout, tables, or generally situations where we want to have static & reactive list items as true siblings...

The new version of thi.ng/rdom is technically a breaking change (sorry!), but the actual changes required (for you) are tiny and purely limited to the $list() and $klist() component function calls, which are now accepting a parameter object instead of positional args for the different possible behaviors. Of course, lists with item wrapper elements can still be created too, just as before (but via new args).

I've updated & tested all existing examples impacted by this change and also created a new fully commented example project (example #187) to illustrate these "bare" lists in situ (check the DOM inspector to see the shallow structure and how updates are applied):

Demo:
https://demo.thi.ng/umbrella/rdom-bare-lists/

Source code:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/rdom-bare-lists/src/index.ts

[1] github.com/thi-ng/umbrella/discussions/562
[2] My use of "list" here is generic, not limited to <ul> or <ol>...

#ThingUmbrella #Reactive #UI #OpenSource #TypeScript #JavaScript #WebDev

#ReleaseFriday Triggered by a recent feature proposal[1], I went ahead and polished & published a closely related, already work-in-progress (but still private) feature in https://thi.ng/rdom to support something I call "bare lists"[2]. I've started working on this for another project last year, but needed to do more testing (which I think have sufficiently done by now).

These "bare" lists are managed reactive control components which attach items directly to the list's parent DOM element instead of first creating a wrapper/container element for the items and so avoid introducing additional nesting.

There're many use cases where this additional nesting was a real problem with the earlier approach, e.g. in containers with CSS grid or flex layout, tables, or generally situations where we want to have static & reactive list items as true siblings...

The new version of thi.ng/rdom is technically a breaking change (sorry!), but the actual changes required (for you) are tiny and purely limited to the $list() and $klist() component function calls, which are now accepting a parameter object instead of positional args for the different possible behaviors. Of course, lists with item wrapper elements can still be created too, just as before (but via new args).

I've updated & tested all existing examples impacted by this change and also created a new fully commented example project (example #187) to illustrate these "bare" lists in situ (check the DOM inspector to see the shallow structure and how updates are applied):

Demo:
https://demo.thi.ng/umbrella/rdom-bare-lists/

Source code:
https://codeberg.org/thi.ng/umbrella/src/branch/develop/examples/rdom-bare-lists/src/index.ts

[1] github.com/thi-ng/umbrella/discussions/562
[2] My use of "list" here is generic, not limited to <ul> or <ol>...

#ThingUmbrella #Reactive #UI #OpenSource #TypeScript #JavaScript #WebDev