51–60 of 124 posts
I went to the weekly tech lead meeting, and when it was my turn to talk, I said: "I think we should increase out internal NuGet package release interval to every 18 hours. F--k the Police!"
People just looked at me weird.
Earlier quoted context omitted.
i'm glad someone who works at the company like you was able to enlighten us as to microsoft's internal practices oh wait
Apply some common sense, you think they let MS employees just commit to any codebase they like? And this is leaving aside all the annoying steps of locating their repository, figuring out how to build it, testing, finding out the right person to send the patch to, going through code review.
The only difference is that you can see the source and test on your own machine first.
MS employees don't have to commit to any codebase they like, but they should be able to obtain the actual source, so that "with enough eyes, all bugs are shallow".
The real news here is that this is considered special. In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch. I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit…
http://referencesource.microsoft.com/#System.Core/Microsoft/...
Earlier quoted context omitted.
> and still chose the hard way Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.
From good source here: You don't actually jump through hoops. All you get to do is submit the bug, which gets logged in the bucket of thousands of other bugs. Then the PMs will gather for bug triage for the next release, which have to compete with the next shiny project features. Nobody wants to fix bugs that only one developer has. It's just not worth it. This bug has existed for years, and it is likely you could mo…
This is an interesting cognitive hazard: it's relatively easy to measure the cost of paying a developer to fix a bug and possible to estimate the cost of getting it wrong but there's no way to measure the cost to everyone who encountered it but never did the work to reduce it to a testcase and file a bug report.
Worse, it's very hard to measure the cost of people who choose to use something else. Repeat that cycle a few times and a fairly high percentage of the people you will hear from are in the “never change anything less than critical” camp.
The real news here is that this is considered special. In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch. I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit…
It's not that special, and they took one hell of a circuitous route to fix their bug. You can download the source and view the bug here: http://referencesource.microsoft.com/#System.Core/Microsoft/...
We actually chose the most expedient route. The reason is, the source you link to is not actually the source of the DLL we were working with. That particular file is very similar, but the rest of the repot is very much different from the version we were working on. (I work at MS, and our project is kind of exotic in this case.)
The history of ET compiler: it started with LINQ in .NET 3.5. Originally it was pretty simple and just handled expressions. In .NET 4.0 we merged the entire codebase with the IronPython/IronRuby compiler trees, expanding the "expression trees" to handle statements. IIRC, it can generate almost any IL construct that you might need, and is usually a lot easier to work with. But we found .NET's runtime compiler (DynamicMethod) was a bit too slow for a lot of use cases. It also wasn't supported on some CLR configurations. To address this we wrote an interpreter and some heuristics to switch from interpreted to compiled. But the actual System.Linq.Expressions.Interpreter must have happened after 4.0, because I don't remember that at all. Instead we just shipped it as a shared library used by IronPython and IronRuby.
Here's the normal ExpressionQuoter: https://github.com/IronLanguages/main/blob/7be8b73e246bfb029...
And here was the interpreter. I don't see the ExpressionQuoter, so either that's a newer fork of the code that was rolled into System.Core, or maybe a completely new implementation. https://github.com/IronLanguages/main/tree/master/Runtime/Mi...
IIRC, ExpressionQuoter was mainly to support the Quote expression, and was always a bit buggy. The 3.5 version was seriously messed up, and our prerelease versions of .NET 4.0 also had various bugs, and very few tests. I tried to fix it by having it use the same reuse closure mechanism as the normal compiler. Funny that same feature caused issues later on.
[1] one might wonder: why use StrongBox, essentially boxing every parameter, rather than just generating a type with only the right fields? The reason was that generating a type in .NET 4.0 timeframe was absurdly slow. Like, a few hundred per second slow. I think this has been largely fixed now, but it was a huge performance problem for Iron* language runtimes back in the day
Earlier quoted context omitted.
They do, but interestingly that particular assembly is not included. Or at least I couldn't find it there.
The namespace appears to have changed or something, I found it here: http://referencesource.microsoft.com/#System.Core/Microsoft/... Note: also MSFT employee, don't work on .NET though.
I work at MS, and we're using a slightly exotic version of this DLL. Please pardon the differences. :)
Earlier quoted context omitted.
> Well, GCC is next-to-impossible to compile for a target other than the host, especially if the target isn't x86 or ARM; You're exaggerating. I had no problems compiling gcc 3.something targeting MIPS-I on an x86 Linux host.
I can't tell if you're being sarcastic. Generally, compiling GCC to target another architecture involves not only recreating most of the root directory structure (notably include files) of the target on the host, but also compiling libc, bintools, and a few other more obscure libraries. And this all needs to be done in the correct order (which involves something like compiling half of libc before compiling GCC, and c…
Sidebar: I haven't done deep C# in several years, since moving to F#. This code is getting to look butt-ugly. It is not a good thing if it continues like this. We already have C++. Don't need another one.