Live data from Hacker News

Fixing a bug in Google Chrome as a first-time contributor

cprimozic.net

91–100 of 170 posts

Re: Fixing a bug in Google Chrome as a first-time contributor

#91
regarding the comments about the "build time" of firefox/chromium - a couple of weeks ago i installed gentoo 686 on an old netbook, including a DE/WM and firefox. I also told it to completely recompile everything that comes "preinstalled" in the stage3 gzip (that's prior to installing the WM and ff).

llvm took forever to compile, and then for some reason i needed to have two versions of llvm - i don't recall why offhand. So i have a devuan VM on my desktop here, i set up a gentoo chroot, updated it and installed distcc, installed distcc on the netbook - just like i've always done in these circumstances. Believe me when i say: it's still like magic, even if "distcc-pump" no longer works.

total time to get the netbook to a stable, running as i want it, useful machine - ~1 week. Results? It's actually useable - more usable than it was with windows 7 on it when it was new, and much more usable than whatever ubuntu i had installed on there 7 years ago or whatever.

I did, however, make a mistake. I didn't need to use i686 (32 bit) - the atom is a dualcore and on ark it shows that CPU is 64 bit. So i'll probably do all this again (after a reboot onto gentoo boot media and 'dd'ing /dev/sda2 to a network location, just in case). I may even see if it's possible to resurrect pump, because that will speed things up even more. If pump is working, the only thing that sucks about "emerge" on gentoo on a slow machine is waiting for the spinner at the beginning and the "installing ..." parts of the flow, due to memory and CPU contstraints. I'm using an SSD in there so at least i got that going.

Re: Fixing a bug in Google Chrome as a first-time contributor

#92
post #79

>Because of this huge codebase size, I wasn't able to get VS Code's C++ extension to work very well with the project. Features like go-to definition (which I usually rely on heavily when navigating codebases) and find references didn't work well or at all, and one of my CPU cores would stay stuck at 100% permanently while the project was open. Chromium Code Search [1] tool is very helpful with that and I believe ther…

I've been working on an extension https://github.com/phil294/search-plus-plus-vscode-extension for instant search results in gigantic repos like this one because it's a recurring pattern that bothers me. And eventually I'd like it to use its index to provide full go-to, autocomplete etc. on a pure plain text basis, because why not? I don't get the obsession with full-fledged language integration when plain text-based search results can get you all the way 9 out of 10 times, whereas a typical language plugin will constantly suffer from brokenness, performance problems and general annoyance, unless maybe you're working in pure JS/TS. And while LSP is great, you still have to fight this battle separately for every language you use. And regular "search" features are dreadful too.

It's one of these things that Jetbrains products are vastly superior in. It's fast, always works, falls back to text matching and also natively allows multiple languages per source file.

Re: Fixing a bug in Google Chrome as a first-time contributor

#93

Not that I really see away around it, given the size and feature set of Chrome, but those build requirements are just crazy. It kinda throws the open source and "everyone can contribute" model out the window, if you can't afford a pretty insane workstation then you're going to have a bad time. I doubt that Firefox is better, I seem to remember that building Firefox and the VIA C3 processor years back as around half a…

A browser is as complex (more) as an operating system. Building and working on one is just going to require beefy build servers or workstations.

Re: Fixing a bug in Google Chrome as a first-time contributor

#94
post #81
post #79

>Because of this huge codebase size, I wasn't able to get VS Code's C++ extension to work very well with the project. Features like go-to definition (which I usually rely on heavily when navigating codebases) and find references didn't work well or at all, and one of my CPU cores would stay stuck at 100% permanently while the project was open. Chromium Code Search [1] tool is very helpful with that and I believe ther…

First, thank you for sharing this helpful link, but LOL at needing to use a third party server to search plain text data that could fit in RAM (at least on this developer's machine). JavaScript- and JSON-based developer tooling is a terrible idea.

It's not searching plaintext though.

VSCode itself can deal with big text data being thrown at it, this will be some of the language server stuff

Re: Fixing a bug in Google Chrome as a first-time contributor

#95
Excellent. One small question If anyone can answer. When an outside contributor is submitting a fix like these, do open source software maintainers ask for test also to be written? Fix itself is worth acceptance. What if contributor don't have any more time/interest beyond submitting the fix.

Re: Fixing a bug in Google Chrome as a first-time contributor

#96
post #75

Not that I really see away around it, given the size and feature set of Chrome, but those build requirements are just crazy. It kinda throws the open source and "everyone can contribute" model out the window, if you can't afford a pretty insane workstation then you're going to have a bad time. I doubt that Firefox is better, I seem to remember that building Firefox and the VIA C3 processor years back as around half a…

> I doubt that Firefox is better For a long time I would build Firefox from source every morning, and I don't have the build logs anymore but I would guess it was in the range of 60 to 75 minutes. Comparing building anything on a VIA C3 is not serious, nor is using some 5400rpm disk for the same task

I can make a clean build of Firefox in less than 15 minutes on my MacBook Air M2, C++, Rust, and all. If you’re working on a frontend feature that only needs to modify Firefox’s frontend JS code, you can use “artifact builds” (prebuilt object files) so you don’t need to recompile the native code.

Re: Fixing a bug in Google Chrome as a first-time contributor

#97

Congratulations! And thank you for the great write-up. I work with the Chromium code base a lot, and it can indeed be daunting. I use Sublime Text, which treats the code as plain text, apart from syntax highlighting. But it's also possible with at least VS Code to get some more intelligence, such as going to the definition or declaration of a function, etc. People who have now become interested in creating their own…

I haven’t looked too closely at Chrome’s build process but there might be a way to get LSP or something set up for it?

Re: Fixing a bug in Google Chrome as a first-time contributor

#98
post #59

Earlier quoted context omitted.

My solution for a few "bugs considered features" in huge open-source software like Firefox was to just patch the binary. Much easier than figuring out how to build it, and with only the change I wanted.

Do you have experience in disassembling binaries? How do you find the relevant part of the executable, and what tools are you using for this?

The big tools in this space are IDA Pro, Ghidra, and you can cross-reference that with the source code to get what you want.

Re: Fixing a bug in Google Chrome as a first-time contributor

#99

Excellent. One small question If anyone can answer. When an outside contributor is submitting a fix like these, do open source software maintainers ask for test also to be written? Fix itself is worth acceptance. What if contributor don't have any more time/interest beyond submitting the fix.

yes if the standard practice on the codebase is to include tests, the maintainers will ask for tests

if the author doesn't want to do it, the PR will likely remain abandoned unless an external contributor comes along to finish it, or a maintainer takes over.

Re: Fixing a bug in Google Chrome as a first-time contributor

#100
post #70
post #19

Earlier quoted context omitted.

> It kinda throws the how open source and "everyone can contribute" model out the window, if you can't afford a pretty insane workstation then you're going to have a bad time. That, it also means you are going to spend a lot of time on it before you can even attempt to do anything. Overall, there can be a pretty substantial amount of effort involved before you are even ready to make a PR of any kind. Then it remains…

"Patches welcome" vs "patches wanted"[1]. 1. https://www.colbyrussell.com/2013/08/06/patches-wanted.html >

That little snippet doesn't quite provide enough historical context for me to agree or disagree with it.
Post reply on HN