Flash Display

[robert-mcdowell]

Flash Display

Yerr. Hm, I'm forking the source of ASC 2 (the ActionScript compiler by Adobe/Macromedia) to make a different edition of ActionScript. I won't have to parse the language, will just do some changes in its Java code and thus be able to bring AS in the web.

I'll have to plan a cooler symbol solver. I was thinking of transpilling Java to C# and use C# libraries for also doing different tasks such as doc generation (with Markdown), color-tracing to the console...

[ROBERT-MCDOWELL]

I changed the git repo name to be better found on git search, but didn't know it just deleted all discussion issues
crates.io looks good, as long as it will be better than flash.display....

[ROBERT-MCDOWELL]

I also recalled FutureFlashFramework by Foo Flash Framework.
I want to keep the work Flash to link Flash developers and user interest.
btw Flash is not copyrighted anymore since 2015

[ROBERT-MCDOWELL]

• Porting old projects to Rust might be hard since it's gradually different from ActionScript, though.
  but feasible?

I changed the git repo name to be better found on git search, but didn't know it just deleted all discussion issues

In fact It can still be found w/ is:issue is:closed. It can be re-opened, but I think some messages should be deleted. It's a bit large IMO...

crates.io looks good, as long as it will be better than flash.display....

crates.io isn't truly everything. I'm afraid you're thinking crates.io is a package (it's actually a registry). You don't use crates.io manually when building projects, but you usually have dependencies in it. I'm not sure if you're familiar with package managers (like Cargo or NPM), though.

btw Flash is not copyrighted anymore since 2015

Only ActionScript was copyrighted back in 2018 from what I heard...

Porting old projects to Rust might be hard since it's gradually different from ActionScript, though.

but feasible?

Yeah. Not much hard, but the developer is encouraged to change the code design. Existing code, if multi-threaded, can benefit in Rust avoiding mutability where desired.

[ROBERT-MCDOWELL]

first issue is always good to keep, yes I just saw it, it's ok to leave it as this.
sorry, I wanted to say gfx-rs, not crates.io

Yeah. Not much hard, but the developer is encouraged to change the code design.
ok, but for the SWF without sources it should work right?

Yes. We don't have much to do, just need to learn math and get used to low-level graphics, swapbuffers... Or use high-level graphics from Amethyst, SDL2, Idk.

There's no multi-purpose display tree implemented by anyone in Rust, still. A UDP server has been implemented by the looks: https://github.com/christian-smith/rust-udp-server.

Well, if we want port SWFs easily then it's a means of having a flash crate. It won't cost in anything in Rust.

Amethyst is for ECS (Entity Component System) patterns, so it's mostly for games. Flash is for ECS, Functional Reactive and all other graphical programming patterns.

Ohhhh, a pitty. >_<

[ROBERT-MCDOWELL]

udp server looks good, so an RTMFP protocol can for sure be created modifying this project code.
Amtthyst looks promising, but why a pitty? :\

Amtthyst looks promising, but why a pitty? :\

Since it's ECS-based, that means it's for game-purposes only. But not much to worry, I'm writting the lib. It'll allow you to cast between the sealed classes (DisplayObject, Sprite, Shape, MovieClip, TextField etc.) just like you could in AS, but you won't be able to extend them (since that mostly leads to bad code).

The cool thing is that will be usable for ECS too. It'll be usable for everything, UI, these.

objects/mod.rs

mod unit;
mod inherit;
mod disp_obj;
mod sprite;

pub use unit::*;
pub use inherit::InstanceOf;
pub use disp_obj::DisplayObject;
pub use sprite::*;

objects/disp.rs

use fladisp::*;
use std::convert::*; // AsRef, From, Into

pub struct DisplayObject {
    kind: DispObjKind,
    x: Unit,
    y: Unit,
}

// Impl InstanceOf's

udp server looks good, so an RTMFP protocol can for sure be created modifying this project code.

Hmm, we could implement a Flash equivalent into Rust, then. E.g., a flash::net module that supports it. For #[cfg(target_arch = "wasm32")] it could fail silently, panic or be unimplemented (so the developer gets a static error).

To get used to Rust you can check Rust by Example.
https://doc.rust-lang.org/stable/rust-by-example/

Well, as a ActionScript developer I've used Flash Professional/Animate or MXML directly to build projects. In fact it wasn't always direct to me (at least for MXML in the command-line). Flash Professional or AS&MXML is a bit better to use since it setups for you, but both of them are still incomplete for handling dependencies, caching etc.. The thing is, the AS environment is quite incomplete. Rust has a package manager in command-line. It's easier and more mature.

