I have recently started on building the oil circulation system for the bearings
I have recently started on building the oil circulation system for the bearings
A few days ago I wrote about how my small desktop app was already suffering from spaghetti code due to interaction between its modules. I had originally set out to create an application with just 3 modes: Gravity, Electrostatic movement, and chemical bonds. But this has a big problem: The scope is small, making development uninteresting and the actual application pointless to users.
In order to solve my spaghetti code problem, I came up with a solution: Instead of implementing 3 different modes, implement an interface that allows you to add as many modes as you want.
My first step was to decide what the public API should be for creating a new module. I settled for this:
The module author may want to intercept a few different things:
I built a module system to register all of the above, plus a psim_module_api.hpp header for the module author. It defines a C-ABI entry point that calls a C++ init function the author provides. I was almost done with the entire process when I discovered that Windows apparently doesn’t properly support the ability of DLLs to access functions in the main program by linking against them at compile time, and had to rewrite a large chunk from scratch.
All the user has to do is include the header and define a void initializePSimModule() which is forward-declared by the header and called by the entry point after populating the function pointer table.
Then we just use user-friendly functions to register anything the module might need. An example module is shown in the screenshots, along with its source code. This module creates constants for boundaries that particles cannot cross, effectively boxing them in a rectangle.
I rewrote the Gravity and Electric modules in the module system. They are part of the core application, so I’m not loading them dynamically every time, but they use the same API as dynamic extensions. This makes it essentially impossible to create spaghetti code around the different modes, and now all I have to do to load a new module into the program is call loadModule(const std::string& path).
The final flow is something like this: The module entry point is a function that receives a function pointer table to all the C-ABI functions that the module uses under the hood. It populates the module’s function pointer table (the one I added because of Windows) and then calls the main initialization function implemented by the module author.
To put things in perspective, here is what happens when you register a constant:
You call registerConstant(...) with a std::string and a std::function => they’re destructured into C-friendly structs => the module finds _regConstant(const char* module, size_t moduleLen, ..., PSIM_Constant_Change_Callback) in the pointer table and calls it => the main program restructures the C parameters back into C++ types => the main program calls the real registration function.
And this is precisely the hard part: The module author can believe that he’s dealing with the same exact std::span<Particle> that is passed to him by the main program, but in reality that span was destructured into a Particle* and a size_t and was then restructured, all before his callback was even called.
This took me 8 hours, and out of everything I’ve done with PSimUltimate for now, this has definitely been the most valuable learning experience. I learned how to expose C++ APIs while maintaining a stable C ABI backend. Very cool!
I might’ve gotten something wrong, sorry if that happened.
I’m trying to create an implementation of a predictive coding neural network.
I have started with reading the tutorial above, it’s a great source. Written down my own understanding of it, made a couple iterations with ChatGPT to correct any mistakes.
After this I’ll continue with learning the basics of numpy and writing an implementation of it in python.
I have reached a few goals and managed to complete a few challenges that I was afraid of. There are actually two important steps I have completed.
First, I managed to finish the raw Hexapod build (a few electronic parts are still missing, but I mean the body).
Secondly, I made a few improvements to control a Hexapod leg with coordinates (we also had a problem with our C++ header files that my friend has, thank goodness, solved). So now we are really able to control a real leg with coordinates.
Another big feature where I laid my focus was a first movement test. I already implemented this feature. I tried to program the tripod gait. I hope that it’ll work, because I wasn’t able to test it until now like I mentioned above, I hadn’t had the time to include some electronic parts in the Hexapod build.
I suppose my next big step will be to actually get the robot to walk, so that my friend can finish his important tests and start to implement other movement features, because he is already really hyped for that. We’ll maybe also start with some kind of a control system, but I think that this will take us a little more time and it will be a while yet before we actually get started with that.
I’m trying out on making the fake injury option, and it is not working as intended. It’s supposed to have a rhythm based minigame, sort of like friday night funkin even though i’ve never played that before, but it clearly isn’t working.
\
All the icons are sideways, there are too much notes, and for the longest time none of them would scale correctly because I forgot to assign the new scale to the scale property.
\
Okay I think I got it this time. If I just leave the backslashes alone…
The core goal was to make this work in a meaningful, compiler-owned way:
name: string = "Ivy" as string
raw: @char = name as @char
other: string = raw as string
if name == other:
print("same\n")
end
print(name.length)
That meant Flower needed more than a typedef in generated C. It needed actual type rules, actual lowering rules, and I needed enough hairs on my head to not be bald after the amount of scares that occurred.
The first step was giving string real compiler support without going too far too fast.
I added support for:
string and @char
string.lengthflower_string_from_cstr(...)flower_string_eq(...)flower_print_string(...)That gave Flower a usable string foundation while still keeping literals conservative for self-hosting. Right now, string literals are not fully “native string values everywhere” yet; the compiler still uses explicit casts like "Ivy" as string as the safe bridge.
The reason for this “safe bridge” is because when I got too ambitious, the compiler would break since everywhere @char was used with a string literal it’d break due to no implicity being allowed.
I had to comment out the following new changes and keep the legacy support so it’d compile:
else if ast.kind == AST_STRING_LIT:
// fprintf(out, "flowe_string_from_cst(")
// fprintf(out, "%.*s", ast.data._string.str_length, src + ast.data._string.str_start)
// fprintf(out, ")")
// LEGACY CODE HERE
and
else if expr.kind == AST_STRING_LIT:
// set_plain_type(out, TOKEN_STRING)
// LEGACY CODE HERE
return 1
The most annoying issue was not string equality or .length. It was print.
Originally, non-string print(...) was basically lowered like this:
printf(expr);
That only works when expr is already a C format string. So something like:
print(name.length)
generated invalid C:
printf(name.length);
The fix was to make print(...) type-aware. Typecheck now records the operand type, and codegen lowers print differently for string, @char, char, floats/doubles, and integer-like values.
That sounds small, but it matters a lot: once string became real, print could no longer get away with pretending every printable value was already a C string.
Somehow Flower’s bootstrap process was breaking, and it will probably break again. Despite the bootstrap requiring it to compile itself, somehow afterwords the binary could become corrupted.
l-2: ~/Documents/GitHub/FloC % make bootstrap
=== Building new version ===
Compiled ./bin/Flower_new.c → ./bin/Flower_new
=== Testing new compiler ===
Compiled ./bin/Flower_test.c → ./bin/Flower_test
Verified bootstrap build complete
l-2: ~/Documents/GitHub/FloC % make bootstrap
=== Building new version ===
Luckily, I always make sure to keep a backup Flower bin stored under /bin/Flower_backup so I used that to compile the new binary and then it worked.
What still remains is the bigger ergonomic question: how fully native string literals should behave, and how to migrate the compiler’s own source to that world without setting bootstrap on fire again. I’m not sure yet how I want to approach this question, or what the goals for it should even be, but I guess I’ll have to find out soon enough!
That is the next fight. But at least now, it is a fight on solid ground.
it is currently 3am and i stayed up finishing this. the style change quite a bit from the original design. however, the organization changed completely. i decided to keep the website as one whole page and to only focus on who i am and my projects. i added my music in there too, since i learned from my friend how to play around with spotify features on websites.
im very proud of this project and it def is a unique take on a website for me. now im going to go to sleep.
pretty excited for this one, as I have implemented a fully offline pokedex for my app!
Since the last devlog, things have moved very quickly and I have implemented a large amount of things.
TODO:
Things went pretty smooth since the last devlog, a lot of work was able to get done (regrettably with AI, but whatever gets me to the stuff i’m actually good at faster…)
After that, it’s the cool hardware stuff! I hope next devlog is a breadboard and not more coding and boring software…
I worked a LOT today! Ran into a few issues with not committing my models so I lost good ones :( But I eventually thought to do a second round of training on real images not just synthetic data and that made the model a LOT better. Still room for improvement like full color, more data, longer training, etc. But the model is getting really good and I will build a web UI soon!
I was able to create a stub of windows.kinect so that we could have kinect support and redirect it to Microsoft.Kinect. So far its been working well, but the point of this was to get mc 1.61 to not freeze when playing. It was a lot of repetitive work to get the idl and cpp stubs. The other issue is that mc seems to be giving me the trial version which I need to try and fix. Sonic Mania is completely playable as well which is good.
Devlog 2-
Hi again! Mae here! I realized this project cant continue if i cant get inputs and outputs from KSP, so i went ahead and spent about an hour and a half setting up all of the basic configs to get Kerbal Simpit to run. Below is a video of one of the basic test programs running on my arduino uno, receving altitude data from the game. It works! (it only took me till 1 am…)
.
PS: I’ve made some progress on the controller layout too, but its not in enough of a finished state to show it
I created the events page to the website!
Hello there! I’ve just started work on a project I’ve been meaning to work on for a long time… Starventure!
Starventure is going to be a survival-sandbox game where you can explore procedurally generated space, like in No Man’s Sky! You’ll have to fly down to new planets to keep yourself alive, whilst also building settlements in the orbits of planets.
Or at least, that’s the hope!
Right now I’ve got a simple visualizer and outline for the PlanetGravity class working, soon this class will be used by StellarRigidbodies to figure out what kind of gravity should be applied to a physics object. Let’s hope this goes well, and happy coding! (also happy pride month!)
I’ve started work on the 3d engine for the game I’ll be making. For the first day, I’ve implemented cascaded shadow maps where there are multiple shadow maps taken at different distances to create a hierarchy of resolution. And I’ve also implemented blinn phong shading. I plan to change this to a PBR pipeline later down the road.
Welcome to Stardance!