Has anyone managed to apply this download to a Visual Studio.NET 2003 Standard installation, to get the benefits of an optimizing compiler?
Standard edition disables the optimizing compiler. You have to pay for Professional edition to get the optimizer. Being cheap, and not needing all the.NET crap in Professional addition, I bought Standard edition. Now it seems MS is giving away the optimizing compiler. But how to enable its use from within Visual Studio? has anyone figured out a way to do this?
I recently went looking for an open source parser generator and had the following experience:
I found a terrific project called "Spirit" that had a well-developed parser framework for C++ programmers (exactly what I wanted). The community was large enough to provide lots of support and rapid evolution of the code, but small enough to be responsive to my input.
I experimented and found some things about the framework I didn't think were quite right. I offered criticism, argued for my point of view, and suggested changes. Some were made, gracefully. In this way I made minor contributions (very minor), so I was not entirely free-riding.
I learned a lot about parsers, and C++ template expressions (the implementation vehicle Spirit uses).
I found Spirit generated parsers that were too bulky for my application. The community was not immediately repsponsive in correcting this defect when I mentioned it (they have many fish to fry), and I judged it might be a while before it bothered others as much as it bothered me (it was a show-stopper in my case).
I began to suspect that Spirit was more of a research project in the applications of C++ templates than an optimal parser. But hey, I had learned enough from it to write my own parser framework.
I wrote my own parser framework, simplifying the approach taken by Spirit's developers and focusing on a minimalist solution to my particular requirements (which were still of a general-purpose nature, i.e. I needed a general parser/generator framework that could be used directly from C++). I did not fork the Spirit source, I wrote my own from scratch, but my experience with Spirit certainly inspired it. I took the oppoirtunity to "fix" everything that irked me about Spirit, and I left out everything I didn't need.
I intend to open source the results after I have got some experience using and tuning it. Whether anyone else will use it remains to be seen.
My experience is probably not typical, but it may be representative. When a programmer adopts an open source component for his use, he *gets involved*. This inevitably leads to one of three things (or all three): criticism and contributions to the discussion (a valuable form of contribution in its own right); actual code contributions to "fix" what he doesn't like or wishes were better; or a fork or competing project to address a need not met by the original.
Perhaps it's as simple as this: programmers build things. That's their modus operandi. If you build something, they will come -- and tear it all apart, rebuild it in their own image, or imitate it.
If this is free riding, it is what artists of every stripe have always done. There is no real danger from free riders where artists are concerned, because they are (by definition) motivated to be creative and productive. There is every likelihood that your effort will be imitated, copied, morphed and expropriated -- but not merely stolen and devalued by individuals who do nothing with it. No programmer can resist peeing in the open source soup until he gets a flavor he likes.
It is important to distinguish such participation from the kind of free riding that destroys a commons. As long as everyone changes what they find a little bit, nothing is destroyed -- on the contrary, every such contribution enriches the whole culture.
I like a Renaissance man, however. More power to him for venturing into economic theory. I think he did it pretty well. When only accredited "experts" speak, the subject suffers from too much conventional thinking.
I like this characterization of software production as a cottage industry. (Maybe because I program in a cottage.) Over 25 years as a programmer I have witnessed the unending quest by management types to deskill the software engineering process -- unsuccessfully. The cottage industries that the industrial revolution wiped out fell victim to the possibility of deskilling them. Let's hope software proves to be an art form, like music or writing, that endures all attempts to make it an assembly-line process. To that end, we have to be careful in our choice of tools -- are they designed to unleash our creativity and automate tedious tasks, or do they simply impose management strictures and create new forms of tedious work? Similarly, the architectures and platforms we buy into. At least as open source developers we generally get to choose (and build) our own tools.
Do we want to open the door to a raft of laws specifying criminal penalties for misuse of protocols? Could a law prescribing jail time for "falsifying routing information" be used to lock up hackers, or someone experimenting with or in contention with internet "authorities", or perhaps subversives the prosecutors wanted to silence, based on technical violations that had nothing to do with spamming? Criminalizing *any* use of protocols is a very dangerous idea -- it's inviting the government into an arena where "enforcement" has always been by consensus, not by the FBI. Not only could this law threaten free speech, it could make the the net a dangerous place to experiment with protocol variations, and set the precedent for even more dangerous laws. Making good law is all about avoiding bad precedent. In China, they just jailed an internet dissident for releasing a list of email addresses. No doubt they will claim it's just to protect citizens from spam! As usual, the ACLU is more farsighted than its shoot-from-the-hip critics on this one. If Jews in Skokie have to live with Nazis marching down main street (and they do, thanks to the ACLU), then we may have to live with spam. Civil liberties are cheap at such a price -- be glad you can still purchase them at any price.
Slashdot Mirror
Has anyone managed to apply this download to a Visual Studio .NET 2003 Standard installation, to get the benefits of an optimizing compiler?
.NET crap in Professional addition, I bought Standard edition. Now it seems MS is giving away the optimizing compiler. But how to enable its use from within Visual Studio? has anyone figured out a way to do this?
Standard edition disables the optimizing compiler. You have to pay for Professional edition to get the optimizer. Being cheap, and not needing all the
I recently went looking for an open source parser generator and had the following experience:
I found a terrific project called "Spirit" that had a well-developed parser framework for C++ programmers (exactly what I wanted). The community was large enough to provide lots of support and rapid evolution of the code, but small enough to be responsive to my input.
I experimented and found some things about the framework I didn't think were quite right. I offered criticism, argued for my point of view, and suggested changes. Some were made, gracefully. In this way I made minor contributions (very minor), so I was not entirely free-riding.
I learned a lot about parsers, and C++ template expressions (the implementation vehicle Spirit uses).
I found Spirit generated parsers that were too bulky for my application. The community was not immediately repsponsive in correcting this defect when I mentioned it (they have many fish to fry), and I judged it might be a while before it bothered others as much as it bothered me (it was a show-stopper in my case).
I began to suspect that Spirit was more of a research project in the applications of C++ templates than an optimal parser. But hey, I had learned enough from it to write my own parser framework.
I wrote my own parser framework, simplifying the approach taken by Spirit's developers and focusing on a minimalist solution to my particular requirements (which were still of a general-purpose nature, i.e. I needed a general parser/generator framework that could be used directly from C++). I did not fork the Spirit source, I wrote my own from scratch, but my experience with Spirit certainly inspired it. I took the oppoirtunity to "fix" everything that irked me about Spirit, and I left out everything I didn't need.
I intend to open source the results after I have got some experience using and tuning it. Whether anyone else will use it remains to be seen.
My experience is probably not typical, but it may be representative. When a programmer adopts an open source component for his use, he *gets involved*. This inevitably leads to one of three things (or all three): criticism and contributions to the discussion (a valuable form of contribution in its own right); actual code contributions to "fix" what he doesn't like or wishes were better; or a fork or competing project to address a need not met by the original.
Perhaps it's as simple as this: programmers build things. That's their modus operandi. If you build something, they will come -- and tear it all apart, rebuild it in their own image, or imitate it.
If this is free riding, it is what artists of every stripe have always done. There is no real danger from free riders where artists are concerned, because they are (by definition) motivated to be creative and productive. There is every likelihood that your effort will be imitated, copied, morphed and expropriated -- but not merely stolen and devalued by individuals who do nothing with it. No programmer can resist peeing in the open source soup until he gets a flavor he likes.
It is important to distinguish such participation from the kind of free riding that destroys a commons. As long as everyone changes what they find a little bit, nothing is destroyed -- on the contrary, every such contribution enriches the whole culture.
You're right. My error, sorry.
I like a Renaissance man, however. More power to him for venturing into economic theory. I think he did it pretty well. When only accredited "experts" speak, the subject suffers from too much conventional thinking.
I like this characterization of software production as a cottage industry. (Maybe because I program in a cottage.) Over 25 years as a programmer I have witnessed the unending quest by management types to deskill the software engineering process -- unsuccessfully. The cottage industries that the industrial revolution wiped out fell victim to the possibility of deskilling them. Let's hope software proves to be an art form, like music or writing, that endures all attempts to make it an assembly-line process. To that end, we have to be careful in our choice of tools -- are they designed to unleash our creativity and automate tedious tasks, or do they simply impose management strictures and create new forms of tedious work? Similarly, the architectures and platforms we buy into. At least as open source developers we generally get to choose (and build) our own tools.
Do we want to open the door to a raft of laws specifying criminal penalties for misuse of protocols? Could a law prescribing jail time for "falsifying routing information" be used to lock up hackers, or someone experimenting with or in contention with internet "authorities", or perhaps subversives the prosecutors wanted to silence, based on technical violations that had nothing to do with spamming? Criminalizing *any* use of protocols is a very dangerous idea -- it's inviting the government into an arena where "enforcement" has always been by consensus, not by the FBI. Not only could this law threaten free speech, it could make the the net a dangerous place to experiment with protocol variations, and set the precedent for even more dangerous laws. Making good law is all about avoiding bad precedent. In China, they just jailed an internet dissident for releasing a list of email addresses. No doubt they will claim it's just to protect citizens from spam! As usual, the ACLU is more farsighted than its shoot-from-the-hip critics on this one. If Jews in Skokie have to live with Nazis marching down main street (and they do, thanks to the ACLU), then we may have to live with spam. Civil liberties are cheap at such a price -- be glad you can still purchase them at any price.