The Getter returning void already gives some info that it’s not actually getting anything.
Regarding which side I’m on. I think the discussion can be avoided by renaming the function to Print_Contents, which more accurately reflects the actual behaviour.
I also think you should rename it to print_contents or PrintContents but I’m trying to be consistent.
Side B claims it’s not a getter. Side A and you thinking it’s getter because of the naming convention you are accustomed to.
My server is currently hosting:
I think that’s about it, maybe some small stuffs but this is the most interesting stuff.
This is all running on DigitalOcean’s smallest droplet with 1G RAM. It runs consistently with ~600M RAM in use and 200M swap in use, because rspamd needs ~200M statically which are never used (I don’t send a whole lot of email).
On the todo list:
Hosting your own mail is doable but difficult. I thought I was fairly okay at sysadminning, but it took a whole lot more time than I expected. I think atm I’ve got over 100 hours trying to get a mailserver operational. Tried a docker-container-based server first, but that’s just a bad idea.
I kinda agree with @eloy that your email should always work. But it was fun to do and people are amused/impressed by it sometimes.
Hosting Nextcloud is less fun because it’s a bit more resource intensive, so it probably won’t fit on this VPS in addition to the rest. But a spare 2G RAM laptop with a harddrive should do fine, if you backup your stuff properly.
Baking pancakes at a restaurant, writing Haskell (and compiling it to VHDL and synthesizing this VHDL, using Clash ), writing CPP (and compiling it to VHDL and synthesizing that VHDL as well, using Vivado HLS)
Always good to see more hardware people on here. Since I’m a software guy, I like to bounce open tools off of experienced, hardware people to assess the current state. If you have time, what do you think of Synflow’s Cx for hardware prototyping? Or letting non-hardware people get started on hardware optimization before handing it off to actual, hardware people? It’s one of the last attempts at HLS that I didn’t see reviews of.
Edit: Given your profile, you might also find [G]alois Inc](https://galois.com/) interesting given their work combines all that. They open source a lot of stuff, too. Have fun with that. :)
Thanks! This looks awesome.
The Cx for HW prototyping looks interesting, however I’ve recently come to believe that using imperative languages for hardware design is a mistake. An FPGA is a “logic machine”, as opposed to a CPU which handles instructions in a sequential way. That’s why C is the “ideal” language for CPU’s (in terms of being able to control exactly what is executing), because C is so close to assembly. For an FPGA, functional programming more closely resembles what the FPGA is doing, and the change in mindset forces you to think more in terms of what the FPGA needs to do / can do.
This is roughly paraphrased from what one of the Clash developers once said, I’ve forgotten where/when.
Galois sounds awesome! I’ll take a closer look when I have more time.
Yeah, the hardware people tell me it’s inherently parallel. So, parallel languages fit. You said inherently functional. The intro I read said there were stateless circuits (functionalish) and stateful circuits with internal memory. The stateful ones sound a bit more like imperative programming. I don’t do functional programming, though. So, what’s your take on the sequential circuits being functional? Or you make exception for those?
Cool! İs clash output reasonably efficient?
It’s quite fast at generating VHDL code, so that’s awesome. As far as I can tell, it’s efficient, but that does require understanding of exactly what the hardware is doing (which I don’t completely have at the moment). It’s also easy to generate hardware that you looks very different when changing small things
Clash looks really cool! I assume you’re working on some kind of FPGA?
Yes, the cpp->vhdl one should run on a PYNQ Z1 and the other one is a Cyclone V