After installing Rust you can check:

https://doc.rust-lang.org/book/ch01-03-hello-cargo.html

It'll introduce it to you, even though it's, yeah, different from ActionScript. It's really light.

Ah, you do install rustup with the night channel. For now it's the one that stdweb supports. I also recommend using MinGW (GNU) as the default linker since MSVC+ is heavy to firstly download.

[ROBERT-MCDOWELL]

ok will do. We need also to think about a flexible and smart architecture.
Let's say if Rust becomes a dead project, what are the chance to switch to another environment to avoid to not loose all the work? From the past lessons we always need to adapt the future to avoid to repeat the same mistakes

@ROBERT-MCDOWELL The framework doesn't depend in many particularities of Rust. But if it's not done in Rust, then it means we'll re-duplicate a low-level system to target WebAssembly, nope?

As to the display library (which I'm now having to work in phone...), as planned, it could be adapted to ActionScript/C#/Swift sealed class inheritance. Inheritance is important since it allows cheap field access through display elements. With that you can perform collision checks with various objects more efficiently (by first capturing rectangular collisions and then exact collisions).

Rust becoming a dead project is unlikely. Very different technologies may come (quantum computing), but binary ones will continue to still be exponentially faster for gaming, animating and such. SIMD operations, for instance, are already in std. They aim to be growing.

Rust is super unlikely to die due to its transparency. When something is transparent, you've full control and confidency of what you're doing.

Swift is also kinda there, but it looks like it has reflection by what's said out. I've never rant it since I've no opportunity to that so fine. (Swift is OSX-ish, cross-arch support is still being worked.)

Rust is a snake, orochi.

[ROBERT-MCDOWELL]

• The framework doesn't depend in many particularities of Rust. But if it's not done in Rust, then it means we'll re-duplicate a low-level system to target WebAssembly, nope?
  I don't know, my question was from my ignorance. I even don't know if it's possible. What's the most long term language existing if it's not C and C++? so if Rust discontinues, does any conversion tools allow us to convert Rust language to C/C++? it's questions we need to seriously ask.
• Rust is super unlikely to die due to its transparency
  mhhm, well, I won't say the story is repeating every decade, but it's unfortunately what I see through the internet development. Everything is nice and promising when a new stuff is created and many developers use it, then boom, one day the core staff decides to stop it for various reasons. I saw that for many languages/projects/softwares, Flash included. What you said about Rust above was exactly the same words 10 years ago with Flash. So it's always better to prevent rather than loose years of work.

@ROBERT-MCDOWELL But Flash isn't transparent, that's when we include its runtime. It requires many assumptions (e.g., store all API strings in ABC constant pool and bring objects with lots of properties representing the API classes at run-time, which can then also be seen by external SWFs and thus not optimised ahead-of-time).

C, C++ and Rust are the kind of transparent languages. Ah, and Rust wasn't implemented in C++, nor there's a Rust-2-C[++] transpiler. Rust is a product of lessions taught earlier from C++ by Mozilla.

What you said about projects stopping didn't exactly occur with, say, C++.

[ROBERT-MCDOWELL]

• What you said about projects stopping didn't exactly occur with, say, C++.
  Ok so we need to know if, for the worst case scenario there is a bridge between Rust-2-C++ and C++ right?

[ROBERT-MCDOWELL]

To start such kind of big project we always need to think of all the worst scenario and negative aspects of it.

[ROBERT-MCDOWELL]

what do you think of this article?
https://hackernoon.com/why-im-dropping-rust-fd1c32986c88

[ROBERT-MCDOWELL]

and this one?
https://www.viva64.com/en/b/0324/

@ROBERT-MCDOWELL They're outdated. I've read the Hackernoon one and its main issue is inheritance. Inheritance is possible (it was my first issue, too, since I were to implement display/DOM-like objects). After having used Rust more, all needed is implementing conversion traits (From, TryFrom and AsRef), fallback traits (Deref), a custom InstanceOf trait and unsafe casts internally (Rc::from_raw(Rc::into_raw(r.clone()) as *const() as *const Out)).

I'm writting a macro class_decl! to facilitate that. Inheritance is efficient, but still the Rust folks don't get it right. They think I want delegation with traits or composition; err, I can't really communicate with them well.

Ah, they do many RFCs, but the language got better in 2018. It's really different from C++, e.g., there's no formal spec. exactly, but in the other hand the progress is fast in it.

Now, Viva64's article looks to also criticise the package manager. What? It's saying packages that depend in other packages hosted in GitHub will cause crates.io to be crazyland. In first place, a package cannot be published to crates.io when it has external dependencies; it can depend in crates.io itself, but cannot in GitHub or a local file-system. And to add, the Rust ecosystem is well aware of semvers (semantic versions), so it's quite the opposite of what this article thinks.

Overall they leak experience with Node.JS, Cargo and inheritance.

[ROBERT-MCDOWELL]

ok, indeed it in 2 years a lot of changes can happen... good luck fo class_decl!

It didn't go well. Well, still inheritance is hard in need of zero-cost Deref to the base class DisplayObject. Hmm, I'm starting to think Rust isn't a good idea, then.

Entity-Component-System isn't something I want directly; I'd rather use it in top of flash.display, thus escaping from inheritance to composition or trait delegation isn't appropriate.

N't sure, but I'm thinking a ActionScript alternative has to come later. E.g. a namespaced-language inspired by AS3. I was working in such, but since I gave up misc. times I won't be working in it any time soon. I guess we'll have to use AS3 as is, but breaking compatibility with the spec (and thus non-static indexing and run-time reflection would be broken).

[ROBERT-MCDOWELL]

I found this
https://internals.rust-lang.org/t/why-not-inheritance/5738/21
maybe it will help, if not, le'ts continue to dig in the rabbit hole

@ROBERT-MCDOWELL They've still not added a feature like fields in traits. I've done the class_decl! macro, but I couldn't implement Deref efficiently and am thus not satisfied w/ Rust. What a pitty...

Everything in Rust is good, except Rc. Lalaolohuahu

I could do something different for the standard's Rc, but why, really? Hm...

[ROBERT-MCDOWELL]

@hydroper it it helps to get inheritance.... What's the motivation of the authors of Rust to lack of it?

They look to say it's not a priority, but is really affecting the flexibility of future libs, I think so.

[ROBERT-MCDOWELL]

weird. anyhow, it stays C++ right?

Yes. C++ isn't very unsafe (compared to Rust it's unsafer), but the usual build systems (Make, CMake, Bazel and others) are very boilerplate. Wauh. No module system... :(

Rust doesn't let me display anything in particular. It misses flexibility in that piece of need. I think I should still try to Deref. I'll have to duplicate Rc in that case...

Okay, I better don't spam about inheritance here. I'll still give a try to replacing Rc somehow.

[ROBERT-MCDOWELL]

There is always a way to do it, it only needs the righ idea ;)

