Every CRT is equipped with a little projector that can focus light onto the user's face. Either that or light rays emitted in all directions from the CRT magically bend themselves to focus on the face 15" in front of the screen.
That one really irks me. It's not like it really even adds that much to the dramatic impact to have "C:\>" go scrolling by on the hero's nose. It just looks dumb.
Unfortunately many of the papers about things like FFT and multigrid on GPU actually run slower on GPU than CPU. But the argument is that the performance of GPUs is growing so rapidly (aka "Moore's law squared") that before too long they will run faster on the GPU. The new NV40/R800 class of GPUs may have already tipped the scales. The ability to now read textures from within vertex programs and branching instructions should also allow some algorithmic improvements to be made to some GPGPU techniques.
And what if you're editing an armature? Doesn't work there. What about when you're editing texture coordinates. Doesn't work there does it? Undo for meshes is great, but there are quite a few other places where it sure would be handy.
People share their ideas and publish, because if they don't they don't get tenure or graduate or whatever. But there's often a big development investment involved in going from some paper published in a journal to working code. The published paper may give you the major differences between what they've done and the previous work, but most any important achievement builds on a bunch of prior work which is, say, contained in 5 other papers, which in turn were each based on 5 other papers each, and tracking all that down and getting it and translated into code can take a long time.
So say I'm the guy who published the paper -- while you're spending all your time re-implementing my previous method, I've already gone on and developed another few enhancements or a whole new method, and gotten another paper or two out of it, while you're still trying to recreate what I did last year.
So basically, just because the ideas in academia are basically open, that doesn't mean the implementations are. In fact, I've heard some math guys voice the opinion that releasing your source code is just a waste. It takes a significant time investment on your part to get it all packaged up, perhaps cleaning up the code some, and then to answer questions people have about it etc. And when it comes time for tenure review, they don't ask you how much source code you released. No, all that matters is how many journals you published in. So while you were busy cleaning up your source code for release, fixing non-critical bugs and adding non-essential features, you could have been working on the next publication instead.
Of course a lot of researchers do go all the way with openness and release source. But I've seen plenty of both strategies.
Another part of the equation is that Universities these days all want a piece of the action on anything invented within their walls. So they want you file for patents and such, and try to find people that will license those patents. And naturally a big cut of the licensing fees go to the Universtity. And then there's folks who dream of starting their own multi-million dollar spin-off technology company, so they don't want to let too many details about what they're doing to leak out until they've got all the patents lined up.
JV: Let's say there are a thousand. But there are 284 million people in this country. You can't have public policy that is aimed at 100,000 people when the other multi-multi-millions are also involved. You can't do it that way.
Yeh, that's a good point. Here's another -- how many people are in wheelchairs out there? It's not *that* many. In fact I don't know anyone in a wheelchair. So why should we have public policy aimed specifically at those people when there are multi-multi-millions of us who aren't crippled? It's another case, just like Skippy Valenti said, where You can't do it that way. To hell with the ADA. Those folks in wheel chairs should go buy their own damn ramps if they want to get into buildings. And tell 'em Jack sent ya!
Yeh, 3D what? The comparisons they make are meaningless because there is no agreed upon meaning of "3D model".
Look at MP3 - A format for specifying a fixed, sampled 1D data stream. Look at JPEG - A format for specifying a fixed, sampled 2D data stream. and I'll throw in MPEG - A format for specifying a fixed, sampled time sequence of sampled 2D data (or 3D sampled data if you want to thing of it that way)
All of those are relatively well defined problems. The output of the decoder is essentially either a 1D array of samples (audio), a 2D array of samples (image pixels), or a 3D array of samples (video). All of those are very well understood and very standardized in terms of meaning.
U3D - What does it encode? It's not clear. Probably the most direct analogue to the MP3 and JPG cases would be that given a U3D file you should be able to generate any 3D view of the model. A view is basically a 2D image, and you can place the camera anywhere in 3D space, and you can rotate the camera about 3 axes. Add it all up you're talking about an 8D dataset. Now using a little clever reordering you can reduce that to 5D, and what's usually called the "plenoptic function" (6D if you include time as a dimension as well, for animation), but it's still an open problem as to how to encode all that info into a reasonable sized file. So we don't. We use cheats. We explicity define triangles that approximate particular surfaces in the scene. We assign them colors. We define material properties like specularity. We assign them textures. We assign them multiple textures. But we want better, more realistic images, so that we can make something that looks like brushed metal. Or refracts like glass. Or whatever. So now we have things like register combiners to allow prettier rendering, then we get pixel shaders. And pixel shaders 1.2, and 1.3, and 1.4, and 2.0. Etc. And there will be a pixel shader 3.0 I'm sure and so on. And then there are full surface BRDF descriptions, and all the many ways to encode that efficiently like the LaFortune model or spherical harmonics and whatnot. And we're definitely not done yet. All these things go a long way to capturing a lot of the high-order terms of the plenoptic function, but it still doesn't give you a way to encode any specific 2D view from any position in space.
The point is that 1D and 2D -- even 3D -- sampled data are simple. It's just a bunch of samples. As soon as you move into describing 3D scenes you we're talking about much higher-dimensional data, and the exhaustive sampling approach breaks down. So you have to make a lot of assumptions, and use a lot of tricks, and people are still inventing the tricks. And some assumptions are useful to some people, like game designers, but completely inappropriate for others, like medical technicians. MP3s use tricks too, but the output is almost indistinguisable from the original audio for most people, same with JPEGs and a photograph. That's because sampling in low dimensional spaces is really well understood, and the raw data size isn't really that big to begin with.
My point is that it's going to be a while before we can represent 3D generically in a way that is basically indistinguishable from reality. And that is universally useful as mp3 is to audio, and Jpeg is to images. Until then we'll continue to use various appearance models like Blinn-Phong specularity, and continue to develop newer and better ones. And each one requires that the decoder know how to handle that appearance model. And may require some particular kind of hardware support, like pixel shader 2.0.
For the time being there just isn't a way to specify a 3D model that's universal. The whole idea is just silly. I don't see this being anything other than another VRML. Useful maybe, but nothing at all like Mp3 or Jpeg. The comparison is just dumb.
That's why we have so many model formats in the first place. Some people just need a plain list of triangles. CAD people need data described
What's the problem? The problem is that they've taken a perfectly good word and used it to describe something that it is not. Yes it's just terminology, but all I'm saying is it's a stupid name, and there was no reason not to continue calling it a "workspace". At least "workspace" was a made up word to which they are free to assign whatever meaning they wish, since they made it up.
I guess the thing that really irks me about the name "solution" is that it almost makes sense. It's so close to making sense that I want to interpret it literally, like the code I need written is the problem and the solution is contained in a "solution" file. But the "solution" file doesn't contain the solution to my problem most of the time. Like for instance when my code doesn't even compile yet. That's hardly a solution. Or maybe I should interpret it as the solution to the problem of building my application. The build configuration problem. But the most difficult bits of the build problem are contained in the project files. The "solution" file is just a glorified list pointing to several projects. So it doesn't really make sense to think of it as the solution to the build problem.
And I can't think of any other context in which it could be the solution. So it just bugs me, ok.
I think we need to think of a new interpretation of the.sln suffix. From this day on, I declare that it's is no longer a "solution" file -- instead.sln will stand for a "sirloin" file. Yes, that's it. It's the file that contains the meat that makes up your application. The sirloin file. That's what it is. Ok, now I'm happy. Maybe I'll even upgrade to VC7 now that I can use these cool new sirloin files.
Ok. I gave this a try, and it doesn't work for me. It compiles, but the debugging information is apparently in a different format from what Visual Studio 6 is expecting. And I have the Platform SDK also. Updated that a month or so ago.
See this post. So Mr. AC, were you able to debug as well? If so please tell us your secret sauce to get it working.
Ok, I gave it a try, the new free compiler with VC6 IDE. It seems to compile and run ok. But debugging doesn't work.
The new link.exe complained that it doesn't know the/pdbtype flag. It still ignored it and linked ok, but when I went to debug, VC6 said the exe didn't have any debugging symbols. I've tried changing the debugging options in VC6 a few different ways (C7 compatible, no program database etc), but nothing I've tried makes the debugger happy.
So it looks like this may not be something that will work as well as one might hope, unless anyone has any other ideas.
There could be switches whose meanings have changed slightly, but I just ran the two versions of "cl.exe/?" and compared the output of the two. Here's the list of differences:
OPTIONS THAT WERE IN VC6 BUT AREN'T IN VC7 cl.exe:
/GD optimize for Windows DLL /noBool disable "bool" keyword
NEW VC7 cl.exe OPTIONS:
/AI<dir> add to assembly search path /FU<file> forced using assembly/module /Fx merge injected code to file /G7 optimize for Pentium 4 or Athlon /GH enable _pexit function call /GL[-] enable link-time code generation /GS enable security checks /GT generate fiber-safe TLS accesses /QIfist[-] use FIST instead of ftol() /RTC1 Enable fast checks (/RTCsu) /RTCc Convert to smaller type checks /RTCs Stack Frame runtime checking /RTCu Uninitialized local usage checks /WL enable one line diagnostics /Wall enable all warnings /Wp64 enable 64 bit porting warnings /Y- disable all PCH options /Yl[sym] inject.PCH ref for debug lib /Zc:arg1[,arg2] C++ language conformance, where arguments can be: forScope - enforce Standard C++ for scoping rules wchar_t - wchar_t is the native type, not a typedef /arch:<SSE|SSE2> minimum CPU architecture requirements, one of: SSE - enable use of instructions available with SSE enabled CPUs SSE2 - enable use of instructions available with SSE2 enabled CPUs /clr[:noAssembly] compile for the common language runtime noAssembly - do not produce an assembly /showIncludes show include file names /w<l><n> set warning level 1-4 for n /wd<n> disable warning n /we<n> treat warning n as an error /wo<n> issue warning n once @<file> options response file
So as you see most of the differences are new switches for the VC.7 version of cl.exe. Those shouldn't cause any trouble, as VC6 just won't use them by default. The two options removed I don't think are very interesting to most poeple. Besides, the VC.7 cl.exe is happy to ignore them:
C:\Program Files\MSVC++2003>cl/nobool Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3052 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
What about the problem of different compiler flags mentioned in this post? Is it a non-issue? I suppose even if it were a problem you could write a wrapper script that did the necessary translation of VC6 options into VC7 options.
A solution is a workspace?? Wow. That's even worse naming. A workspace is basically just a collection of projects (which in turn correspond usually to an exe or a lib). So who says that a collection of exes and libs is going to be "solution" to anything? A workspace is a "space" for doing "work" on several projects at once (related or not). So workspace always seemed like a perfectly reasonable name to me. "Solution" somehow sounds like the same smug marketing speak that brought us "My Computer" and "My Music". Like they're stepping in my shoes trying to put words in my mouth. Maybe I want to have 5 completely unrelated projects in my "solution" because those are the projects I'm currently working on. How is that a "solution" to anyting? Anyway "solution" is a really pompous name for what amounts basically to a simple ASCII list of project file names. It's like the manager claiming that he "solved" the problem, when all he really did was just ask someone else to do it for him. Or like Al Gore "inventing" the internet.
I wonder if it is possible to use the newer commandline compiler from within Visual Studio 6. From what I hear, the.NET IDE isn't so great for C/C++ work. And come on, a project file is now called a "solution" file?? That's just dumb.
On the other hand, I would really like to have the better standards compliance of the newer compiler.
The Intel compiler can be used as a drop in replacement for the VC6 compiler, so maybe it's possible to drop in this one somehow. Anyone tried this? Maybe it's as easy as just putting the new compiler tools first in the VC6 bin/include/lib paths.
Since when? It means "almost but not quite". Period. I think the poster is quite right. KDE is almost but not quite as good a desktop as Windows. And that's saying something. KDE used to be no where near as good as Windows, and now it's pretty close. Bravo to the KDE team.
I'm with you that this doesn't seem like a very patent-worthy innovation. But when you think about it, when you go to a fast food restaraunt or coffee joint, even the plastic lids on the cups are patented. They've been patenting things like that for as long as I can remember. And what's the difference from lid to lid? Basically just a little industrial design. If that's the standard, then yeh, I have to say the iPod is at least as innovative as the plastic lid I got on my last cup of coffee.
Perhaps I was too terse. Grandparent says basically "Ford would never care about someone using their trademark on a computer related product because they make cars not computer products", and I replied with an example of how an automotive trademark is currently being used on a computer product. All I was trying to say was that Ford might be interested in extending their brands to computing products as well, just as Ferrari has done with this Acer deal.
You'd think, but cars and computers may have
more in common than you think. At least one automaker thought their brand name would look swell on a computer product.
Thanks for the link. Installed GTK and GIMP. Looks like it's still got a ways to go before it'll replace Photoshop. The new version of the GIMP bombs out for me with these error messages as soon as I pick up my Wacom Tablet stylus:
(gimp-1.3.exe:2972): Gdk-WARNING **: losing last reference to undestroyed window
I think you forgot to prefix your comment with "In the Year 2000 (In the year twoooo thousaaaaaaand)"
the GIMP will still be butt ugly Photoshop user still wont want to use it. Zealots will keep saying the GIMP it is just as good as Photoshop even though it clearly isn't (it may be "good enough" for many people but that is something else entirely):-)
Good points. I agree it's useless to debate which is better, GUI or CLI. Each has distinct advantages. What I'd like to see is more exploration of how to take advantage of the best of both with GUI/CLI hybrids.
Matlab and Maple offer pretty interesting examples of hybrid GUI/CLI interfaces. For instance, you type some graphing command, and then the graphical output appears right there inline in the console. Overall their UI is more slanted to the CLI end than GUI.
AutoCAD was another one, but with a more GUI slant than CLI. Actually several modern modeling packages, (e.g. Maya) have a sort of command line interface that lets you type in a scripting command, but it's basically just a way to run one-line scripts than a command line interface to the entire application. I think in AutoCAD it was more like a full interface. I could be wrong, though, not having used either extensively.
Anyway, there's no reason why the CLI type of interface can't be intermixed more cohesively with GUI. Think of the CLI as an interface for textual interaction of any sort. It doesn't just have to be a set of 'command ' syntax. It could incorporate much more than we think of as 'CLI' today in terms of natural language processing and especially pattern matching and searching.
Think about the best interface we've got for managing the complexity of the web: Gooogle. There's a similar problem with managing complexity in many application programs. What if in photoshop you could type "gaussian filter" and just click on the "I'm feeling lucky" button, and it would perform the gaussian filter. For many operations you do infrequently, that could be a big improvement over the frustrations of searching through all the menus to try to find the right thing. If the command needs parameters, the parameter sliders could even appear right there in-line in the app's console. If you need to tweak those same parameters again a few minutes later, the sliders would still be there in the console history.
Applications that have good searchable help give you some of the ability. But it's all set up to be really slow. With help searches, you have to open the help, search for the command you want, say "oh of course! it's under the format menu", close the help, then go open the "format" menu and click on the right menu choice. Instead, I'm talking about a CLI where the command/search area is always shown and is used to launch the commands directly (or present you a list of options if there's ambiguity).
Actually the Microsoft Office team seems to be trying to go in that direction. But their implementation in the form of Clippy is horrible. And it's still tied into 'help', which to me is basically like "exception handling" for application flow, rather than being a normal part of usage. It's too heavy handed. I _know_ what "kerning" is -- I don't need a whole window to pop up with a description of typsetting terms just to kern some text -- I just want it to execute the darn command.
O.J.Simpson lost the "court of public opinion" and he is still walking around a free man.
Yeh, he's free, but remeber how O.J. Simpson used to be do lots of television commercials for major corporations at one time? Now he's basically shunned by everyone. I don't think that's the future free software supporters are hoping for for Linux.
Slashdot Mirror
That one really irks me. It's not like it really even adds that much to the dramatic impact to have "C:\>" go scrolling by on the hero's nose. It just looks dumb.
Unfortunately many of the papers about things like FFT and multigrid on GPU actually run slower on GPU than CPU. But the argument is that the performance of GPUs is growing so rapidly (aka "Moore's law squared") that before too long they will run faster on the GPU. The new NV40/R800 class of GPUs may have already tipped the scales. The ability to now read textures from within vertex programs and branching instructions should also allow some algorithmic improvements to be made to some GPGPU techniques.
And what if you're editing an armature?
Doesn't work there. What about when you're editing texture coordinates. Doesn't work there does it? Undo for meshes is great, but there are quite a few other places where it sure would be handy.
People share their ideas and publish, because if they don't they don't get tenure or graduate or whatever. But there's often a big development investment involved in going from some paper published in a journal to working code. The published paper may give you the major differences between what they've done and the previous work, but most any important achievement builds on a bunch of prior work which is, say, contained in 5 other papers, which in turn were each based on 5 other papers each, and tracking all that down and getting it and translated into code can take a long time.
So say I'm the guy who published the paper -- while you're spending all your time re-implementing my previous method, I've already gone on and developed another few enhancements or a whole new method, and gotten another paper or two out of it, while you're still trying to recreate what I did last year.
So basically, just because the ideas in academia are basically open, that doesn't mean the implementations are. In fact, I've heard some math guys voice the opinion that releasing your source code is just a waste. It takes a significant time investment on your part to get it all packaged up, perhaps cleaning up the code some, and then to answer questions people have about it etc. And when it comes time for tenure review, they don't ask you how much source code you released. No, all that matters is how many journals you published in. So while you were busy cleaning up your source code for release, fixing non-critical bugs and adding non-essential features, you could have been working on the next publication instead.
Of course a lot of researchers do go all the way with openness and release source. But I've seen plenty of both strategies.
Another part of the equation is that Universities these days all want a piece of the action on anything invented within their walls. So they want you file for patents and such, and try to find people that will license those patents. And naturally a big cut of the licensing fees go to the Universtity. And then there's folks who dream of starting their own multi-million dollar spin-off technology company, so they don't want to let too many details about what they're doing to leak out until they've got all the patents lined up.
JV: Let's say there are a thousand. But there are 284 million people in this country. You can't have public policy that is aimed at 100,000 people when the other multi-multi-millions are also involved. You can't do it that way.
Yeh, that's a good point. Here's another -- how many people are in wheelchairs out there? It's not *that* many. In fact I don't know anyone in a wheelchair. So why should we have public policy aimed specifically at those people when there are multi-multi-millions of us who aren't crippled? It's another case, just like Skippy Valenti said, where You can't do it that way. To hell with the ADA. Those folks in wheel chairs should go buy their own damn ramps if they want to get into buildings. And tell 'em Jack sent ya!
Executive summary: XML was a bad idea
Is Ant better than SCONS?
http://ant.apache.org/
http://www.scons.org/
Seriously, I'm just curious. I've heard a lot more about SCONS than Ant. For instance Blender is switching over to a SCONS build system.
Yeh, 3D what? The comparisons they make are meaningless because there is no agreed upon meaning of "3D model".
Look at MP3 - A format for specifying a fixed, sampled 1D data stream.
Look at JPEG - A format for specifying a fixed, sampled 2D data stream.
and I'll throw in
MPEG - A format for specifying a fixed, sampled time sequence of sampled 2D data (or 3D sampled data if you want to thing of it that way)
All of those are relatively well defined problems. The output of the decoder is essentially either a 1D array of samples (audio), a 2D array of samples (image pixels), or a 3D array of samples (video). All of those are very well understood and very standardized in terms of meaning.
U3D - What does it encode? It's not clear. Probably the most direct analogue to the MP3 and JPG cases would be that given a U3D file you should be able to generate any 3D view of the model. A view is basically a 2D image, and you can place the camera anywhere in 3D space, and you can rotate the camera about 3 axes. Add it all up you're talking about an 8D dataset. Now using a little clever reordering you can reduce that to 5D, and what's usually called the "plenoptic function" (6D if you include time as a dimension as well, for animation), but it's still an open problem as to how to encode all that info into a reasonable sized file. So we don't. We use cheats. We explicity define triangles that approximate particular surfaces in the scene. We assign them colors. We define material properties like specularity. We assign them textures. We assign them multiple textures. But we want better, more realistic images, so that we can make something that looks like brushed metal. Or refracts like glass. Or whatever. So now we have things like register combiners to allow prettier rendering, then we get pixel shaders. And pixel shaders 1.2, and 1.3, and 1.4, and 2.0. Etc. And there will be a pixel shader 3.0 I'm sure and so on. And then there are full surface BRDF descriptions, and all the many ways to encode that efficiently like the LaFortune model or spherical harmonics and whatnot. And we're definitely not done yet. All these things go a long way to capturing a lot of the high-order terms of the plenoptic function, but it still doesn't give you a way to encode any specific 2D view from any position in space.
The point is that 1D and 2D -- even 3D -- sampled data are simple. It's just a bunch of samples. As soon as you move into describing 3D scenes you we're talking about much higher-dimensional data, and the exhaustive sampling approach breaks down. So you have to make a lot of assumptions, and use a lot of tricks, and people are still inventing the tricks. And some assumptions are useful to some people, like game designers, but completely inappropriate for others, like medical technicians. MP3s use tricks too, but the output is almost indistinguisable from the original audio for most people, same with JPEGs and a photograph. That's because sampling in low dimensional spaces is really well understood, and the raw data size isn't really that big to begin with.
My point is that it's going to be a while before we can represent 3D generically in a way that is basically indistinguishable from reality. And that is universally useful as mp3 is to audio, and Jpeg is to images. Until then we'll continue to use various appearance models like Blinn-Phong specularity, and continue to develop newer and better ones. And each one requires that the decoder know how to handle that appearance model. And may require some particular kind of hardware support, like pixel shader 2.0.
For the time being there just isn't a way to specify a 3D model that's universal. The whole idea is just silly. I don't see this being anything other than another VRML. Useful maybe, but nothing at all like Mp3 or Jpeg. The comparison is just dumb.
That's why we have so many model formats in the first place. Some people just need a plain list of triangles. CAD people need data described
What's the problem? The problem is that they've taken a perfectly good word and used it to describe something that it is not. Yes it's just terminology, but all I'm saying is it's a stupid name, and there was no reason not to continue calling it a "workspace". At least "workspace" was a made up word to which they are free to assign whatever meaning they wish, since they made it up.
.sln suffix. From this day on, I declare that it's is no longer a "solution" file -- instead .sln will stand for a "sirloin" file. Yes, that's it. It's the file that contains the meat that makes up your application. The sirloin file. That's what it is. Ok, now I'm happy. Maybe I'll even upgrade to VC7 now that I can use these cool new sirloin files.
I guess the thing that really irks me about the name "solution" is that it almost makes sense. It's so close to making sense that I want to interpret it literally, like the code I need written is the problem and the solution is contained in a "solution" file. But the "solution" file doesn't contain the solution to my problem most of the time. Like for instance when my code doesn't even compile yet. That's hardly a solution. Or maybe I should interpret it as the solution to the problem of building my application. The build configuration problem. But the most difficult bits of the build problem are contained in the project files. The "solution" file is just a glorified list pointing to several projects. So it doesn't really make sense to think of it as the solution to the build problem.
And I can't think of any other context in which it could be the solution. So it just bugs me, ok.
I think we need to think of a new interpretation of the
Ok. I gave this a try, and it doesn't work for me. It compiles, but the debugging information is apparently in a different format from what Visual Studio 6 is expecting. And I have the Platform SDK also. Updated that a month or so ago.
See this post. So Mr. AC, were you able to debug as well? If so please tell us your secret sauce to get it working.
Ok, I gave it a try, the new free compiler with VC6 IDE. It seems to compile and run ok. But debugging doesn't work.
/pdbtype flag. It still ignored it and linked ok, but when I went to debug, VC6 said the exe didn't have any debugging symbols. I've tried changing the debugging options in VC6 a few different ways (C7 compatible, no program database etc), but nothing I've tried makes the debugger happy.
The new link.exe complained that it doesn't know the
So it looks like this may not be something that will work as well as one might hope, unless anyone has any other ideas.
OPTIONS THAT WERE IN VC6 BUT AREN'T IN VC7 cl.exe:NEW VC7 cl.exe OPTIONS:So as you see most of the differences are new switches for the VC.7 version of cl.exe. Those shouldn't cause any trouble, as VC6 just won't use them by default. The two options removed I don't think are very interesting to most poeple. Besides, the VC.7 cl.exe is happy to ignore them:So as another poster has said, it looks like it should just work if you put the new directories first in the MSVC6 bin/lib/include paths.
Cool! All the updates I care about for VC 6 without having to switch to a new IDE!
What about the problem of different compiler flags mentioned in this post? Is it a non-issue? I suppose even if it were a problem you could write a wrapper script that did the necessary translation of VC6 options into VC7 options.
A solution is a workspace?? Wow. That's even worse naming. A workspace is basically just a collection of projects (which in turn correspond usually to an exe or a lib). So who says that a collection of exes and libs is going to be "solution" to anything? A workspace is a "space" for doing "work" on several projects at once (related or not). So workspace always seemed like a perfectly reasonable name to me. "Solution" somehow sounds like the same smug marketing speak that brought us "My Computer" and "My Music". Like they're stepping in my shoes trying to put words in my mouth. Maybe I want to have 5 completely unrelated projects in my "solution" because those are the projects I'm currently working on. How is that a "solution" to anyting? Anyway "solution" is a really pompous name for what amounts basically to a simple ASCII list of project file names. It's like the manager claiming that he "solved" the problem, when all he really did was just ask someone else to do it for him. Or like Al Gore "inventing" the internet.
Bah! Solution files. Ridiculous.
So yeh, I'm with you. I'd like to know if I can somehow plug this new compiler into the VC6 IDE.
I wonder if it is possible to use the newer commandline compiler from within Visual Studio 6. From what I hear, the .NET IDE isn't so great for C/C++ work. And come on, a project file is now called a "solution" file?? That's just dumb.
On the other hand, I would really like to have the better standards compliance of the newer compiler.
The Intel compiler can be used as a drop in replacement for the VC6 compiler, so maybe it's possible to drop in this one somehow. Anyone tried this? Maybe it's as easy as just putting the new compiler tools first in the VC6 bin/include/lib paths.
Hmm. I think I'm going to try this out...
Since when? It means "almost but not quite". Period. I think the poster is quite right. KDE is almost but not quite as good a desktop as Windows. And that's saying something. KDE used to be no where near as good as Windows, and now it's pretty close. Bravo to the KDE team.
I'm with you that this doesn't seem like a very patent-worthy innovation. But when you think about it, when you go to a fast food restaraunt or coffee joint, even the plastic lids on the cups are patented. They've been patenting things like that for as long as I can remember. And what's the difference from lid to lid? Basically just a little industrial design. If that's the standard, then yeh, I have to say the iPod is at least as innovative as the plastic lid I got on my last cup of coffee.
Perhaps I was too terse. Grandparent says basically "Ford would never care about someone using their trademark on a computer related product because they make cars not computer products", and I replied with an example of how an automotive trademark is currently being used on a computer product. All I was trying to say was that Ford might be interested in extending their brands to computing products as well, just as Ferrari has done with this Acer deal.
You'd think, but cars and computers may have more in common than you think. At least one automaker thought their brand name would look swell on a computer product.
Not to mention that the debug console pops up right from the start telling me:
Whatever all that means, it isn't exactly going to inspire confidence in the newbies.
I think you forgot to prefix your comment with
:-)
"In the Year 2000 (In the year twoooo thousaaaaaaand)"
the GIMP will still be butt ugly
Photoshop user still wont want to use it.
Zealots will keep saying the GIMP it is just as good as Photoshop even though it clearly isn't
(it may be "good enough" for many people but that is something else entirely)
No, I read it as "SCO blah bl-blah blah b-blah blah blah."
Good points. I agree it's useless to debate which is better, GUI or CLI. Each has distinct advantages. What I'd like to see is more exploration of how to take advantage of the best of both with GUI/CLI hybrids.
Matlab and Maple offer pretty interesting examples of hybrid GUI/CLI interfaces. For instance, you type some graphing command, and then the graphical output appears right there inline in the console. Overall their UI is more slanted to the CLI end than GUI.
AutoCAD was another one, but with a more GUI slant than CLI. Actually several modern modeling packages, (e.g. Maya) have a sort of command line interface that lets you type in a scripting command, but it's basically just a way to run one-line scripts than a command line interface to the entire application. I think in AutoCAD it was more like a full interface. I could be wrong, though, not having used either extensively.
Anyway, there's no reason why the CLI type of interface can't be intermixed more cohesively with GUI. Think of the CLI as an interface for textual interaction of any sort. It doesn't just have to be a set of 'command ' syntax. It could incorporate much more than we think of as 'CLI' today in terms of natural language processing and especially pattern matching and searching.
Think about the best interface we've got for managing the complexity of the web: Gooogle. There's a similar problem with managing complexity in many application programs. What if in photoshop you could type "gaussian filter" and just click on the "I'm feeling lucky" button, and it would perform the gaussian filter. For many operations you do infrequently, that could be a big improvement over the frustrations of searching through all the menus to try to find the right thing. If the command needs parameters, the parameter sliders could even appear right there in-line in the app's console. If you need to tweak those same parameters again a few minutes later, the sliders would still be there in the console history.
Applications that have good searchable help give you some of the ability. But it's all set up to be really slow. With help searches, you have to open the help, search for the command you want, say "oh of course! it's under the format menu", close the help, then go open the "format" menu and click on the right menu choice. Instead, I'm talking about a CLI where the command/search area is always shown and is used to launch the commands directly (or present you a list of options if there's ambiguity).
Actually the Microsoft Office team seems to be trying to go in that direction. But their implementation in the form of Clippy is horrible. And it's still tied into 'help', which to me is basically like "exception handling" for application flow, rather than being a normal part of usage. It's too heavy handed. I _know_ what "kerning" is -- I don't need a whole window to pop up with a description of typsetting terms just to kern some text -- I just want it to execute the darn command.
O.J.Simpson lost the "court of public opinion" and he is still walking around a free man.
Yeh, he's free, but remeber how O.J. Simpson used to be do lots of television commercials for major corporations at one time? Now he's basically shunned by everyone. I don't think that's the future free software supporters are hoping for for Linux.