Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cprimozic.net

Post reply on HN
Print view View original

121–130 of 170 posts

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

#121

Post by mdaniel »

cpeterso wrote: post #96
mdaniel wrote: post #75

Earlier quoted context omitted.

> 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.

> less than 15 minutes ... Rust, and all

Wow, your rust experience is way different from mine (not just FF, I mean invocations of rustc are where time goes to die). I also readily admit that I struggled constantly with trying to get sccache to behave sanely, so I'm open to that being part of the difference, too

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

#122

Post by dieortin »

kllrnohj wrote: post #105
mrweasel wrote: post #15

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…

16 core CPU, 64GB RAM, and 100GB of storage is definitely not a budget build, but I don't really see how that would be a "pretty insane workstation", either. That's firmly in consumer space these days and has been for a few years. But that's also not a requirement , either, that's just what it took for a 40 minute clean build time.

Those requirements exceed what 99% of developers have, so I would agree that a workstation with those specs is pretty insane.

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

#123

Post by progmetaldev »

phil294 wrote: post #92
macqm wrote: 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…

Sounds really interesting, and useful for most developers. I think the issue is probably more what people have read about edge cases, than what it's actually like to use an extension like you are building. People tend to worry that they will hit the edge case and not realize it, so completely avoid anything that might give them faster results in the name of 100% accuracy that they will probably never hit. In a typed language, I would think that it would be extremely rare to search and make the type of changes that would be missed in that edge case, and the code still compiles without issue. Maybe I just haven't worked on large enough codebases, or ones that are full of "magic" where such a thing would create such an issue.

Regardless, I think it's impressive that you've taken on this task and are sharing it with the VSCode community, and appreciate you sharing.

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

#124

Post by quirino »

oops wrote: post #113
quirino wrote: post #58

There's this one Chrome (?) bug I've been experiencing for a long time on Linux. Every once in a while, the browser detects I'm typing "±±±±±±+..." and writes that to any selected text input. It stops when I type anything, but sometimes comes back rather quickly. I thought it was a keyboard issue, but it doesn't affect Firefox or other applications, only Chrome based ones like Spotify and VSCode. I've found no other…

> I've found no other mention of this on the internet Here's one! (different character, but same issue it seems?) https://www.reddit.com/r/linuxquestions/comments/1cbarz5/ele... > and I'd love to to hunt this down and fix it but have no clue where to start. I guess the first step would be to consistently reproduce the bug... I am not familiar with Chromium at all, and I also don't run Linux on the desktop as I'm gues…

Thank you so much for all these pointers!

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

#125

Post by n_plus_1_acc »

mirekrusin wrote: post #14
matrss wrote: post #8

Earlier quoted context omitted.

> That said, I usually prefer the changing bit at the end. So something like GlobalScopeForWorker, GlobalScopeForWorklet. But then that's clunky, so we're back at WorkerGlobalScope and WorkletGlobalScope again. I wouldn't necessarily call "GlobalScopeForWorker" more clunky than "WorkerGlobalScope", just a bit longer, but also more descriptive. Using the languages namespacing features might also make it more obvious,…

„Of” is underused in programming. It’s short, can appear standalone, as prefix, infix and suffix and it’s generic enough that it works in most contexts for types, type functions, functions, constructors, mappings etc.

When Java introduced List.of(1, 2, 3), I was sceptical but now I like it

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

#126

Post by koyote »

kllrnohj wrote: post #105
mrweasel wrote: post #15

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…

16 core CPU, 64GB RAM, and 100GB of storage is definitely not a budget build, but I don't really see how that would be a "pretty insane workstation", either. That's firmly in consumer space these days and has been for a few years. But that's also not a requirement , either, that's just what it took for a 40 minute clean build time.

I'd argue that it's not the 'default' workstation most developers who do not have specific requirements will be running, especially on the RAM side.

My personal machine is very mid-spec'ed because my personal projects are all small and don't really require much.

Even my work machine tops out at 32Gb RAM which has always been plenty, even for our comparatively large codebases (although more is always welcome :)).

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

#127

Post by kllrnohj »

koyote wrote: post #126
kllrnohj wrote: post #105

Earlier quoted context omitted.

16 core CPU, 64GB RAM, and 100GB of storage is definitely not a budget build, but I don't really see how that would be a "pretty insane workstation", either. That's firmly in consumer space these days and has been for a few years. But that's also not a requirement , either, that's just what it took for a 40 minute clean build time.

I'd argue that it's not the 'default' workstation most developers who do not have specific requirements will be running, especially on the RAM side. My personal machine is very mid-spec'ed because my personal projects are all small and don't really require much. Even my work machine tops out at 32Gb RAM which has always been plenty, even for our comparatively large codebases (although more is always welcome :)).

RAM is cheap and easily upgraded after the fact, though. Going from 32gb to 64gb is $100

I certainly wouldn't spend that for a one-off patch to an open source project, but if you're doing this regularly it's not exactly a steep upgrade either

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

#128

Post by SAI_Peregrinus »

ivanjermakov wrote: post #85
SAI_Peregrinus wrote: post #68

Earlier quoted context omitted.

Yep. Debuggers are more powerful , they can do everything `printf` debugging can do + more, but take more work to set up. For interpreted languages, they often take more work to use than just adding a print statement & rerunning, for compiled languages the reverse is more likely.

There are cases where printf helps but debugging doesn't. Multithreaded code is one of such cases.

Conditional breakpoints that run a script and continue can be used equivalently to printf debugging, just set it to print when the selected line is hit. You can do this without restarting the application, even for multithreaded code.

Also watchpoints, for the equivalent but at a memory location instead of a code line.

Debugger != breakpoints.

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

#129

Post by kllrnohj »

dieortin wrote: post #122
kllrnohj wrote: post #105

Earlier quoted context omitted.

16 core CPU, 64GB RAM, and 100GB of storage is definitely not a budget build, but I don't really see how that would be a "pretty insane workstation", either. That's firmly in consumer space these days and has been for a few years. But that's also not a requirement , either, that's just what it took for a 40 minute clean build time.

Those requirements exceed what 99% of developers have, so I would agree that a workstation with those specs is pretty insane.

~5% of steam users have 16 core CPUs & 22% are more than 8 cores: https://store.steampowered.com/hwsurvey/cpus/

No idea where you're pulling your 99% figure from, but it seems quite unlikely.

Regardless, if compiling Chromium or similar large code bases is a thing you want to do regularly, it's unlikely to present a significant burden.

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

#130

Post by mananaysiempre »

henning wrote: post #102
coldpie wrote: post #84

Earlier quoted context omitted.

I'm sure it can do a plaintext search just fine. What the author is talking about is language-aware features like "go to definition". Holding all of a whole web browser's C++ parsing tree in memory is a lot bigger ask than just its plain text.

You're assuming that the only way to a definition of an identifier is 1) parse the entire source tree 2) keep the entire source tree in memory 3) use that in-memory source tree to go to definition. If you accept those constraints and then implement in a slow language, then yes, it won't work.

You’re rather underestimating the vast expanse that is the Chromium codebase, I think. That said, distributing tags files was a common thing once, and a dedicated symbol package you could just download and feed into your language server (instead of being constantly tethered to a symbol server) could make for a nice affordance today.
Post reply on HN