[ROBERT-MCDOWELL]

WebAssembly/design#1255 (comment)

Crystal has inheritance, but its host/target systems are still very undone. Well, meanwhile only C++ has inheritance and targets systems well (like Rust).

Inheritance is something efficient/flexible for display objects, but what I need isn't inheritance at all; I just need efficient field traits within reference-counted structures. The unique way will be to diverge from Rust standard library's Rc pointer, but I think I'll just use Adobe AIR for now. I'm writting a package manager for ActionScript and maybe something good might happen.

What I see is that Adobe AIR has few-few showcases. I know apps/games done w/ Adobe AIR (Atelier 801 games (principally the newest, Dead Maze, released in 2017), Hero Fighter X, Brawhalhia, Gasha Universe and I'm not reminding right now other samples). 3D games there're too, but all of which I know aren't MMO (I even remind a nearly 3D RPG).

Probably with a package manager people'd stop being lazy.

[ROBERT-MCDOWELL]

In digital world the beauty is everything is possible, from bad to good. It just needs imagination, out of all squared guides, manual and else...

I solved to continue building a refinement language of ActionScript. (Now that I've deleted my unicode-gc repo and lost its source, I'm so sick about it...)

• Vega in ~7 mins.
• W.I.P. semantics

Vega isn't exactly a subset of AS. It's not AS, but by the syntax and namespaces it looks like. It's mostly zero-cost (near Rust and C++), has no RTT (runtime-type) info and no property names in run-time, very unlike JS/AS/Lua/C#/Haxe.

[ROBERT-MCDOWELL]

ok good idea, but is the purpose of this new language to be used with Rust or?

@ROBERT-MCDOWELL Mostly with C++. If it were Rust, then I'd have to waste neurons with the borrow checker and general crates obligging me to borrow several times.

[ROBERT-MCDOWELL]

ok gotcha. So what the advantages to create a new language on top of C++ knowing that for ex
Haxe is an Actionscript like language and can be compiled in native?

@ROBERT-MCDOWELL Haxe has RTT-info (reflection and property names in run-time), what means it already has certain overhead for large projects. But whether that RTT-info would cause slowness, well, it depends in AOT optimizations. If dead code isn't eliminated, much may happen.

Haxe is at least better than ActionScript, but it's not entirely near a systems programming language. Its implementation uses a mark-sweep GC. If you take into account mark-sweep GC and RTT-info, it has a quite considerable overhead for the Web.

RTT-info? Well:

class A {
    constructor() {
        this.f = 'Hi'
    }
}

const a = new A
a[String.fromCodePoint('b'.charCodeAt(0) + 4)]

Unfortunately languages with reflection may already have libs using reflection and C#-like dynamic values.

These languages are for more than general purposes. Meta-hooking is everywhere and thus clustering your run-time...

But did it influence performance at all? Hm, I remember playing Super Mario Bros. Crossover (SWF) in a browser and it were slow. Playing it in a Flash Projector used to be more efficient. Embedding a big GC into another big GC isn't cool.

WebAssembly will allow re-use of the JS GC, I think, but I still don't like using them... Though it's acceptably usable.

[ROBERT-MCDOWELL]

I see... So just enumerate the pros and cons of this new language

@ROBERT-MCDOWELL Pros:

• Flexibler names (with namespaces) and aliasing versus Haxe/AS
• Really better imports (and the compiler aims to allow better directory-structure)
• Data-classes (Vector3F as a copy-value everywhere)
• Many syntax goodies (function keyword only used in non-method definitions; lambdas use arrow-likes)
• Implementation will use A.R.C. (auto ref-count) rather than tracing GC since the language provides WeakRef.<>
• Faster-to-write loops (numeric ones may use (inclusive) ranges, e.g., for (var i in 1..=j) task;, though there's no step like in Lua)
• Safer switch, safer in general.
• Less run-time clustering guaranteed.

Cons:

• No reflection (definitions can't be hooked at run-time; properties aren't exposed too).

Error-handling is also different. It's Rust-based, but discrete. throw will return and such and such.

[ROBERT-MCDOWELL]

ok, Do you think the Cons are the only major one? Could it be fixed? because properties are really important for more flexibility

@ROBERT-MCDOWELL Properties can be accessed, but can't be indexed/enumerated at run-time. E.g., you can do this in JS/AS... self['k'], delete self.k, for (let k in self) console.log(k); Object.entries({ window, }). Same can be done in Lua and other related languages.

In C#, dynamic also allows you to do so very easily, and this feature leads to type information being initialized and then hold statically in run-time.

[ROBERT-MCDOWELL]

What the alternative?

@ROBERT-MCDOWELL It's the equivalent of writting maps/dictionaries with string-keys. In languages like Rust and C++ there's usually no reflection too.

const reflection = {
    drink,
    api,
}

function drink() {
   trace('Drank soy milk.')
}

reflection['drink']()

P.S.: If this is used by someone (though inusual), then we also need a AS-like Function type that can be called with dynamic arguments and verify them at run-time, since outer code doesn't know the specific function types and how they should be called. This is easy...

Sometimes specific error handling is neccessary for calling functions, so Function is of no value, but if it's there it'll do nothing since dead code elimination will be successful.

Unlike other languages, Vega'd not need a passive JIT optimizator like V8. It'll be directly suitable for wasm and other platforms, even for embedding in existing apps and servers.

[ROBERT-MCDOWELL]

how long it will take to finalize this language?
do you know kha?
https://github.com/Kode/Kha

@ROBERT-MCDOWELL Kha is a SDK, but looks promising for me. Lots of targets and supports Haxe directly.

Hmm, really interesting.

As far as I know, Haxe doesn't target wasm anyway... And it's a run-time cluster.

[ROBERT-MCDOWELL]

well :)
https://github.com/ncannasse/webidl
Nicolas Cannasse is like you a brilliant developer, author of Haxe.

[ROBERT-MCDOWELL]

https://groups.google.com/forum/#!msg/haxelang/Pcm38LPFjW0/Q3-WXk2oBQAJ

Haxe compiler also performs DCE. Personally I don't like to have Emscripten (implies JDK) installed in my environment; 'd be nicer if it were just LLVM (LLVM does support wasm today).

But I know things can improve. Ehhr, I think I need to use Haxe.

[ROBERT-MCDOWELL]

I think Haxe is a good start indeed. And I agree that use LLVM direclty is much better.
https://github.com/bradparks/Native

[ROBERT-MCDOWELL]

Do you think that implement AVM1 is feasible with kha? as it's much smaller than AVM2 so it would be a good test.

There're many built-ins in ActionScript, so there'll be a regular cost for any SWF running in Kha. Also doing it in Haxe won't be very efficient at all (but still better than in AS).

Conversion is the best way to fit existing projects, unfortunately. Well, I guess Adobe will also give up for AIR. :vv

[ROBERT-MCDOWELL]

There are many very good games and app not maintained anymore, or just with lost sources, I was wondering if there is a way to interpret teh SWF as it is through LLVM or such

Yes, but you can already use such SWFs with standalone projectors... They won't be efficient for the Web, you could be sure, or unless they don't (accidentaly) use the so common AS reflection, dynamics and external bytecode loading (through normal SWF loading).

Well, are you still referring to play SWFs in the Web?

[ROBERT-MCDOWELL]

yes, usually they download various things, not possible anymore with the legacy projector tech for security reasons

Yes, I see. But it's not neccessary to use the Web for this implementation. Also, you can consider using old Firefox versions which allow plugins like Flash Player.

E.g., download Firefox Portable.

IMO what's missing is a efficient SWF player for Android. It'd be like a PSP emulator.

[ROBERT-MCDOWELL]

Users of my platform use https://www.puffin.com on Android and IOS, works very well

[ROBERT-MCDOWELL]

We constantly need to go back to the essential, find a way to run legacy and new standards on the same browser, that's why I created this repo...

[ROBERT-MCDOWELL]

https://thinkmobiles.com/blog/convert-flash-unity/

Exploding Rabbit's Jay is also re-writting his SMBC game in Unity/C# (with ECS) for use in a new upcoming game.

I think not everything in Flash has to be used in modern ways (like running any old SWF in your normal Chrome). As I said, everything will have to be emulated with pre-installed apps (Firefox Portable for MMO or SWF-external games in general, standalone Flash Player Debugger/Projector and standalone PegaJogo).

Only ellaborated SWFs which still show good value will be re-worked in general.

I said miscellanous times about transparency here, too. Display objects, networking etc. are all fine, but due to AS (JS-dialect) it's a bit inconvenient to fit SWFs in the web. Well, ... It has to also have more relationship to the Browsers API to be a successful and costless project for bringing hand-heavy games there.

Principally, one issue I had said earlier was SWFs that load external SWFs. Implementing this feature for the Web is heavy as it also means embedding a JIT WASM generator into the self Web page.

Reflection isn't entirely an issue too, but if it can be avoided, that's better; it decreases initialization cost and loading (no constant pool names and garbage property tables). Just like C++ and Rust.

Okay, reflection could be broken. It'd not affect usual projects, but people'd have to definitely diverge from AS to not fail futurely.

Red Tamarin thinks it'll turn into AIR, but it'll also fail (though it's old). It doesn't care for reflection, but does use it accidentaly. Adobe doesn't care for AIR and uses it very little.

What I think is that it'll just fail.

(I preferred not to say about languages very much.)

[ROBERT-MCDOWELL]

• It has to also have more relationship to the Browsers API to be a successful and costless project for bringing hand-heavy games there
  that's all the challenge
  I think about a game dev team I know running an online multiplayer Flash game since 2001 with 80 millions users. If we find a good solution I'm pretty sure there will be already a massive client to embrace the project as they didn't planned to reprogram a very well running game.

[ROBERT-MCDOWELL]

btw red tamarin, crossbridge essentially have been discontinued because of strategy choice, aka focus all their effort (Adobe included) to webassembly

@ROBERT-MCDOWELL Hmmm...

game dev team

Do you know which? Well, of the alive games I only know HF-X (inactive now) and A801 games in general...

[ROBERT-MCDOWELL]

I will tell you right on time when needed ;)

There's much to do to get my language working. Hmm, I think I'm getting of my idea. Once I was able to get DollScript almost symbol-solving, but I did also waste time parsing it.

Well, I think Swift would be great really, but it doesn't still target Windows very-well and WebAssembly. For me it'll be Haxe, dot. :|

[ROBERT-MCDOWELL]

thing I know is today everything is done to make things very complex, but as it's done on purpose it means that there is always a narrow door opened we need to find. If it was easy so it would be already ready to use! :D

[ROBERT-MCDOWELL]

Ok we are one day before to decide what to do to start.
My analyze and vision of things:

• all corpos controlling the web tech decided to adopt webassembly as the replacement of Flash and btw opening doors to multiple languages, as perspective get rid of JS which is obsolete, cpu and memory hunger, also hard to maintain. Of course webassembly will be the way for the major social corpomedias to improve all their JS spaghetti code. So the first point we can't avoid is webassembly, which on long term will even replace desktop softwares.
• Create a language is always possible, but on long term requires thousands of developers adopting it or for sure it will be dead before birth. To attract them, it needs a language that offers what other languages don't to make development to be easy, fast and rock solid. I don't have any doubt you are skillful to create this language, but something no one control is Time. Haxe, build on top of other languages is for me the most advanced Framework, in term of quality and popularity. I'm following this project since the start (12 years) and his Author, I can confirm that the quailty and results done on this project after 12 years is just brilliant, and a very important point, it's not controlled (for now) by any smoking corporations. it's genuine developers community from all around the world.
• So why not to not reinvent the wheel again and use what's already existing, and specialize/optimize it for what it's needed? explore deeper some part of Haxe to fill some gap/missing/features is not negligeable.

In conclusion, optimize Haxe, runtime machine for webassembly is the right solution for me, knowing that Nicolas Cannasse just started it, I guess that guys like you who join to the project will be nice. And at least you will be directly in the game, with no waste of time and doubts.

Of course webassembly will be the way for the major social corpomedias to improve all their JS spaghetti code. So the first point we can't avoid is webassembly, which on long term will even replace desktop softwares.

Haxe targets wasm by transpilling to C++, though. Maybe it were from this idea that they started to think in reflection. ;)

