@mai_lapyst@soc.saiyajin.spaceTinkered around the last couple days on my own dlang package manager & build system, and it finally can build simple apps (even with local, pathbased dependencies!).
Still in it's early stages, but it works (somewhow). Now I can start working on the registry software for it so packages can be hosted & explored online...
I think I like the D programming language quite well. Though I would say there are certainly still things missing, but that appears to be the case with all langs.
D seems to be pretty decent, so far.
#Dlang #ProgrammingLanguages
Samerion is written in #Dlang, which is a niche programming language, and games in written in D are a rare sight. Nonetheless, I'm not the only one, so check this out:
The Art of Reflection. A puzzle game, four years in development, with an in-house engine written in D. Coming out this year!
Demo available.
https://store.steampowered.com/app/2290770/The_Art_of_Reflection/
Fluid, the declarative user-interface library for D, has just been updated to version 0.7.3.
Despite the patch number, this is one of the largest updates, massively boosting Fluid's potential capabilities. The I/O system is now modular, taking inspiration from algebraic effects.
Full changelog: https://git.samerion.com/Samerion/Fluid/releases/tag/v0.7.3
@mai_lapyst@soc.saiyajin.spaceJust released my attempt on reimplementing the dlang language with an modern codebase, focused on modularity & clearity of the code: https://codearq.net/mdc/mdc
Currently only the parser is implemented, which can completly parse the libphobos & its own source. Next steps would be to move the ast into it's own package (it's currently part of the parser), as well as implementing the semantic analysis, typechecker and IR.
little trick to not have ugly signs messing up the alignment of your array data
#programming #dlang #gamedesign
@mai_lapyst@soc.saiyajin.spaceOne of my favourite #dlang's traps is postbliting aka the way dlang implements default values for fields.
In other languages, initializer (or default values) of fields are essentially just syntactic sugar and get compiled (more or less) to assignments into each of the declared contructors.
Not so in dlang however. It creates an instance at compiletime (of the class in this case) without running constructors and "snapshots" it. This is then used in the compiled binary whenever an instance is created: the snapshot is memcpy'd over to the newly allocated instance. The problem is, that this includes any field that is a pointer / a class!!! So if you have an member field which type is a class itself and you write an initializer to create that class with the new keyword, this instance is put into static memory and each instance of the class you've done this in now holds the same reference to that statically allocated instance. Each and everyone of them, and it's completly against my mental picture of field initilizers (and I assume for a lot of others as well).
Just stumpled about this again while debugging a template system I've wrote [code.dlang.org], where I experimented with moving the bound functions of a template into a "common" class so it's easier to share them with templates that are grouped together (i.e. sub-templates or "blocks"). Moved the fields around and without actually assigning the "common" class to the sub templates the tests magically started working and I didn't know why. Makes sense now, since they've just had recieved all the same reference to the same static instance of the "common" class.
Example code:
class Other {}
class Test {
Other o = new Other();
}
void main() {
import std.stdio;
auto t1 = new Test();
auto t2 = new Test();
writeln("t1.o: ", cast(void*) t1.o);
writeln("t2.o: ", cast(void*) t2.o);
}
On the other hand, I atleast got finally arround to clean up the serializer a bit / refactored parts of the json mapper so it can hopefully be easier reused with other formats. (All while sweating on the 7th floor, send icecream lol)
@mai_lapyst@soc.saiyajin.spaceRant about configuration formats
Im currently working on my dlang serialization framework and just thought about adding maybe yaml, but the spec is so fucking complex, half the time it even dosnt know what it wants to even say. Like, it cannot tell you straigt what characters are allowed in an key, heck it dosnt even can decide how keys should be parsed. For example you can put a `?` at the start of a line (after indentation ofc) and then write arbitary yaml that then gets parsed and used as the key! Like wtf!
So I tought: "maybe try toml instead", but theyre just the same insane but in a different way; like keys and tables/sections cannot have the same value since a table is just syntactic sugar for a key with an inline-table aka object. End bc it's not enough already we invented that it would be nice to put another pair of brackets (`[]`) around the section/table to say: hey this is now an **array of tables**! Like very nice for serializers and stuff.... *sigh*
Officially showing off my latest pet project: ys-3dskit!
This is a framework to build homebrew for the 3DS using
- xmake as the build tool
- xmake to manage libraries instead of pacman
- support for using the #dlang D programming language instead of C with full bindings and a port of the D stdlib (WIP)
code and instructions at https://github.com/ys-3dskit
video showing pure D homebrew building against devkitarm and libctru and running in citra - this is the experience you'd have OOTB given you had devkitpro setup, albeit with a slightly more complex main.d on show here!:
One more release of my Repology cli program. Got a PR improving option handling and then noticed some small bugs in display output I made, so I fixed them.
Grab it here: https://github.com/ibara/repology/releases/tag/v1.2.0
Hooray! I was gifted a SiFive Unleashed for my research lab, and wasted no time porting #dlang to OpenBSD/riscv64 by way of GDC:
/home/brian $ uname -a
OpenBSD riscv64.cs.rpi.edu 7.5 GENERIC.MP#26 riscv64
/home/brian $ egdc --version
egdc (GCC) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
A wild #blog post appears! I bootstrapped the DMD compiler on OpenIndiana and built a package for it. Which apparently no one had done before.
@mai_lapyst@soc.saiyajin.spaceAfter been a bit feed up not having demanled symbols in #dlang stacktraces, I searched and found out there's actually an idea to integrate dlang better into lldb; looking at it I then found out that the demangling part is actually (kind) already in LLVM's demangle library; it only severily lacks support for nearly any symbol.
So I figured I spend two days implementing it myself XD
ofc also send an PR, so maaaaaaaaybe in the future atleast non-context aware demangling is supported.
@mai_lapyst@soc.saiyajin.spaceYay, I finally got the #dlang #parser to parse (without any exception or segfault) itself and the libphobos standard library! Next step is either start working on the IR or to increaset source-to-source compability to actually check if everything is parsed in a correct order and/or to enable usecases such as documentation tools and formatters.
Performancewise it's not that bad either; it parses all 314k lines of libphobos in ~5.5 seconds.
@mai_lapyst@soc.saiyajin.spaceYay, finally done with my #dlang parser. And even without that many things left to fix too: it nearly can parse itself! Excluding the biggest files (lexer + parser, mainly bc they fail parsing) it only takes around 80ms too.
The bug I run into the most honestly is the lookahead problem of dlang's grammar, since attributes come **before** the declaration. *sigh*
One reason more why #lapystlang / my own language is doing it the modern way: a keyword to first say what's about to come and then everything else.
@lepidotos@bitbang.socialIn yet more news, should I learn Rust or stick with D?
Given the state of the D community (and the character of the Rust community) I think I know what the answer will be, but here goes.
I know of a Rust compiler that compiles to 9x targets, can't say the same for D, but D does compile to MIPS R4200...
#programming #rust #RustLang #d #DLang
Feel free to boost.
@raccoonformality hopefully a near MVP / First content pass of Multi Mall - my mall simulator with mild OpenTTD vibes.
Fingers crossed 
#sdl2 #dlang #multimall
