Microsoft demoed a version of their GraphRAG that translated C code to (I believe) mostly idiomatic Rust, and it ran without errors.
I tried to find reference to how they did it, does anyone know?
It sounds like this approach of translating old code could help speed up teams that are looking at rewrites. I also have some old code that's in Kotlin that I'd like to move to something else. I had a bad NullPointerException take down my application after missing a breaking change in a Kotlin update.
I mentioned neither of the things you're shouting at me about.
> I also have some old code that's in Kotlin that I'd like to move to something else.
Something else was left unmentioned because I'm not even talking about Rust. My reference to it was that I've seen the approach before where a RAG is used to aid in translating C code, and it's an interesting thing which with more examples, might be easier to non-experts like me.
Translating languages is of great interest to various communities. I have friends stuck with a Scala codebase written by geniuses who are no longer around, and they want to move it to something else that the team is comfortable with.
Or he’s just mentioning the other major transpiler he’s heard of recently that happens to be C to Rust and wondering how it works and if it could be adapted to other language pairs. You’re the one that’s taken the conversation in a super weird direction all by your lonesome.
Ha! I stumbled upon this by mistake. I wanted the camera to be able to turn on the PC to store recordings, but while tweaking the BIOS settings, I somehow got that wrong, and instead the PC turns on whenever it detects power.
I have it connected to an Eve Energy so I can track power usage, and that turned into a good remote way to turn it on.
Then with a Tailscale, I remote into it easily.
The downside is that I can't shut it down remotely without knowing when exactly to also turn off the plug. I could create some automation, but it takes about 2 seconds being off before turning on again.
>The downside is that I can't shut it down remotely without knowing when exactly to also turn off the plug. I could create some automation, but it takes about 2 seconds being off before turning on again.
Huh, I would have expected the BIOS to not do that if it detected a graceful shutdown (or at least have a longer grace period).
I'm about 60% with RISC-V, I'm enjoying learning it, and my use-case is being able to embed some assembly on ESP32 code.
A few years ago I embarked on learning ARM assembly, I also got far, but I found it more laborious somehow. x64 is just too much for me to want to learn.
> If someone feels compelled to read every function either the functions are poor abstractions or the reader has trust issues, which may be warranted.
I joined a company with great code and architecture for 3 months last year. They deal with remittances and payments.
Their architecture leads are very clued up, and I observed that they spent a lot of quality time figuring out their architecture and improvements, continuously. They'd do a lot of refactors for all the various teams, and the cadence of feature development and release was quite impressive.
In that period though, I and another long-standing colleague made a few errors that cost the company a lot of money, like an automated system duplicating payments to users for a few hours until we noticed it.
Part of their architectural decision was to use small functions to encapsulate logic, and great care and code review was put into naming functions appropriately (though they were comment averse).
The mistakes we committed, were because we trusted that those functions did what they said they did correctly. After all, they've also been unit tested, and there's also integration tests.
If it weren't for the fortitude of the project manager (great guy hey) in firmly believing in collective responsibility if there's no malice, I'd probably have been fired after a few weeks (I left for a higher offer elsewhere).
---
So the part about trust issues resonates well with me. As a team we made the decision that we shouldn't always trust existing code, and the weeks thereafter had much higher cognitive load.
That sounds like a very difficult situation. Would you be willing to elaborate on what kinds of bugs lay in the pre-existing functions? Was some sort of operation that was supposed to be idempotent (“if you call it with these unique parameters over and over, it will be the same as if you only called it once”) not so? I am trying to imagine what went wrong here. A tough situation, must have been quite painful. How serious were the consequences? If you don’t feel comfortable answering that is okay.
I can't remember the exact detail, but one instance was a function checking whether a user should be paid based on some conditions. It checked the db, and I think because the codebase and db move fast, there was a new enum added a few months prior which was triggered by our transaction type.
So that helped function didn't account for the new enum, and we ended up sending >2 payments to users, in some cases I think over 10 to one user.
The issue was brought to customer support's attention, else we might have only noticed it at the end of the week, which I think would have led to severe consequences.
The consequences never reached us because our PM dealt with them. I suppose in all the financial loss instances, the business absorbed the losses.
> So that helped function didn't account for the new enum
This is where Scala/Rust's enforcement of having to handle all arms of a match clause help catch such issues - if you are matching against the enum, you won't even be able to compile if you don't handle all the arms.
The only db work I've done in rust required a recompile if the db schema changed, or even the specific queries your program used, because the rust types got generated from the schema. So in those cases the db change would have driven a rust type change and rust would have verified exhaustive handling.
Db changes are generally at runtime, how would you recompile rust code during the save of the data to the db? How do you rollback the change if a compile fails? How do you add the necessary code to handle new cases of the enum but not have it present in the db? This is amazingly interesting to me, would love to know more.
Maybe a code gen layer that generates rust types from a db schema. I don’t know rust but have seen those in other languages. I could see a DB enum type corresponding to a language specific enum type and then the language rules applying.
I do think this is a level of indirection myself; if the generated code was perfect and always in sync, that would be one thing, but by definition it is not the case.
Function names aren't wholly distinct from comments. They suffer from the same problems as comments - they can go stale and no longer reflect the code they're naming.
I think the argument against comments is that while function names are a necessary form of communicating intent of the code, comments aren’t. The more forms there are the more work there is to update on each change in the code. Comments mean more to update and hence more to fail to update. They also generally can’t be detected for staleness as well as functions, although that is changing now with better ai, not only compilers etc.
Functions generally need to be documented, especially if there are any gotchas not obvious from the function signature. And one should always read the documentation. Good names are for discovery and recollection, and for the call-site code to be more intelligible, but they don’t replace having a specification of the function’s interface contract, and client code properly taking it into account.
>The mistakes we committed, were because we trusted that those functions did what they said they did correctly. After all, they've also been unit tested, and there's also integration tests.
As it is stated, I don't see where it is your mistake. You should be able to trust things do what they say, and there should be integration testing that happens which adds the appropriate amount of distrust and verification. Even with adequate unit testing, you normally inject the dependencies so it wouldn't be caught.
This seems an issue caused by two problems, inadequate integration testing and bugs in the original function, neither of which are your fault.
Building a sixth sense of when to distrust certain code is something you see from more experienced developers at a company, but you were new so there is no reason to expect you to have it (and the system for making code changes shouldn't depend upon such intuition anyways).
> This seems an issue caused by two problems, inadequate integration testing and bugs in the original function, neither of which are your fault.
I believe the problem may be the culture. Business logic that handles sensitive things where bugs can cost a lot of money is one place where hardcore DRY and factoring everything into small functions is not such a great idea. Yes, it may be a big function, and there is an upfront overhead of having to understand it all to make a change, and there is some duplication of code, but once you understand the function you can reason locally and such bugs would be less likely.
Better late than never, I have 3 of their bulbs in the house, and not being able to integrate with HA prevented me from buying more (at least before Matter was announced).
I've been using them with Google Home, so the lights weren't automated with HA. I'll try the integration out.
I have bulbs from wiz, which already have HA support.
Being new to all this home automation stuff I was quite intrigued how they worked though. They're exposed on the WiFi network over a really simple UDP based protocol which led me down a rabbit hole of writing a little go client to mess about with them, took a few evenings.
Not saying Xiaomi bulbs would be quite as simple to write an integration for, but they might have been. It's kind of fun seeing how people have reverse engineered all these custom protocols.
I got some of those Yeelight ones (gen 1/gray plastic and gen 2/white plastic!) but my experience has been really bad. Even if their app allows you to enable local mode it's laggy and just... stops working after a while, it also seems to break if it can't reach xiaomi servers (pihole). Wondering how you got yours to work, mine are just trash at this point and i've since switched to proper local devices.
Zero lag. If they lose power they revert to cool white. All local. Checked home assistant and its direct integration (yeelight)...no mqtt.
And looked up my old notes - copied in below though don't recall details of what I did. Suspect maybe I used the python stuff just to check that lan is enabled rather than editing
Just to confirm, you are using the Yeelight app for this setup? On android there's Yeelight Classic (red icon), Yeelight (purple icon), Yeelight Pro (black icon) and the Xiaomi Home one. I think some of my issue might have been that region lock thing that kept changing a few years back (someone mentioned in another parent here). I remember setting it up on the Yeelight (red) but it eventually had me switch to Xiaomi Home (green app) which then required re-setting it up on another cloud region, which then broke again after a while.
I'll give this python script a try for sure, glad to know you got yours to properly work!
Both the red yeelight classic and green Xiaomi Home is showing as previously downloaded on my iphone. Afraid I don't know which (was years ago) but I'd try red first
...and that too feels on brand for Xiaomi...utter chaos on branding.
I'm going to review my backup strategy these holidays, and look at how much downtime my services would incur if Hetzner shuts me down.
The reality that they have this power, and that they'd delete data irretrievably, scares me.
Last year I had a misconfigured port on a Docker service, and someone was able to exploit it and run a port scanner.
It was during a period that I was away from home, so if I hadn't seen their service abuse emails in time, I could have returned home after a few days to find all my data wiped out (or uptime monitors complaining).
I tried to find reference to how they did it, does anyone know?
It sounds like this approach of translating old code could help speed up teams that are looking at rewrites. I also have some old code that's in Kotlin that I'd like to move to something else. I had a bad NullPointerException take down my application after missing a breaking change in a Kotlin update.