(A pitty the C++ runtime may include a mark-sweep GC. It could just use auto-ref.-counting if there wasn't the any-type and interface-casting limitations.)

Haxe, build on top of other languages is for me the most advanced Framework, in term of quality and popularity.

Some perf. proofs are like the Armory engine, but frameworks may be missing networking. So, yay, we need contributing to existing projects or build something above them.

From what we can see here, Kha supports graphics everywhere (a bit low-level, I think, but supports TrueType font rendering and probably benefits from Canvas 2-D), but networking isn't done.

[ROBERT-MCDOWELL]

• (A pitty the C++ runtime may include a mark-sweep GC. It could just use auto-ref.-counting if there wasn't the any-type and interface-casting limitations.)
  that's already a point to work on it no?
  I know Armory engine, but didn't know it lacks of Networking...

[ROBERT-MCDOWELL]

so in any case Networking classes must be implemented right? for sure it would be a plus for all the games developers.....

[ROBERT-MCDOWELL]

Isn't Kha be added as a module in Haxe?

It exports definitions to the kha package, but things are implemented individually for each platform.

Http.hx just provides a header for requests. Now, Sources/Kore/Network (written in C++) shows there's certain progress in connection...

It might be in design, but they should adapt to the Fetch API. For targetting HTML5 they'll want to reuse browser's XMLHttpRequest probably, but fetch is going everywhere...

[ROBERT-MCDOWELL]

or simply webrtc

[ROBERT-MCDOWELL]

good idea!

@ROBERT-MCDOWELL TL; DR, before all I think it's a good idea to allow AS to evolve through a package manager, then the first non-alpha version will force people to use a more bound-stricted AS and, when possible, probably Vega or a language-alike gets implemented and replaces AS completely (as2vega plus some manual user changes for ARC.).

I'm implementing a package manager for ActionScript with Node.js (I was about to use Rust, but I got some borrow limitations and got bored to do so; I was also about to use Red Tamarin or AIR, but none of them were appropriate enough for CLI apps and the former crashes arbitrarily).

I did even write a TOML parser and was beginning a CLI lib. in AS, but I got really disappointed about AIR/Red Tamarin. Well, I'm even not so sure Adobe will give a **** for my projects. Adobe plus its dead community is extremely lazy.

I'm sometimes excited to use AIR and, when I use it to write something, I do it divergently, unlike most usually write it, but no one really cares.

I find it so weird and, when I compare it to the JS or Rust community, it's quite much dead really. I'm not sure AS deserves such a package manager to get more easy to use and handy.

I lost my unicode-gc and various parser libs I wrote due to lack of feedback. Hmmmm, I guess we should eat AS.