BehindTheBarrier

joined 1 year ago
[–] BehindTheBarrier 2 points 6 days ago* (last edited 6 days ago)

I'm a chemical engineer and fullstack dev. Also not pissed, but it's worth clarifying that I am worse at frontend than backend...

[–] BehindTheBarrier 4 points 1 week ago* (last edited 1 week ago)

Made my own (windows only) to learn programming. Primarily because nothing beats Ctrl-C, Alt-Tab, Ctrl-V, Enter, Alt-Tab to download something. Then profiles, textfile with link support, and parallel downloads since some sites rate limit downloads.

Somewhat crude (don't ask me how the profile are stored behind the scenes, it's a mess)

https://github.com/Thomasedv/Grabber

[–] BehindTheBarrier 1 points 2 weeks ago

That's true, i didn't think about that when I wrote it.

I'm used to the world being pretty simple though, so for me that slash has always just been a visual representation of the location of the branch if that makes sense. We don't have to have a slash in the branch name, only to use it to represent where that branch is located. It could have been something git only used for presentation.

[–] BehindTheBarrier 12 points 2 weeks ago (4 children)

I never considered branch names to be a vector, but in hindsight it makes total sense when put into a workflow like that. What possibly surprised me even more, was that branch names weren't limited to basic characters or at least no special signs. I obviously see the case for all the extended characters outside the latin alphabet, such as Chinese characters, but I totally expected restrictions on special symbols like ", ', /, \, ;, etc.

[–] BehindTheBarrier 3 points 2 weeks ago* (last edited 2 weeks ago)

It's said right in the article that games benefit from only using the main CCD (where half the cores are, those with the X3D cache) It's nothing new for dual CCDs to have overhead of splitting work across the two CCDs. So 8 cores makes sense here, especially when only one CCD has the "infinity cache".

The other thing is SMT being disabled. If I understand SMT, it's what gives the 2 threads per core. So maybe it should have been 8 cores, 8 threads in this case? Edit: I googled but didn't find a good answer apart from seeing someone benchmark the with the boost on, and the normal had the doubled core count threads, while the "turbo mode" only mentioned the core count (at half)

[–] BehindTheBarrier 2 points 4 weeks ago (1 children)

Thanks for the replies.

The stashing isn't as bad as it sounds, it keeps a copy around when swapping branch so even if you fuck it up, it should still be in storage. I think the worst one I had was popping from the shelf and it failed to apply but still got removed... I don't remember why that ended up happening but yeah. Not exactly related to the automatic stashing however. But I tend to more often want to keep changes changing branch than not. I have to use stash/Shelve less often because of it.

I know Jetbrains added a "all in one" diff option about a year ago, but I hate it as large/many files make it horribly slow and awful to navigate compared to just moving through the files one at a time. But the diff view itself good. I know there may be some that disagree, but it allows ignoring whitespace and newlines, which filters out non-important from important changes. For most programming (aka not python) whitespace changes means nothing so it doesn't matter 99% of the time. But it greatly improves going through a diff that had a total "code cleanup/reformat". Which is more often than one would expect in my project.

[–] BehindTheBarrier 2 points 4 weeks ago (3 children)

I asked about that for diffs, because I can't imagine using a terminal for this job. I don't mean any offense by it just to be clear, it's just not something that works for me. Perhaps I rely more on visual orgnaization. To give some context to that:

The standard way git shows up in a terminal (on Windows) it's diffuclt for me to "orient" myself in the code based on the diff, I prefer side by side diff compared to the split addition/deletion lines. I also like syntax highlighing that default git does not do.

Git in a Jetbrains IDE has the diff for any of my changed files is a single click away. The commit window has overview of changed files, a single click to view and edit a diff, including the normal syntax highlighting and one-click revert for a single change. Jetbrains specifically also avoid some of the bothersome part of pulling or checking out changes, as it doesn't force you to stash changes first.

Dealing with a merge conflict without a GUI also seems exessively hard. How do you do that through a terminal and keep track of things? Especially if it is a really messy conflict?

[–] BehindTheBarrier 6 points 1 month ago (6 children)

How do you view diffs and merges when you say you don't use git GUIs? External tool or terminal/command line?

