Working a bit more on Scala Native + Raspberry PI GPIO .

I have some code to:

• Display arbitrary images to an OLED
• Perform an action (e.g. change an image) when a button is pushed
• Control a LED
• Fetch data from an HTTP server (OK, this part is not yet working because I run out of RAM while compiling)

So, I have all the building blocks for a small project:

• Periodically fetch notifications from a server
• Turn the LED on when there are unread notifications
• Show some details about the OLED screen
• Clear the notifications with a button press

But, I just noticed that I don't have any concrete project like that in mind.

It also doesn't help that the screen is tiny (128x64 and about the size of my thumb), so the amount of text I can show is a bit limited unless I use a font for ants.

So I think I'll let things simmer for a bit until I figure out what to do with this.

@JD557 running out of ram while compiling? Can you not cross compile from a more powerful machine?

@kubukoz@mstdn.party Great question.

I think so, but I don't know how to deal with the linking phase. I need a way to add wiringPi, but I don't know how to set that up on my Mac

https://github.com/Programming-Rivers/rules_scala_native/issues/7

@kubukoz@mstdn.party This did help me to send some PRs to improve SN's memory usage.

But now it's blowing up on State.fullClone() so I don't think there's no low hanging fruit there.

The only potential easy win there would be to change the OpenHashMaps to something else that could need less contiguous memory, but someone sent a PR 5 years ago saying that OpenHashMaps make the full clone much faster: https://github.com/scala-native/scala-native/pull/2134

That guy seems trustworthy, so I won't change that code

@JD557 using bazel to build scala native? talk about going uphill... 😅

@JD557 if only I remembered anything 😭

I'd start with a target triple and letting the compiler/linker know where the libs are