Flash editor was the magic

Indeed, Flash UI is really its strenght, the way to draw and manipulate curves, I don't think I've seen anything like it after that, although illustrating is not my trade. However, it is possible to do cool procedurally generated stuff with the drawing API, or use plain normal bitmap graphics to do things.

Adobe’s pen tool across all titles is second to none. There is so much value in just that one tool done right.

I far prefer the pen tool in Macromedia Freehand/MX, to say nothing of the other drawing modes which it offered (and which Adobe later copied).

I might still have an InDesign Subscription if Adobe had just rolled all of Freehand's capabilities into it --- instead, I keep a Windows computer for it and a stylus (despite Windows having crippled stylus functionality in Windows 10 Fall Creators Update) --- which reminds me, stylus usage in Waterfox broke again and I have to look up how to fix it (again).

This is very true.

There is Wick Editor (which I mentioned elsethread)

https://www.wickeditor.com/#/

Unfortunately, it's been abandoned for a while now.

There are some forks of it that seem more recent:

1. Candlestick https://github.com/Candlestickers/Candlestick

2. StickmanRed’s Fork https://github.com/StickmanRed/wick-editor

3. This brand new fork: https://forum.wickeditor.com/t/started-my-own-fork-luke-tool...

That is unfortunate.

Other similar projects?

Another reason for me to knuckle down and write my own (programmable) drawing program....

yeah, definitely gonna participate in NG's flash forward

Weird coincident.. last I week I installed "Flash MX 2004" in linux using wine. Works flawlessly! Gonna make some cool shit for "newgrounds flash forward 2026"

Context: Flash Forward is a yearly game jam on Newgrounds, where all the games are made in Flash. (They work in all browsers without flashplayer now thanks to Ruffle.)

This year's jam just started:

https://www.newgrounds.com/bbs/topic/1554561/1

Will TS v7 only support erasable syntax? e.g. no enums?

TS v5.8 added the --erasableSyntaxOnly option, along with Node.js 23.6 so you can run your TS in Node, which will error on enums (as well as namespaces and other syntax). I haven't found anything that mentions the deprecation of enums when searching, TS v6 is supposed to be as feature compatible with v7 as possible, and since enums are not a type-level feature of JS I wouldn't rely on them.

Right now you can make use of the --erasableSyntaxOnly to find any enums in your code, and start porting over to an alternative. This article lists alternatives if you're interested.

https://exploringjs.com/tackling-ts/ch_enum-alternatives.htm...

I am getting proper error feedback,

``` swift_hello_main + 322 in swift-hello at /home/fermi/Documents/temp/swift-hello/Sources/main.swift:64:8

    62│
    63│ let a = [1]
    64│ print(a[1])
      │        ▲
    65│

```

The whole FlatBuffers toolchain is wildly immature compared to Protobuf. Last I checked, flatc doesn’t even have a plugin system - all code generators had to be upstreamed into the compiler itself.

Isn't protoc mostly the same? I mean I know the code generators are separate binaries (which is quite annoying frankly) but protoc needs to know of them all upstream to expose options like --go_out and --go_opt, right?

No, that's not the case - there's a standard to how protoc exposes plugin options as CLI options that doesn't require the compiler to know about each plugin. It's obtuse, annoying, and badly documented, but it's there :)

The whole situation is extra confusing because some of the core codegen plugins are built into protoc. That's a distribution and version-matching strategy from the Google team rather than a requirement of the plugin system. I'd very much like Google to ship the built-in plugins as standalone binaries, even if they're also bundled with protoc.

I'm not sure. We have a few private plugins at work and they work fine with regular protoc. I think the --go_out and friends are automatically created by the plugins. Something like, they declare themselves as "toto" and to protoc now has a --toto_out option.

I see, interesting!

If you work with both the ergonomic advantages of protobufs become quickly apparent - starting the first time you nest things a few times. Unless you are very very frequently not going to deserialize your entire messages and so can get huge benefits from the better selective-deser of only what a given consumer cares about at a certain time, I find using flatbuffers hard to justify.

Which binary data representation? If I'm sending a Java object, do you think a C program will be able to just use it? Or for that matter, do you think two different C++ implementations, maybe on different platforms, will use the same binary representation of a class object?

just need an standard for that

Java has a standard, each C implementation has a standard, Python has a standard, etc.

The problem is that each of these standards is different, and impossible to modify.

So, we need something that can serialize one standard to a wire format, and then deserialize from that wire format to another standard.

Oh wait...

so we cant create a standard that can eliminate serde part????

I'm assuming you may be trolling me, but no, that can't realistically be done.

seems like skill issue to me

cap'n proto does IIUC