I use Jetbrains IDEs and most of my life has been IDE based git interaction. And I honestly love it, easy access to see my diffs, the most common commit, push and stage(or shelve as Jetbrains does it, which is better than visual studio). Hassle free and available beats writing anything to me.

[–] BehindTheBarrier 5 points 1 month ago* (last edited 1 month ago) (1 children)

My own disks won't survive the house burning down, and while obviously feasible, aren't accessible when I'm not home. I don't need it often, but sometimes I do. But the extra safety of a cloud disk is nice.

[–] BehindTheBarrier 1 points 1 month ago

The thing he wanted looks AI generated as well...

[–] BehindTheBarrier 6 points 1 month ago

Just got reminded of the silencer gun battle scene in one of the John Wick movies. That was perhaps the most unrealistic thing I'd seen in those.

[–] BehindTheBarrier 3 points 1 month ago (1 children)

What do you think the effective power generation and heat production is for whatever that reactor is producing, when not in a suit?

If memory serves correctly, the entire outer shell is a round metal cylinder, so that's a fairly large surface area to transfer heat to the body. Tony might not need winter clothes if he's got a portable heater in the chest.

 

Some background, I work full stack while we also man the support email from users. I'm manning the support email this week, but today I was also tech support for a fellow developer.

We use HP docks to connect everything from screens to keyboards. But today a dock would not do anything when my colleague attempted to use it.

Being the nosy kind, I went and asked the usual

  • Did you reboot?
  • Did you remove the power to the dock?
  • Try messing with the drivers?
  • lock the screen before unplugging?
  • Tried another dock?

All yes, none worked. Our IT support hadn't opened for the day yet and he was looking into updating the specific dock driver.

So I asked, did you try the other USB-C port? And what do you know, that worked. Then he just plugged right back into the first USB-C port and everything was back to normal. I don't know who made the drivers, but it's pretty danning when they can brick a specific USB port until it's forced to redo whatever config that messes it up, by using another USB port...

If anyone wonders, the docks have a magnetically joined charging and USB plug, so it's fairly natural to plug them in together side by side. It's also almost uniquely a dock issue and not a dead USB port, so it's funny that the enite thing uncloggs from just using another port for a second. But a reboot does not...

22
submitted 1 year ago* (last edited 1 year ago) by BehindTheBarrier to c/rust
 

I'm super new to Rust, like a day old really.

But I tried a program made in Rust on Windows, and it refuses to work.

Never prints anything. Just straight up instantly dead. Long story short, this thing relies on some linked stuff like ffmpeg in some form. So, I did my best trying to gather all the things it needs per github issues, reddit and other souces. And the end result was that it now spent 0.1 s longer before crashing, actually leaving time for some error in the Windows Event log. Nothing useful there either as far as I can see.

So I clone the repo and get the required things to compile Rust, and I managed to build it from source at least. The executable doesn't run, but the Run in VS Code works, somehow. It prints the error messages corresponding to missing input. So i try to debug it, but nothing happens. No breakpoint is hit, and nothing is printed in the terminal, unlike when using Run or cargo Run. I can also just strip out everything it does in the file the main function is in, and it will hit breakpoints. But that didn't help me find out what is missing/broken though.

So what the difference, is there a way to catch and prevent Rust from just going silent, and actually tell you what dependencies it failed to load?

My entire reason for getting it running locally is to fix that. Because no one sane wants to deal with a program that doesn't tell you why it will not run... And when debugging also does nothing... I'm out of ideas.

The program is called Av1an for reference, and it's a video encoding tool. I used a python version before they migrated to Rust, and wanted to give it a try again.

Edit: Wrote linked library, but i think the proper term is dynamic libraries. I'm really not good with compiled programs.

Update: Figured it out. Had to copy the out files from the ffmpeg compiled stuff back to the executable. Apparently Cargo Run includes that location when looing for the files, while running from the command line clearly doesn't.

But the biggest whiplash, was that I got a full windows dialog popup when i tried to in the exectuable in CMD instead of Powershell. Told me the exact file I was missing too. I know PowerShell is a bitch when piping stuff, but I'm amazed no other program or error message could hand me that vital information. Fuck me, I wish I had tried that from the start....

view more: next ›