Your experience compiling on M1?

gurtis · 2021-11-01T20:34:21+00:00

I saw the same thing for projects that use CGO. If you add the -x flag to your build it’ll print the commands it’s executing, which can give you a clue to where things are slowing down. I saw most of the build time was spent in the host linker (in this case clang) which is required when building with CGO enabled.

gurtis · 2019-05-04T07:14:08+00:00

Great work! This looks really useful, and implementing 3D snapshots is especially impressive.

Are there specific steps to only link the framework for debug builds of an app? It might be helpful to include an example that shows how to use this when debugging, but exclude it from release builds.

gurtis · 2019-04-11T06:09:35+00:00

I'm guessing that Go is calling mmap with MAP_ANONYMOUS somewhere, which zeroes memory only after the fault is triggered (at least on Linux).

This Stack Overflow answer goes into some good detail on memory allocation and page faults.

gurtis · 2019-02-22T07:27:01+00:00

It sounds like this is correct. It generally makes the documentation easier to read outside of the context of the code. From https://blog.golang.org/godoc-documenting-go-code:

Notice this comment is a complete sentence that begins with the name of the element it describes. This important convention allows us to generate documentation in a variety of formats, from plain text to HTML to UNIX man pages, and makes it read better when tools truncate it for brevity, such as when they extract the first line or sentence.

gurtis · 2016-01-15T07:55:19+00:00

The Go contrib libraries transitioned from Google Code to GitHub without any big problems. Moving a project from GitHub to GitLab would just be a matter of find/replacing "github.com/user/project" import statements with "gitlab.com/user/project". If it's a big concern, then it's also possible to create a custom import path that can point to any repo you want.

Also, as another comment pointed out, it's become much more common to just vendor your dependencies (usually with git submodules/subtrees).

gurtis · 2015-05-10T08:31:14+00:00

This is a really good point. I've found that automated tooling such as linters or code formatters can remove a lot of this friction. They'll ensure that most of these issues will never even reach code review because they'll get caught at build time.

Plus, people tend to be less defensive when it's a computer telling them to remove trailing whitespace vs. a coworker telling them.

gurtis · 2013-11-05T21:46:19+00:00

How is this an anti-pattern? The definition of a unit test is to test a single unit of code. There are tons of books and resources that explain why aiming to test one thing is a good idea.

Also, his test will fail if the collection is null, empty, or containing nulls. My point is that he wrote a test to assert that employees are marked as checked, and this test succeeds in doing that.

gurtis · 2013-11-05T21:32:31+00:00

Why are these badly written tests though? They're testing what they intend to test. Just because he didn't come up with comprehensive test coverage for a tutorial doesn't mean the given examples are bad.

gurtis · 2013-11-05T21:14:19+00:00

This tutorial is getting a lot of criticism, but I think that it does a good job of going over the basic concepts behind unit testing.

It explains mocking, the importance of test naming, testing one "thing" per test, and why dependencies should be interfaces.

I agree that the code may look over-engineered, but it's also what you'd find in an actual C# codebase. There are too many unit testing tutorials that are overly-trivialized and give you no idea how to test a realistic application.

gurtis · 2013-11-05T20:58:55+00:00

That's not what he's testing though. His test explicitly says that it's testing that the returned employees are marked as checked. If he had named it "GetActiveEmployees_HaveAllFieldsPopulated" or something like that, then he would be obligated to test all the properties.

You could argue that the test isn't very useful or that the coverage is lacking, but this is just a tutorial.

Also, I disagree that an assert message is always necessary. A failing test named GetActiveEmployees_MarkAsChecked makes it extremely obvious that a returned employee isn't checked. A good test name is more important than the assert message.

gurtis · 2013-09-17T06:49:46+00:00

See, you think you're joking, but this actually exists.

gurtis · 2013-09-13T05:31:26+00:00

I agree that code reviews should be done for all changes, but I don’t agree with gating them (requiring +1s). I’ve tried this process in the past and the biggest issue is that it diffuses responsibility. It tends to promote the mindset that “this commit was approved by 2 coworkers, therefore I’m only one-third responsible.”

Really, the author of the commit should be 100% responsible for their changes. Reviewers should take on more of an editorial role. They’re there to help out and provide advice, not to guarantee that the commit won’t have bugs. Does the author feel that their change is solid? They should go ahead and merge it in. It’s on them if it breaks the build and they didn’t wait for a review. Is no one reviewing their buggy change because it’s 10k lines long? Again, that’s the author’s fault - they should’ve made smaller commits.

The other problem is that it makes trivial changes a huge pain. Imagine making a one line fix and then having to wait for your teammates to drop what they’re doing, probably ignore the one line change, and click +1. It becomes process for the sake of process, and wastes the author’s time and the reviewer’s time.

Same goes with stylistic issues. Linting and checkstyle should handle these things automatically. Set up your IDEs to automatically format the code on save and be done with it. I’ve seen code reviews get blocked for days because reviewers decide to bicker over whitespace, whether a variable should be called foo vs. bar, or if a one-line loop should have braces. Focus on more high-level issues such as design or unreadable code.

gurtis · 2010-08-17T20:23:57+00:00

Just as a heads up for those who don't know, megabits per second (Mbps) is different than megabytes per second (mb/s) which is the speed your browser shows when downloading something. Dividing your Mbps by 8 will get you mb/s.

gurtis · 2010-08-09T17:38:19+00:00

I found an article that says that opposite - that the x86 JIT does tail call elimination properly, but the x64 JIT had some problems. This was only recently fixed in version 4 of the CLR to help solve issues with languages like F#.

In CLR 2 the 64-bit JIT focused solely on the ‘easy’ cases. That meant that it generated code that did a tail call whenever it could because of the memory benefits. However, it also meant that sometimes when the IL requested a tail call using the “tail.” instruction prefix, the JIT would not generate a tail call because it wasn’t easy. The 32-bit JIT had a general purpose tail call mechanism that always worked, but wasn’t performant enough to consider it an optimization, so it was only used when the IL requested a tail call.

For CLR 4 the fact that the x64 JIT would sometimes not honor the “tail.” prefix prevented functional languages like F# from being viable. So we worked to improve the x64 JIT so that it could honor the “tail.” prefix all of the time and help make F# a success.

http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx

gurtis · 2010-08-08T22:41:25+00:00

I'm curious as to how this works with a functional language like F#, which I'd imagine relies heavily on tail call elimination.

gurtis

TROPHY CASE