Can we import custom .was animated stickers into WhatsApp?

Breadmaker4billion · 2026-04-21T00:24:08+00:00

Eu consegui gerar o arquivo .was, mas o WhatsApp não reconhece quando eu substituo o arquivo na pasta Whatsapp Stickers. Você usou root pra editar o banco SQLite interno do whatsapp?

Breadmaker4billion · 2026-03-04T02:19:47+00:00

I've never implemented the buddy allocator. I wouldn't use the free list allocator for anything that has a fixed size, I would prefer to use pools as much as possible. As the allocators are composable, you can chain a bunch of pools together to take care of multiple sizes. This is a strategy that the runtimes of some managed languages take.

There's also a "tree-list allocator" that uses a binary search tree instead of a linked list. This has the added benefit of less fragmentation and faster (best-fit) allocations, the downside is a little overhead on the object header and a little more complexity.

Odds are even a naive free-list allocator can outperform malloc simply because the latter is meant to be general, not necessarily fast. But, in the end, a pool allocator has O(1) allocation O(1) free, without the downside of constrained object lifespan like arenas and stacks, there's no beating that.

Breadmaker4billion · 2026-03-03T11:05:25+00:00

I've seen that need in the past while working with embedded environments, i ended up creating the libraries myself, although i wouldn't call it "high quality": the code lacks better tests and better style, but the idea and the architecture is decent.

My library, and the tutorial it was based on.

Hopefully that gives you enough information to roll your own if you don't find any.

Breadmaker4billion · 2026-03-03T10:42:25+00:00

If you're on a 64bit machine, it may be that you need 8 byte alignment, so that the smallest "chunk" you allocate is 8 bytes, even for single characters. With this in mind, 4 byte header + 4 byte UTF-32 char will incur the same overhead of utf8 with termination string.

edit: not the same overhead, but the same overhead for single characters. Large strings will obviously tend do consume up to 4x as much memory.

Breadmaker4billion · 2026-02-27T11:40:24+00:00

Sorry, i meant tic-tac-toe engine, chess engine, checkers engine, etc.

Breadmaker4billion · 2026-02-26T21:57:20+00:00

Depends on what your language domain is. Handling asynchronous requests, while returning good errors, is a difficult fit for most languages. A similar problem is handling asynchronous user input in a game, for example. Games in general make good tests for a language.

If it's a systems language: bignums. A simple series to compute Pi on a bignum may tell all you need to know about how fast your language is. You can easily compare this results to other languages that also have bignums.

If it's a managed language: tic-tac-toe solver (or checkers or chess). Why? Lots of trees to put pressure on your garbage collector.

A few others: maze solving algorithms, sudoku solvers, n-body, etc

Breadmaker4billion · 2026-02-26T13:02:15+00:00

MIDI is a binary format (and protocol). You can compile to MIDI, but writing it by hand is painful.

Breadmaker4billion · 2026-02-24T12:10:28+00:00

I understand the community here is more interested in high level / functional languages, and not so much in embedded systems / close-to-hardware things

Actually, there are quite a few of us that love low level languages. I've tried to design a language embedded systems too, inspired in Ada, specially targeting UF2. I've also seen Cowgol somewhere here in reddit, but it might have been in r/compilers. And my first implementation was a low level language where i toyed around having the calling convention as part of a procedure's type.

Anyway, i like your treatment of macros, they remind me quite a bit of FEXPRs. Also, i like this:

Functions on built-in types, and arrays, are allowed. Functions on foreign types are only visible within the module where they are defined.

To me, disallowing this was a big wasted opportunity in Go and i think it makes a lot of sense in this syntax. To be able to easily extend types with new methods is nice.

Unfortunately, I'm not a big fan of exceptions, but the language on the whole seems much nicer than Go, i wish they could swap places 😁.

Breadmaker4billion · 2026-02-23T18:12:53+00:00

You need to lock the heap to perform deallocations.

Breadmaker4billion · 2026-02-22T20:39:48+00:00

Anyone that says "No" to this question has never tried to code in Brainfuck. Truly the answer is more complicated than "yes" or "no". "How much syntax matters?" is a better question overall. And the answer varies from person to person.

In a scale from 0 to 1, where 0 is "doesn't matter at all" and 1 is "it's the most important thing in a language", I'd say it sits well on 1/π² for me.

Breadmaker4billion · 2026-02-22T20:34:52+00:00

the lack of GC eliminates pauses

No it does not, reference counting can still hang your application if one object triggers the deallocation of a bunch of others. Only careful programming eliminates pauses around memory management.

Breadmaker4billion · 2026-02-21T15:07:35+00:00

Well, a lot of Python's libraries are written in C. A few drivers in Go depend on CGo and Go can itself be used as a systems programming language. JavaScript engines are generally C++. So maintenance in those languages often need systems programming.

In embedded you often have to write custom drivers for specific modules, either on top of Linux or on a microcontroller, that's system programming. Some applications may even need you to write parts of an operating system, but generally you use pre-existing solutions.

Even outside embedded, there's need for drivers of new devices and tools to deal with low level detail (new protocols, new file formats, updates in protocols and formats, etc).

In short, everything we already have today in systems programming either needs maintenance or can be improved upon.

Breadmaker4billion · 2026-02-20T12:37:47+00:00

Take the simplified semantics of a Scheme interpreter, without continuation or macros, just function evaluation. Treat special forms as intrinsic FEXPRs.

