My comment game has gotten far better since I started doing live code reviews. Essentially I ask myself, “Would I feel the need to explain this to someone during a code review?” and if the answer is yes I add a comment.
Principal Engineer for Accumulate
My comment game has gotten far better since I started doing live code reviews. Essentially I ask myself, “Would I feel the need to explain this to someone during a code review?” and if the answer is yes I add a comment.
That’s a hot take. If you want your code to be maintainable at all, it needs comments. If you’re part of a team, write comments for them. If someone else may take over your project after you move on, leave comments for them. And have you ever tried to read uncommented code you wrote a year ago? Leave comments for yourself.
The key difference is that compilers don’t fuck up, outside of the very rare compiler bug. LLMs do fuck up, quite often.
Copilot frequently produces results that need to be fixed. Compilers don’t do that. Anyone who uses copilot to generate code without understanding how that code works is a shit developer. The same is true of anyone who copies from stack overflow/etc without understanding what they’re copying.
I’d create my own macro or function for that. I have enough ADD that I cannot stand boring shit like that and I will almost immediately write a pile of code to avoid having to do boring crap like that, even with copilot.
I have not and will not ever use AI generated code that I don’t thoroughly understand. If you properly understand the code you’re committing there shouldn’t be any damage. And beyond AI you should never commit code that you don’t properly understand unless it’s a throw away project.
I’ve run into that exact issue with copilot (deleting my tests). It is infuriating.
I don’t think I’d trust it to refactor code for me, not for anything important. I’d need to completely understand both the initial state and the result on a statement-by-statement level to be confident the result wasn’t secretly garbage and at that point I might as well write everything myself.
The way you wrote it, it sounds like you’re saying, “The FSF is worthless because they didn’t respond to me.” Which may not be what you meant but it still comes across as rather conceited. I don’t see how them not responding to you about your random project is at all relevant to whether the FSF is useful to the FLOSS community.
It’s not clear to me that AMD is in breach of contract, though I admit I haven’t looked into it in detail. But regardless, the contract is irrelevant to the open source thing unless that was in the terms of the contract.
If I steal code and release it with an open source license, that license is not valid. The author released his work open source based on an email from AMD. AMD is now saying that email was not legally binding thus the author did not have the right to release it under and open source license thus that license was not legally valid. If you had forked it and continued to use it, AMD could take you to court and say that the license you are operating under is legally invalid.
Obscurity is not real security
if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.
That goes without saying; I’m not a barbarian.
“readability” is subjective. much like how there is no objective definition of “clean code”.
Did you not see the part where I said it’s less readable “in my opinion”?
i am insisting that people use a common standard regardless of your opinion on it.
I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.
The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.
Sorry, I forgot about this. I’ve attached my full configuration at the end. The steps are:
docker exec --privileged -it container_name bash
.
--privileged
is required to make delve work. I don’t entirely remember why.-it
is something like --interactive and --terminal, it’s what you need to get a proper interactive shell.container_name
is the name of your container.bash
can also be sh
or pwsh
or whatever shell your container has (hopefully it has one).dlv attach PID --headless --listen=:2345 --accept-multiclient --api-version=2
.
PID
is the ID of the process you want to debug. This should be 1
if you’re debugging the main process of the container.--listen=:2345
says to listen on (TCP) port 2345 on all interfaces (0.0.0.0)ssh ${USER}@${SERVER} -NL LOCAL:2345:REMOTE:2345
.
LOCAL
is the local IP to listen on, usually localhost
. When a process connects to your local IP, it will be forwarded to the remote.REMOTE
is the remote IP to connect to, this should be the IP of your container. When a connection is forwarded from your local machine, this is where it is forwarded to. My containers are set up with --net host
so I can use localhost
as REMOTE
but that’s not the default so you may have to use docker inspect
to figure out your container’s IP.I also included the path substitution configs I use. I generally debug these by pausing the target, clicking on something in the stack trace, seeing what path it tries to load, then adjusting the substitute path so that it loads the correct file.
{
"name": "Attach to a docker container",
// Get a shell in the container: `docker exec --privileged -it ${NAME} bash`
// Launch delve: `dlv attach 1 --headless --listen=:2345 --accept-multiclient --api-version=2`
// Forward the port (if remote): `ssh ${USER}@${SERVER} -NL localhost:2345:localhost:2345`
// Then run this debug config
"presentation": {
"group": "99-Miscellaneous",
},
"type": "go",
"request": "attach",
"mode": "remote",
"remotePath": "${workspaceFolder}",
"port": 2345,
"host": "127.0.0.1",
"substitutePath": [
// // Full paths (GitLab Docker build)
// {
// "to": "/go/",
// "from": "${env:HOME}/go/", // <-- MODIFY THIS if you're not using the default GOPATH
// },
// {
// "to": "/root/",
// "from": "${workspaceFolder}",
// },
// Trimmed paths
{
"to": "gitlab.com/accumulatenetwork/accumulate/",
"from": "${workspaceFolder}/",
},
{
"to": "github.com/AccumulateNetwork/",
"from": "${env:HOME}/go/pkg/mod/github.com/!accumulate!network/", // <-- MODIFY THIS if you're not using the default GOPATH
},
// {
// "to": "",
// "from": "${env:HOME}/go/pkg/mod/", // <-- MODIFY THIS if you're not using the default GOPATH
// },
],
}
The TL;DR is that you have to exec —privileged and execute dlv attach within the container then tell VSCode to connect. I’ll look up my notes tomorrow and post more details.
Attaching to and debugging a process most certainly does work. I did it yesterday. Your issue is that Go doesn’t have any way of telling the process to pause until a debugger attaches. Which is frustrating but not the same issue.
Specifically for debugging stdin, by far the easiest way to do that (in VSCode) is "console": "integratedTerminal"
. Another comment links a stack overflow answer that includes other options.
If a spec tells me I should do something that makes my code less readable in my opinion I am going to ignore the spec every time.
AppArmor is part of the kernel. Why does it require patches?
GitLab, Inc is a business and it’s not run by idiots. If federation was going to make them a bunch of money, they’d put a team on it. Relying on an outside group to execute your business goals is terrible management. It’s clear federation is not one of their business goals.
They may advertise it, but they’d be working on it themselves if they thought it would bring in serious revenue.
Their rules have stopped me from being able to do my job. Like the time the AV software quarantined executables as I was creating them so I literally could not run my code. When security enforcement prevents me from working, something needs to change.