I heard that day-5 part two was a curveball, so I ...
# devlog-together
m
I heard that day-5 part two was a curveball, so I really want to be able to implement it using my visual programming system... which failed so far. Using a brute force solution would mean that the program would run very very long. And my current "speed run" solution wouldn't suffice for this. Part one actually provided a big challenge for my vps as well, running the program with the small test dataset can be seen in the video:

https://youtu.be/td0QeePvfGQ

. I've spend a lot of time adding more new node-types this weekend (like handling a while-loop and improved array handling) and making changes to the variable-nodes and expressions. Also the variable scoping (needed for local function variables) that I implemented had some flaws, so I fixed that as well. You can now define global and scoped variables. I've also made some simple variable visualizers that better show the data for data types like dictionary/array and grid. My current vps solution works better than the flow-based vps that I was building last year. A big difference is that the data that is send from node to node is now just a single value. That value can still be of different types (number, string, array).. and special variable-nodes are needed to keep track of data. These variables also have a type like number, string, array, dictionary, grid. Often working with a single value is not enough and that's why these variables are needed. They can be referenced from within expressions. Also being able to run some flow-parts in parallel or sequentially helps a lot. This starts to feel much more like a regular 3rd gen programming language. The UI is currently quite limited.. to be able to create a flow program efficiently it definitely needs a lot of work. Textual programming is much faster. I want to finish at least one of the advent of code puzzles where a grid is involved .. so today's puzzle (17) seems like a good fit. I'll probably work on that next weekend.
Big zoomable image of the flow
k
How are you using a VPS?! Is this running in a browser that receives graphics from a server that's executing the program? Or is this a "head-ful" native app that's rendering graphics locally somehow? Or something else?
m
This is 100% in the browser build with typescript without any libraries. It's all regular DOM and svg elements with css (tailwind and css transforms)
I hope that I can put something online in january, there are still some bugs that I want to fix before I do that 😊
k
Oh, you don't mean Virtual Private Server, do you? What does vps mean, Visual Programming System?
m
No sorry, I mean visual programming system 😊
The regular term that is used is usually VPL for these kind of applications, but thats not what i want to try and build. It's a part of it , but I want to build a system that can be used to build multiple visual programming languages and environments. I am probably aiming to high for a one person project 😅
k
Nice, I like it. The common lisp or smalltalk of VPLs.
m
Thanks! 😀 😊
a
Using a brute force solution would mean that the program would run very very long
There's some simplifying assumptions you can make about the inputs (that afaik are true, even if not specified) that get the brute force down to a reasonable runtime -- i didn't want to figure out the good solution that night, but got a python (so hardly a speedy one!) solution down to <4 minutes doing brute force