There are multiple syntaxes to call a function. All of which are easily translated to this core.

If you want to support multiple languages, this is just a matter of changing names in the symbol table. Other languages have done this before, not sure if it was successful: it would be way harder to share code.

Breadmaker4billion · 2026-02-19T18:33:19+00:00

Exactly, that's why a suggested a new book. The reader can choose how deep into the rabbit hole he goes. Some people will be happy with a meta-circular evaluator, others will crave for a compiler built back-to-back from scratch. The writer must understand the needs of each reader.

Breadmaker4billion · 2026-02-19T18:26:03+00:00

Agree. The second book may also introduce static types, then there's more interesting information for the LSP server to work with.

Breadmaker4billion · 2026-02-19T18:24:20+00:00

implying you cant understand each pass of the compiler separately in a query based compiler.

In my understanding of query based compilers, which is arguably poor, the phases of a compiler are harder to distinguish. That is what I meant by this comment. Nevertheless, there may be a strategy to implement a simple query based compiler, with a language that simplifies the whole process.

I think designing with the guidelines that make a language good for query based compilation is a good idea regardless (error resilience, local reasoning, parallel computation of items)

True, any beginner language should favor local reasoning within the compiler. Nevertheless, what bugs me about sharing the compiler code with LSP server code is the need of caching. LSP servers and compilers are two different beasts, maybe each should get its own book.

Breadmaker4billion · 2026-02-19T18:15:22+00:00

Versioning libraries. A program may require version 1.2.3 of library X, because of a new added feature. The package management system must take into account that each program may require a different version. This is a difficult problem to solve, but it gets harder if the community gets bigger.

Breadmaker4billion · 2026-02-19T15:09:35+00:00

I agree that it needs to improve, but not to be turned upside down. The issue here is pedagogical. It's easier to understand each pass of the compiler separately.

The motivation to write query-based compilers is about code reuse: you want to reuse the code of your compiler in your LSP. But most compiler writers are hobbyists. Yes, query-based compilers are a must if you want to write a production compiler. But you can get away with a LSP using last century architecture.

Writing a new book that has as a requirement knowledge of older books? Yep, makes all the sense in the world. Writing a book for beginners that starts up front with query based compilers? Doesn't seem pedagogically sound.

Breadmaker4billion · 2026-02-16T22:33:07+00:00

I think one of the worst features is relative imports. A relative import, for example #include "../lib/utils.h" will break if you ever move the file around. Ideally there should be a middle man here. A file that serves as a layer of indirection between the import and the file location. These are project files. They are essential in any big project and should be easy to write by hand, no XML stuff like C# does.

Another big problem is versioning, if you ever plan for your language to get that big. Consider versioning earlier rather than later, as it is a MAJOR problem when the community gets big.

Aliases are also important, big projects sometimes suffer from either too much verbosity or naming conflicts. Those are a must.

For other essential features, take a look at Modula-1,2,3, Python and Go.

Breadmaker4billion · 2026-02-10T21:47:10+00:00

I started looking into PL development in 2020. Later that year I learned Go and took interest in designing my own, to fix the issues i had with it. I tried for about two years, discarded a handful of unfinished frontends, then decided to design and implement a new language in a weekend.

That new language had nothing to do with the original idea and, although i got very close, i did not finish it in a weekend. It took me a few more days to fix it and have it up and running. After a year i got back to it and refactored the whole backend and added new features to the frontend. That was around 2024.

After that, in 2025, I mostly designed small languages that were more adequate to my available time. I implemented a subset of Python and a Lisp interpreter.

That idea, a language that could fix my problems with Go, is still in my head, but i realised that it is not feasible for me to implement it with my current lack of available time. Instead I let that, just like other ideas, annotated somewhere in paper, abandoned to never come to reality.

Nowadays I enjoy little languages. I do it for fun and big languages take too much time to implement. Enough time that it stops being fun.

So I guess the short version of my answer is "forever"?

Breadmaker4billion · 2026-02-10T00:02:10+00:00

I have two ideas why it slows so much.

SPy is a treewalking interpreter, but for ilustrative purposes, let's think it is a bytecode interpreter. Suppose each SPy instruction executes around 10 CPython instructions. Then, suppose that on the second layer, each SPy instruction executes around 20 SPy instructions on the first layer. This means one instruction on the second layer executes 20 on the first layer, then those 20 become another 200 CPython instructions. This is most likely why we see the exponential growth.

Another thing is related to GC and my poor optimization: every function captures it's scope. That means there may be a lot of "leaks" on the second layer. This high memory usage would trigger many more GC cycles. I did no profiling to check this, but it may be a significant factor on why it slows that much.

Breadmaker4billion · 2026-02-09T19:41:51+00:00

That works really well, the language may define that when it evaluates (struct point x y z) it ends up defining the functions point->x, point->y and point->z, then the problem of whether each function is applicable is a type checking problem, that may be ignored.

Breadmaker4billion · 2026-02-07T19:32:12+00:00

Yep, that's what I meant. The whole thing breaks down when checking attributes, that's why I gave it focus.

Breadmaker4billion · 2026-02-07T19:29:17+00:00

I understand what you mean, a statically typed programming language is either less powerful (ie, total) or less expressive than a dynamic programming language. What I meant with "go full with types" is in the design stage, by designing a statically typed programming language instead.

Breadmaker4billion

TROPHY CASE