prologic @twtxt.net

Follow

Problems are Solved by Method\" 🇦🇺👨‍💻👨‍🦯🏹♔ 🏓⚯ 👨‍👩‍👧‍👧🛥 -- James Mills (operator of twtxt.net / creator of Yarn.social 🧶)

Block / Report User

If this user/feed is violating this Pod's (yarn.meff.me) community guidelines as set out in the Abuse Policy, please report them immediately!

You are also free to Unfollow or Mute this user or feed. Muting will also remove that user/feed's content from your view and you will no longer see content from that user/feed anywhere.

@prologic does not follow you (they may not see your replies!)

Recent Twts

Recent twts from prologic

Trying to build a native heap allocator that grows and isn’t statically wired into the binary’s image is fuck’n hard™ as 🤣


#bfoknma

Mu (µ) is now getting much closer to where I want it to be, it now has:

  • A process stdlib module (very basic, but it works)
  • An ffi stdob module that supports dlopen / dlsym and calling C functions with a nice mu-esque wrapper ffi.fn(...)
  • A sqlite stdlib module (also very basic) that shows off the FFI capabilities

😅


#n3vbeia

(#w3qxekq) @movq@www.uninformativ.de What I wish for once on this miserable planet is for coporations one day ohave a different set of reasons to exist and thrive other than:

but since the only goal of that manufacturer is to make money, they do it

Life becomes very boring and uninteresting when your only goal in life is to “make more fucking money” 💰 Fuck 🤬 Fuck this Corporatocracy we live in 🤦‍♂️


#gpoo3oq

(#p43aoaq) @lyse@lyse.isobeef.org A “Hello World” binary is ~372KB in size. I currently have peephole optimization and deac code optimizations in play, and a few other performance related ones, but nothing too fancy. I have a test case that ensures fib(35) doesn’t regress too badly as I continue to evolve the language.


#y656lsa

Opinion / Question time…

Do you think Mu (µ)’s native compiler and therefore emitted machine code “runtime” (which obviously adds a bit of weight to the resulting binary, and runtime overheads) needs to support “runtime stack traces”, or would it be enough to only support that in the bytecode VM interpreter for debuggability / quick feedback loops and instead just rely on flat (no stacktraces) errors in natively built compiled executables?

So in effect:

Stack Traces:

  • Bytecode VM Interpreter: ✅
  • Native Code Executables: ❌

#hagpelq

mu (µ) now has builtin code formatting and linting tools, making µ far more useful and useable as a general purpose programming language. Mu now includes:

  • An interpreter for quick “scriptinog”
  • A native code compiler for building native executables (Darwin / macOS only for now)
  • A builtin set of developer tools, currently: fmt (-fmt), check (-check) and test (-test).

#oorss4a

Whoo! I fixed one of the hardest bugs in mu (µ) I think I’ve had to figure out. Took me several days in fact to figure it out. The basic problem was, println(1, 2) was bring printed as 1 2 in the bytecode VM and 1 nil when natively compiled to machine code on macOS. In the end it turned out the machine code being generated / emitted meant that the list pointers for the rest... of the variadic arguments was being slot into a register that was being clobbered by the mu_retain and mu_release calls and effectively getting freed up on first use by the RC (reference counting) garbage collector 🤦‍♂️


#xupmaxa

Hmmm I need to figure out a way to reduce the no. of lines of code / complexity of the ARM64 native code emitter for mu (µ). It’s insane really, it’s a whopping ~6k SLOC, the next biggest source file is the compiler at only ~800 SLOC 🤔


#kaiqxgq