The difference is indeed that users of VPython (not me!) have no involvement with C/C++, and no involvement with any kind of compiling. Almost all of the VPython C++ code is platform-independent, thanks to use of OpenGL, with no use of DirectX, and as I've said, the platform-dependent code (make a window, handle events) has been rock-solid for 12 years on all versions of Windows (7 of them). During that time there were repeated problems with Mac and Linux. Maybe another difference is that in your textbook, Ed, handling events is a rather minor issue, so that for example Carbon/Cocoa issues probably haven't mattered?
Changes in the Visual Studio compiler have not been a problem until just a couple of months ago, when I had to do quite a bit of work to keep going. The problem is that one has to compile a C++ module for Python X.Y using the same compiler that was used to build that version of Python. In the case of 64-bit Python on Windows, that compiler is a rather old version of Visual Studio which required arcane edits of various Visual Studio configuration files on my machine. Bruce On Fri, Feb 8, 2013 at 9:02 AM, Edward Angel <an...@cs.unm.edu> wrote: > Although it might seem that I would have a similar view as Bruce since we > both support 3D graphics for educational purposes, my experience is exactly > the opposite of Bruce's. I have to support thousands of mostly CS students > and various professionals every year. Windows is an absolute nightmare for > me to support with somewhat linux behind that. I have never had a problem > on a Mac that wasn't my own error. > > Maybe the difference is that the majority of my users use C/C++. > Incompatible versions of DirectX, changes in Visual Studio, coupled with > driver issues from third party graphics boards and dealing with 32 and 64 > bit architectures makes it almost impossible to give a single set of > instructions on how to get an OpenGL program running. If I get someone > going on a 32 bit build, that may not work for 64 bits on the same machine. > We even had to add a line in one of our libraries that sets a single > element of a small array to 0.0 because of a driver bug in an AMD driver. > > The problems with linux have usually been simpler to deal with, usually > involving where each one puts the "standard" libraries or how they are > named. > > I used to recommend and do my own development using linux under Windows > but that got worse with problems of dealing with dynamic vs dynamic > libraries. > > If I didn't have to do so much support for my textbook and was only doing > my own work, then there would be some attraction to Windows such as the > ability to access the latest hardware. Apple sometimes infuriates me by its > slowness hand secrettness in keeping up with graphics standards but when > they do upgrade, the software is correct and works across their hardware > and versions of OSX.. > > Ed > __________ > > Ed Angel > > Founding Director, Art, Research, Technology and Science Laboratory > (ARTS Lab) > Professor Emeritus of Computer Science, University of New Mexico > > 1017 Sierra Pinon > Santa Fe, NM 87501 > 505-984-0136 (home) an...@cs.unm.edu > 505-453-4944 (cell) http://www.cs.unm.edu/~angel > > > On Feb 8, 2013, at 8:32 AM, Bruce Sherwood wrote: > > I'm not claiming that Windows has all the answers for all possible goals. > What I am pointing out is that in the case of a quite non-trivial > application there has been remarkable stability that has been missing from > both Mac and Linux environments. I haven't seen Microsoft being given > credit for this, and it's not unimportant. Clearly someone at Microsoft has > thought it important that applications continue to work. > > Concerning graphics, with each new release of Ubuntu I find it easy or > difficult to install a proprietary graphics driver without which even > simple 3D can fail. As for the Mac, a couple years ago World of Warcraft > was broken on the Macbook Pro for something like a year and a half because > the graphics driver had been tweaked to cater to some iProgram, and there > was no way to upgrade the driver, given the closed Mac environment. > > What I'm objecting to is the facile assumption in computer-savvy circles > that "obviously" Windows and Microsoft are hopeless (roll the eyes). That's > not the whole story. > > Bruce > > > On Thu, Feb 7, 2013 at 11:22 PM, Marcus G. Daniels > <mar...@snoutfarm.com>wrote: > >> On 2/7/13 10:54 PM, Bruce Sherwood wrote: >> >>> To repeat, Windows for my 3D graphics development purposes has been far >>> more stable than either Mac or Ubuntu Linux. >>> >> Windows is the biggest market for gamers. 3D innovation has historically >> always been first on WIndows. >> If all you want a computer to do is a fixed set of 2d and 3d graphics >> APIs, then, sure, use Windows. But performance and stability are only two >> dimensions. >> >> I care much more about flexibility than stability or graphics >> performance. For example, I want to use GPUs for accelerated computation. >> It is inappropriate in my situation to code using unportable (CUDA) or >> crudely simple APIs like OpenCL. That's no way to write complex, >> long-lived, maintainable software. It could be a way to write simple, >> static, scientific codes that perform on particular cards, if that's all >> you need to do. I want the possibility of *some* acceleration over >> generations of cards, not peak performance for one generation. >> >> AMD GPUs on Linux now have the driver bits (in Mesa, a free OpenGL) and >> compiler bits in LLVM (a free compiler). Together there's now the >> possibility of integrating real compilers with accelerator technology. On >> Windows, this kind of integration and experimentation is not possible. >> >> Now fast forward to the day this all just works. Someone writes a code >> using these compiler tools, but, oops there's a strange anomaly in a >> particular calculation. How do you fix it? Get your favorite bloggers >> to complain in a public setting? No thanks, I want direct control. >> That means source code. >> >> Marcus >> >> >> ==============================**============================== >> FRIAM Applied Complexity Group listserv >> Meets Fridays 9a-11:30 at cafe at St. John's College >> to unsubscribe >> http://redfish.com/mailman/**listinfo/friam_redfish.com<http://redfish.com/mailman/listinfo/friam_redfish.com> >> > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com >
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
