Back when it was cool to know about OLE in Windows, I would call it oh-el-ee, even when corrected to call it oley (as in ole with the accent on the e as what people chant at the bull fight). I was a noob to call it oh-el-ee, but I was just not going to dignify the Microsoft Offering de Jour by calling it oley.
What are people going with on top of Java to get scripting?
I have reasonable success using Python on Windows to host ActiveX controls and then interact with those controls from a command line or from scripts using PyCrust. If I want to host Java Swing controls and do the same thing, are people going with Jython? Something else?
With Java you get a good 2D graphics API with the BufferedImage class. To set your own pixels in C#, you need unsafe code. If it gives your app adequate performance, Java is a no-brainer.
Should a tools/component developer hang on to their legacy ActiveX codebase or should they reimplement everything as.NET controls?
Windows 95 was a big thing on a number of fronts -- preemptive processes and threads, 32-bit virtual memory, the Start button, standardized File dialogs. Another front was the COM/ActiveX component software model.
Having some kind of object and/or software component standard at the operating system level has been this long-time dream -- Taligent/Pink, Copeland, Open Doc, Wirth's Black Box. For all of its warts, COM and ActiveX became the standard for Windows, using an object-reference based standard to replace earlier attempts based on Windows messages and HWNDs.
Besides that ActiveX became the new plumbing for Visual Basic widgets, Microsoft did consume their own dog food in that COM/ActiveX became pervasive throughout the Windows desktop and desktop apps. Think of all of those demo programs of how to control Excel through your favorite scripting language (Automation) or how to include an IE window into your GUI (ActiveX). There is a lot more code sharing on the Windows desktop than you realize thanks to COM and ActiveX and the fact that Microsoft uses it.
I am in the boat that it has taken me a good 10 years to absorb the lessons of ActiveX, to decide on tools to develop for it, to develop software in it, to consume one's own dog food and use one's own ActiveX controls, to develop ActiveX libraries for commercial release. And this.NET thing comes along. Is this the Wave, should I drop everything I am doing in ActiveX and write.NET components? Or should I keep plodding along because that is what Microsoft is doing -- they too have 10 years invested in their own ActiveX libraries and are not about to start over.
ActiveX is incredibly crufty -- no one knows what half the interfaces do, and no one develops for it from ground zero without using automatic code generation from either Microsoft or some 3rd party tools (Delphi), and no one knows what that automatic code generation is doing. ActiveX controls are clunky in that they are software components, but they are not true object classes that you can inherit and extend in your own applications. But they get the job done, they are superbly language-independent (of course restricted to the Windows world), and.NET apps can mix and match ActiveX widgets with the newer.NET widgets.
So why.NET widgets? They allow true object inheritence, the crufty parts are better hidden and encapsulated away, and they are, well, the new thing! On the other hand, everything from the open-source Python to the commercial Matlab has excellent support for ActiveX but nothing for.NET widgets.
When someone does this analysis of.Net use in Vista, this is not just a matter of "ha, Microsoft doesn't eat their own dogfood." I really need to know what state my investment in ActiveX is in and where I need to go next. For example, the current support for 2-D graphics in.NET is rather hamstrung compared to what you can do with CreateDIBSection and ScrollWindowEx under Win32/ActiveX. On the other hand, if there is a whole 'nother graphics model under Vista requiring.NET to access, and if legacy ActiveX controls under Vista start looking like 16-bit Windows apps under Windows 95, then I have to respond to that. But if Microsoft hasn't seen the need to bother with reimplementing their disktop apps under.NET, maybe I am OK with my stuff. If they have reimplemented their desktop stuff to give it a Vista/Aero look but are not using.NET to do it, I sure as heck want to know what they are using instead.
In case you are wondering, I am looking to Java if I have to go through the bother of rewriting all my ActiveX stuff. First off, the BufferedImage.setRGB() and Graphics.copyArea are pretty m
Does this process provide any insight into the origin of oil within the Earth?
One of the claims of the abiogenic-oil folks (J F Kenney and Russian colleagues, T Gold) is that no one has proven the mechanism by which buried plant or algae or other organic material turns into oil by being buried at the shallow depths of the "oil window." The conventional narrative on biogenic oil is that organic material gets buried, and at a certain range of depth (about 1-2 miles down), the temperature and pressure is able over time to crack the long-chain molecules in the plant material into oil.
The skeptics of the conventional narrative, the abundant abiogenic-oil quacks, whatever you want to call them, argue that the conversion of long-chain carbohydrates or plant oils into saturated short-chain hydrocarbons just doesn't happen in the oil window just as diamonds don't form in the shallow layers of the crust. They argue that oil can only form at the same depths (pressures and temperatures) as diamonds -- that is deep down in the upper mantle -- and that there are mechanisms by which oil and gas can migrate upward from those extreme depths and not disassociate.
It should be simple enough to take organic matter and apply the same squeeze and temperature and pressure as the oil window, mix in what you think is the natural mineral catalyst, and voila, get oil from "oil window" conditions, no? Even if long time is an ingredient, you should be able to get traces of oil for short time? The oil window skeptics argue 1) no one has ever done this, 2) it doesn't happen, and 3) it only happens in industrial processes where you are using metal catalysts.
The skeptics argue that you can't just crack long-chain unsaturated carbohydrates and turn them into short-chain saturated hydrocarbons. The skeptics of the skeptics turn around a say, wrong, it is not plant carbs but an unspecificed something else in organic matter that turns into oil. Anyone have any insight into this?
Yeah, they were being funny on purpose. I guess the idea of the "Hollywood suits" was that Batman was a comic, hence a cartoon, so if you bring it to life with live-action actors, you were appealing to kids at a serious level, but you made it kind of campy-humorous to hold the attention of the adults who had to take their kids to the thing.
My guess is that the suits didn't realize how campy and unserious they had made it. The sort of comic book Batman as Dark Avenger (I mean hey, the character is a vigilante, so you would expect his character to be somewhat outside the law instead of a mere "civilian contractor" to an incompetent police chief) was developed, of course, in the Tim Burton treatment. The suits skipped over that part of Batman, perhaps to make it more kid friendly.
I would agree that a survivor of the Holocaust has standing to bring up comparisons to Nazi Germany that others of us may not have, but I take issue with the idea that Congressman Lantos is a Holocaust survivor so that one cannot publically disagree with him on such matters, in a public forum meant to air such disagreements, where he is a public figure airing such disagreements for the furtherance of law.
The other thing I take issue with is that once a society or a regime crosses a certain threshold of evil that they become Nazi Germany. There has been a lot of evil in the world over the years, but it is generally believed that Nazi Germany represented a particularly unique and malignant evil in that history. It also diminishes our rememberance how just how bad Nazi Germany was when we equate it to Milosovic's Serbia, Saddam's Iraq, or modern day China. While there are people who may argue this point, it is even believed that Stalin's Soviet Union, however lethal and repressive a regime that was, didn't quite rise to the unique combination of modern science and industrial production with a racist world view and mass murder that was Nazi Germany.
There are many ways that all regimes that practice evil resemble Nazi Germany, and people have even invoked this comparison for matters that bring shame to the U.S., but there are many ways that Nazi Germany was unique, and to call every bad regime a Nazi Germany diminishes the rememberance of those who suffered under it, and I would say that publically to Mr. Lanos.
Agreed. In response to the challenge "would you have cooperated with Nazi Germany" I would have been attempted to respond "no, not when we were at war, but remember we are not at war with China, although we ended up at war with Nazi Germany as a consequence of an economic embargo we imposed on Japan in response to human rights violations in China."
On the other hand, Lantos has standing to invoke Nazi Germany on account of his personal and family history.
Why does this remind me of the kinds of things Medievel war reenactors do with their catapult and trebuchet reconstructions and their enthusiasm for flinging things in the name of historical research? I can just picture some bearded geeks in the year 3000 building and testing such a thing (by then we are all living in space colonies and New York City will be an ancient ruin where they will be allowed to do all of this) as a kind of off-the-wall seat-of-the-pants attempt at a historical recreation of an event believed to have taken place in 2050.
There is one more Windows thing that Delphi does well to add to your list: develop.ocx ActiveX library modules.
I could never get the hang of Microsoft tools for developing ActiveX controls -- I have done toy examples in ATL and don't want to even think about MFC. My biggest gripe is that COM interface development doesn't round-trip -- once you develop an interface using the wizards (gosh I hate that word for those lame tools) you are pretty much stuck. The wizards create so much code in so many places of "you-can't-touch-that" code, that if you need to change an interface, you may as well crumple the sheet into a wad, toss into wastebasket, and start fresh.
Delphi has a pretty good Type Library editor for fine tuning COM and ActiveX interfaces -- of course interfaces are cast in stone when you let them out, but I like to make changes to interfaces when developing a new library. Type Library editor does a pretty good job of allowing one to add to or edit COM or ActiveX interfaces -- the updates to your code are a sometime thing, but there are not too many places you need to change and the compiler error when something doesn't change automatically also help.
There is one serious flaw in Delphi-developed ActiveX controls -- they won't serve up events with the Python ActiveX support, with Matlab 7, and with any other system that does multiple registrations of event listeners on a control. I have a really ugly patch for this at http://www.medsch.wisc.edu/~milenkvc/pdf/multieven t.htm.
There is one big shortcoming to Delphi -- collection classes. C++ has the STL, Java has its collection classes, Python is a set of collection objects masquerading as an object system. The built-in collection types in Delphi are sparse and are wired into major parts of the VCL (you can't do a console app or a straight Windows API app and use those collection types without folding in a lot of VCL code). Collection classes built-in to the language/library instead of programmers rolling their own linked lists, hash tables, etc. are the vogue, and Delphi hasn't kept up.
Mr. Kahn was probably the mastermind behind the cheesy Byte Magazine ads trumpeting the $49.95 Turbo Pascal. I was actually put off by the ads -- the price seemed too low for anything good (I believe MS Fortran sold for about $400 in those days), the name Turbo anything seemed complete
hype, and the ad graphics had all of the style of your local appliance king in the pre Best Buy days.
But a colleague at work said, "No, it actually is a good product", I dropped what I was using at the time: would you believe RR Software's subset Ada compiler? Turbo Pascal changed all of that, and I never looked back.
That colleague who turned me on to TP later defected to Matlab. I am seriously looking at Java/Swing/Netbeans these days. Neither the compile-side or the runtime performance are anywhere near Delphi, but hey, Moore's Law and all of that so it doesn't matter anymore.
Just as it is assumed that a language like C or C++ translates statement-by-statement into machine code, you are assuming that a language like Python translates line-by-line into C++. Does it?
A variable in Python is a variable as in anything else, but a variable is a reference to an instance of a type that could be anything -- the referenced instance has a type as opposed to being some universal type like a string, but it can be assigned on the fly, and it can be a number, a string, an object instance, a class, or a function. I suppose assignment is just copying the reference, but as soon as you do anything with it, you have to somehow look up the dynamic type and decide to do something legal. And fail gracefully if called to do something illegal.
And as to memory allocation, everytime you touch a reference you are doing something with a reference count, and I believe there is some kind of primitive mark-scan garbage collection layered on top of the reference count to break circular chains. Are you going to hand translate that into C++ as well?
Greenspun's 10th law is this inside joke among Smug Lisp Weenies (TM) that any sufficiently complicated Fortran program (back in the day, today substitute C/C++ program) implements a good chunk of Common Lisp, only slower and with a lot of bugs. I may offend people to compare meek Python to mighty Common Lisp, but Python has a sufficient dynamic behavior to make the connection.
My advice on the reliable C++ program is 1) design to the level of having a clear idea of the architecture of your app before coding -- the classes, their purpose, their containing other objects, 2) for each object where a reference is contained in another object, do some kind of code reading/verification/check of conformance to a standard you have established as to how that object gets deleted in a safe way. It could be reference counts, auto-objects, caller deletes/callee delets -- just decide on what you are going to do and read code to see that you are consistent about it.
But I don't agree with the grandparent post about the dirt coat on a withering snowball. It is just an intuition shy of a hypothesis, but the data points are 1) the very dark pictures of the solid object that makes up a comet, 2) the very dark C-type asteroids, 3), the seeming continuum between comets and C-type asteroids, 4) the carbonaceous chondrite meteorites, 4) the high silicate content of interstellar dust grains from which the Solar System formed.
Ice may be a more minor constituant of these things -- a lot of the water may be more in the form of hydrated minerals than just plain water. SiO2 may be more abundant out there than H2O. If someone were making book on this kind of thing, I am wagering at long odds that when the first spacecraft brings back a chunk of comet, it will be more like the piece of road spalled off a pothole than the dirty, sandy ice filling that pothole.
The standard model of a comet is as a dirty iceball -- like Frosty parked out in your yard. I am thinking more snowy dirtball. The first pictures of Halley's Comet showed that it was quite dark. I have been thinking that a chunk of comet is more like those chunks of pavement that spall off potholes than the slushy snow that the plow truck shovels to the side.
Yep, I am thinking road pothole leavings -- a conglomerate of silicates, hydrocarbons, with a little bit of ice mixed in. Arthur C Clark has a plot point in one of his 2001 spinoffs that a spaceship could land on Halley's Comet, load up on slush, and use this for thrusting mass for some kind of fusion-thermal rocket drive, only the carbon in the slush would make for a spectacular incandescent rocket exhaust. My view is that the comet surface may be kind of crumbly, but it won't more very well and likely clog up some valves if used as rocket fuel.
Solving the GUI layout manager problem
on
NetBeans 5.0 Released
·
· Score: 4, Insightful
Looks like Java Swing may have solved the GUI layout manager problem. VB/Delphi using pixel placement layout allow you to place the controls on a form just so, but what about resize? I know, I heard, use anchors, but you end up doing a lot of tinkering with anchors and with panels within panels within panels to get things anchored right. Anchors in Delphi can be like a bad case of Swing BorderLayout.
The Matisse layout manager allows direct placement, but it offers guidelines and snap-to-grid hints, and it auto-places anchors for resizing. On the other hand, there is this JAR file one has to distribute with one's apps to get this new layout capability.
Could this finally be Java Swing as the VB killer? What I mean by this is that Swing is criticized for clumsy repaint, for ugly look-and-feel, for slow, etc. But is it good enough? VB apps are not known for speed or well-thought GUI design. For a lot of apps (whipping off a bunch of forms as a front-end to something) these are not considerations. What is a consideration is that someone versed in VB is not going to put up with Swing layout managers. If VB was the killer development app that kept people on Windows, this thing may help people break free.
Don't think I ever got the "is that all" reaction to M31 -- you tell them a story about what they are looking at and why it is important and how it is one of our near galaxy neighbors, and when they see the white fuzzy oval, they quietly reflect on that. I think most people expect that a small telescope won't show the same dazzling images as a "professional" telescope, although I am not sure what you would see naked eye on M31 through the Palomar telescope that is much different from the back yard -- photos enhance contrast in addition to image intensity.
M31 is perhaps the most universal theme for a galaxy photo in an astronomy textbook -- it is after all the most nearby of the big spirals and I have seen more pictures of it than I can count. The pictures in a way are a cheat because they are deep time exposures with dodgy color rendition. When you look at M31, you are looking at it as it really is, and I have always thought there is some cool factor to that over looking at pictures.
The other thing about M31 is that the fuzzy blob that you see is only the central region -- M31 is not a tiny object, it is huge, but the spiral arms and dust lanes are so low contrast it takes very dark skies and experienced observing to see any of it. On the other hand, one can see M32 in the same field of a wide-field eyepiece and then one can also see M110 if you have a big enough scope, dark skies, and averted vision technique. Even if you don't see the spiral arms and dust lanes, a person can see the landmark satellite galaxies, well known in photos, and get a lay of the land -- that the fuzzy blob is just the bright central part and that the parts seen on photos go a ways off. People used to looking at Mars or Saturn are thinking that telescopes mainly magnify things that are tiny -- M31 would be quite viewable without magnification if you had enough light grasp.
For criticism of look-and-feel of TCL/TK, Java Swing, what have you relative to VB, a person needs to look at the hodge-podge of a lot of VB apps -- I can't see how a TCL/TK or Swing app would be much worse.
For Win32 stuff, Delphi is great, but I second the concern of the poster below that it costs too much -- no more Philipe Kahn selling it for 49.95 USD.
What about Java? What about NetBeans 5? There may be some hangup on getting serial port access, but for the GUI stuff, NetBeans 5 may be the new VB/Delphi.
The age old problem with visual GUI development is that you can do absolute placement and then what happens when you resize the form? Or you can use layout managers (Java Swing) and then you have to wrestle with the layout manager to get the placement you want. NetBeans 5 has the Matisse layout manager -- I played with it and it seems to be the best of both worlds. You can drop and drag widgets in the form designer, but it gives hints regarding good alignments and regarding anchoring to boundaries for resize. Oh, and NetBeans is a free-as-in-beer download.
Java Swing, you say, not the native look for Windows. A lot of native Windows software is a hodge-podge of look-and-feel anyway -- Swing is no big deal. Besides, if you go with Java, you are not tied down to Windows.
How did they do on drafting specifications? Yeah, yeah, the homework assignment is a spec, but you know how profs are in leaving out important details. In line with the remarks that learning how to outsource coding is better than learning how to code in today's climate, you still have to write a specification and come up with test cases to verify that the spec is met. In that way, your overseas coders are a kind of 4th generation language -- a translation of English-language specs according to some protocol into Java code and test cases.
I have kind of wondered about this sort of outsourcing in my own work, but I am wondering about the degree of independent thought of the coders and what kind of spec I need to supply.
One of the projects I have is implementing a wait-for-vertical retrace in Java. Java has BufferStrategy, but you only get vertical sync on page flips in full-screen mode and only on Windows. I have gotten a wait-for-vertical retrace working under Debian Linux as a JNI module written in C++ using OpenGL/GLX/X calls, and I would like to port this to Solaris, OS X, etc. So can I tell some dude "Here are the C++ source files, here is my makefile, here is a Java test program, go make this work on all of the other platforms by finding where the headers and libs are and/or download the needed drivers to make it work or tell me why it won't work on a particular platform, and if GLX/X on OS X doesn't support vertical retrace, tell me if there is some other hack to use on OS X"?
A lot of what I spend my development time on is stuff like that -- the rote coding to a spec is something I know how to pound out the code and don't need to outsource. For large projects, one should draft and maintain specs instead of just hacking code until it sticks, but it seems the writing the specs is the bulk of the work and the outsource coder is a sort of human 4GL. And for tricky stuff -- that is using libraries and OS features that are not well documented -- there is no substitute for hacking.
Before the Buran shuttle vehicle, the Russians had a project called Spiral, very similar to the India proposal for a high-Mach carrier aircraft first stage followed by an orbital stage and a small lifting body orbiter.
But before going down that path, the folks in India should listen to this guy http://www.dunnspace.com/home.html#Columns. Getting into orbit is fundamentally different than flying an aircraft, and this Arthur Schnitt fellow argues that the max performance route used in aircraft is too costly. He got this idea of Minimum Cost Design from the Thor-Agena launcher for the Corona-Discoverer spy satellite -- the Thor booster was a lot cheaper than the Agena upper stage on top -- that cost had little to do with size in rockets, and by building big rockets with cheap methods (the Big Dumb Booster), you could reduce the cost of space launch
You argue that developers can pound out a Swing interface in a few seconds -- yes they can, but in practice does this work?
An old VB/Delphi/whatever Windows developer downloads NetBeans, fires up the GUI designer and asks, "this Java Swing stuff, how hard can this be?" So they click on a button widget, drag it to a form, and fire up the application. They get this big honkin button which takes up the entire form. "No problemo, I will simply drag this button over into a corner on the Form Designer." Fire up the program, and you still have a big honkin button taking up the entire form without any apparent way of changing its location.
You see, the VB/Delphi/whatever Windows school of GUI development is pixel-based and folks are used to using the Form Designer to place a widget on the form and then tweak locations and placement on a pixel level to satisfy their client/bosses/customers. Yeah, yeah, when you resize the form, now what? But for a lot of people, they do pixel-level layout using the form designer and kind of assume no one ever resizes the form. Also, a switch between large font/small font on Windows can jazz up a lot of Delphi widgets, but we will assume no one ever makes that switch either.
The Java Swing people know about layout managers, and layout managers solve all of the above problems -- font size changes, form resizes. But the layout manager world is a bizarro world to the form designer pixel-placement world. It is kind of like the gulf between WYSIWYG and TeX/LaTeX -- Word and its WYSIWYG cousins are like the pixel-placement world while the TeX world is related to layout managers. But just as TeX word processing is largely generic text editor plus document preview -- does anyone have a workable TeX/LaTeX WYSIWYG -- do layout manager GUI more properly belongs in the vi/emacs/pico and javac world -- does it even make sense to have a graphical form designer in the layout-manager world.
So to VB people, the.NET Form Designer is quite comfortable and familiar and Windows Forms is pixel-placement friendly while Swing/Netbeans is in the bizarro world of layout managers. I am not saying layout managers are bad -- I do a lot of word processing using LaTeX -- it is just that people who are not indoctrinated in them get frustrated real quick on Java Swing and return to what they are used to.
I use Eclipse a little, but often find it easier to revert to (favorite text editor) and javac. The Eclipse built-in compiler seems pretty fast though.
The first roadblock is how to run a program from the IDE. Yeah, yeah, in Java you have to specify which module contains a class with a static main method, but still, bringing up a project and figuring out the Run dialog can be an effort.
The second roadblock is how example programs are packaged -- some kind of.zip format and unzipping when you load projects -- still haven't cracked that on.
The third annoyance is if you have a bunch of.java files that compile to a bunch of.class files, and you just want to use Eclipse a text editor for the.java, as a compiler for the.class, and perhaps to run a.class file containing a static main(). Eclipse is real fussy about existing/new directories, and yes I have generated projects to encompass collections of.java files I had previously maintained with a text editor and compiled with javac, but I can never remember from one time to the next how to do it.
Last time I mentioned any of these issues I was modded Troll and told I was an idiot (gee, people are that sensitive about any criticism about Eclipse). Eclipse may be good, Eclipse may be powerful, but Eclipse has a lot of the stamp of IBM on it that they have their unique way of doing UI's, and I second that observation.
For people raised on the Unix culture, Linux on PC's is a natural progression from workstations and before that, VAXen.
Linux (OK, OK, GNU/Linux) was meant as a Unix clone, and it is only natural that Linux has displaced Solaris, whatever Silicon Graphics was doing, and so on.
For people raised on the DOS/Windows culture, it is not as natural a progression. A lot of us (those doing lab computers for data collection, using computers for scientific computation, other academic pursuits) came to DOS and later Windows because . . . computers for this sort of thing (largely VAXes and later workstations) all ran Unix, and you had to have a big enough grant to afford not only the hardware but the Bearded Guru (TM) to keep such a system running. DOS and later Windows was in part a go-it-alone and do-it-yourself movement so the scientific luser community would have some financial and technical independence. While DOS/Windows came to require a guru culture of its own, a lot of us renegades acquired that expertise while we didn't know much Unix beyond ls, cat, hidden config files started with a dot, and VI has two modes: insert mode and beep mode.
The academic luser community could have adopted Linux as a go-it-alone replacement for big iron Unix, but for a variety of historical, cultural, and technical reasons, we went with DOS and Windows.
For the longest time, Microsoft was the "good guy upstarts" compared with the commercial Unix's. Microsoft acted tough with vendors and software developers crossing a certain threshold from the beginning, and the acting tough with users (product activation) is much more recent. But the academic luser community is stuck in the Windows world and is making toe-dipping attempt to try Linux out to break free, and it has been tough going.
But those NASA/JPL dudes running Linux come from people migrated from workstations I bet -- I would like to see an example of a luser community making a major effort to get going on Linux.
Without going into personal details, Bernie Mac's standup routine in the Spike Lee "Kings of Comedy Movie" will disabuse you of those romantic notions regarding married sex life.
Slashdot Mirror
Back when it was cool to know about OLE in Windows, I would call it oh-el-ee, even when corrected to call it oley (as in ole with the accent on the e as what people chant at the bull fight). I was a noob to call it oh-el-ee, but I was just not going to dignify the Microsoft Offering de Jour by calling it oley.
I have reasonable success using Python on Windows to host ActiveX controls and then interact with those controls from a command line or from scripts using PyCrust. If I want to host Java Swing controls and do the same thing, are people going with Jython? Something else?
With Java you get a good 2D graphics API with the BufferedImage class. To set your own pixels in C#, you need unsafe code. If it gives your app adequate performance, Java is a no-brainer.
Windows 95 was a big thing on a number of fronts -- preemptive processes and threads, 32-bit virtual memory, the Start button, standardized File dialogs. Another front was the COM/ActiveX component software model.
Having some kind of object and/or software component standard at the operating system level has been this long-time dream -- Taligent/Pink, Copeland, Open Doc, Wirth's Black Box. For all of its warts, COM and ActiveX became the standard for Windows, using an object-reference based standard to replace earlier attempts based on Windows messages and HWNDs.
Besides that ActiveX became the new plumbing for Visual Basic widgets, Microsoft did consume their own dog food in that COM/ActiveX became pervasive throughout the Windows desktop and desktop apps. Think of all of those demo programs of how to control Excel through your favorite scripting language (Automation) or how to include an IE window into your GUI (ActiveX). There is a lot more code sharing on the Windows desktop than you realize thanks to COM and ActiveX and the fact that Microsoft uses it.
I am in the boat that it has taken me a good 10 years to absorb the lessons of ActiveX, to decide on tools to develop for it, to develop software in it, to consume one's own dog food and use one's own ActiveX controls, to develop ActiveX libraries for commercial release. And this .NET thing comes along. Is this the Wave, should I drop everything I am doing in ActiveX and write .NET components? Or should I keep plodding along because that is what Microsoft is doing -- they too have 10 years invested in their own ActiveX libraries and are not about to start over.
ActiveX is incredibly crufty -- no one knows what half the interfaces do, and no one develops for it from ground zero without using automatic code generation from either Microsoft or some 3rd party tools (Delphi), and no one knows what that automatic code generation is doing. ActiveX controls are clunky in that they are software components, but they are not true object classes that you can inherit and extend in your own applications. But they get the job done, they are superbly language-independent (of course restricted to the Windows world), and .NET apps can mix and match ActiveX widgets with the newer .NET widgets.
So why .NET widgets? They allow true object inheritence, the crufty parts are better hidden and encapsulated away, and they are, well, the new thing! On the other hand, everything from the open-source Python to the commercial Matlab has excellent support for ActiveX but nothing for .NET widgets.
When someone does this analysis of .Net use in Vista, this is not just a matter of "ha, Microsoft doesn't eat their own dogfood." I really need to know what state my investment in ActiveX is in and where I need to go next. For example, the current support for 2-D graphics in .NET is rather hamstrung compared to what you can do with CreateDIBSection and ScrollWindowEx under Win32/ActiveX. On the other hand, if there is a whole 'nother graphics model under Vista requiring .NET to access, and if legacy ActiveX controls under Vista start looking like 16-bit Windows apps under Windows 95, then I have to respond to that. But if Microsoft hasn't seen the need to bother with reimplementing their disktop apps under .NET, maybe I am OK with my stuff. If they have reimplemented their desktop stuff to give it a Vista/Aero look but are not using .NET to do it, I sure as heck want to know what they are using instead.
In case you are wondering, I am looking to Java if I have to go through the bother of rewriting all my ActiveX stuff. First off, the BufferedImage.setRGB() and Graphics.copyArea are pretty m
One of the claims of the abiogenic-oil folks (J F Kenney and Russian colleagues, T Gold) is that no one has proven the mechanism by which buried plant or algae or other organic material turns into oil by being buried at the shallow depths of the "oil window." The conventional narrative on biogenic oil is that organic material gets buried, and at a certain range of depth (about 1-2 miles down), the temperature and pressure is able over time to crack the long-chain molecules in the plant material into oil.
The skeptics of the conventional narrative, the abundant abiogenic-oil quacks, whatever you want to call them, argue that the conversion of long-chain carbohydrates or plant oils into saturated short-chain hydrocarbons just doesn't happen in the oil window just as diamonds don't form in the shallow layers of the crust. They argue that oil can only form at the same depths (pressures and temperatures) as diamonds -- that is deep down in the upper mantle -- and that there are mechanisms by which oil and gas can migrate upward from those extreme depths and not disassociate.
It should be simple enough to take organic matter and apply the same squeeze and temperature and pressure as the oil window, mix in what you think is the natural mineral catalyst, and voila, get oil from "oil window" conditions, no? Even if long time is an ingredient, you should be able to get traces of oil for short time? The oil window skeptics argue 1) no one has ever done this, 2) it doesn't happen, and 3) it only happens in industrial processes where you are using metal catalysts.
The skeptics argue that you can't just crack long-chain unsaturated carbohydrates and turn them into short-chain saturated hydrocarbons. The skeptics of the skeptics turn around a say, wrong, it is not plant carbs but an unspecificed something else in organic matter that turns into oil. Anyone have any insight into this?
My guess is that the suits didn't realize how campy and unserious they had made it. The sort of comic book Batman as Dark Avenger (I mean hey, the character is a vigilante, so you would expect his character to be somewhat outside the law instead of a mere "civilian contractor" to an incompetent police chief) was developed, of course, in the Tim Burton treatment. The suits skipped over that part of Batman, perhaps to make it more kid friendly.
The other thing I take issue with is that once a society or a regime crosses a certain threshold of evil that they become Nazi Germany. There has been a lot of evil in the world over the years, but it is generally believed that Nazi Germany represented a particularly unique and malignant evil in that history. It also diminishes our rememberance how just how bad Nazi Germany was when we equate it to Milosovic's Serbia, Saddam's Iraq, or modern day China. While there are people who may argue this point, it is even believed that Stalin's Soviet Union, however lethal and repressive a regime that was, didn't quite rise to the unique combination of modern science and industrial production with a racist world view and mass murder that was Nazi Germany.
There are many ways that all regimes that practice evil resemble Nazi Germany, and people have even invoked this comparison for matters that bring shame to the U.S., but there are many ways that Nazi Germany was unique, and to call every bad regime a Nazi Germany diminishes the rememberance of those who suffered under it, and I would say that publically to Mr. Lanos.
On the other hand, Lantos has standing to invoke Nazi Germany on account of his personal and family history.
Why does this remind me of the kinds of things Medievel war reenactors do with their catapult and trebuchet reconstructions and their enthusiasm for flinging things in the name of historical research? I can just picture some bearded geeks in the year 3000 building and testing such a thing (by then we are all living in space colonies and New York City will be an ancient ruin where they will be allowed to do all of this) as a kind of off-the-wall seat-of-the-pants attempt at a historical recreation of an event believed to have taken place in 2050.
I could never get the hang of Microsoft tools for developing ActiveX controls -- I have done toy examples in ATL and don't want to even think about MFC. My biggest gripe is that COM interface development doesn't round-trip -- once you develop an interface using the wizards (gosh I hate that word for those lame tools) you are pretty much stuck. The wizards create so much code in so many places of "you-can't-touch-that" code, that if you need to change an interface, you may as well crumple the sheet into a wad, toss into wastebasket, and start fresh.
Delphi has a pretty good Type Library editor for fine tuning COM and ActiveX interfaces -- of course interfaces are cast in stone when you let them out, but I like to make changes to interfaces when developing a new library. Type Library editor does a pretty good job of allowing one to add to or edit COM or ActiveX interfaces -- the updates to your code are a sometime thing, but there are not too many places you need to change and the compiler error when something doesn't change automatically also help.
There is one serious flaw in Delphi-developed ActiveX controls -- they won't serve up events with the Python ActiveX support, with Matlab 7, and with any other system that does multiple registrations of event listeners on a control. I have a really ugly patch for this at http://www.medsch.wisc.edu/~milenkvc/pdf/multieven t.htm.
There is one big shortcoming to Delphi -- collection classes. C++ has the STL, Java has its collection classes, Python is a set of collection objects masquerading as an object system. The built-in collection types in Delphi are sparse and are wired into major parts of the VCL (you can't do a console app or a straight Windows API app and use those collection types without folding in a lot of VCL code). Collection classes built-in to the language/library instead of programmers rolling their own linked lists, hash tables, etc. are the vogue, and Delphi hasn't kept up.
But a colleague at work said, "No, it actually is a good product", I dropped what I was using at the time: would you believe RR Software's subset Ada compiler? Turbo Pascal changed all of that, and I never looked back.
That colleague who turned me on to TP later defected to Matlab. I am seriously looking at Java/Swing/Netbeans these days. Neither the compile-side or the runtime performance are anywhere near Delphi, but hey, Moore's Law and all of that so it doesn't matter anymore.
A variable in Python is a variable as in anything else, but a variable is a reference to an instance of a type that could be anything -- the referenced instance has a type as opposed to being some universal type like a string, but it can be assigned on the fly, and it can be a number, a string, an object instance, a class, or a function. I suppose assignment is just copying the reference, but as soon as you do anything with it, you have to somehow look up the dynamic type and decide to do something legal. And fail gracefully if called to do something illegal.
And as to memory allocation, everytime you touch a reference you are doing something with a reference count, and I believe there is some kind of primitive mark-scan garbage collection layered on top of the reference count to break circular chains. Are you going to hand translate that into C++ as well?
Greenspun's 10th law is this inside joke among Smug Lisp Weenies (TM) that any sufficiently complicated Fortran program (back in the day, today substitute C/C++ program) implements a good chunk of Common Lisp, only slower and with a lot of bugs. I may offend people to compare meek Python to mighty Common Lisp, but Python has a sufficient dynamic behavior to make the connection.
My advice on the reliable C++ program is 1) design to the level of having a clear idea of the architecture of your app before coding -- the classes, their purpose, their containing other objects, 2) for each object where a reference is contained in another object, do some kind of code reading/verification/check of conformance to a standard you have established as to how that object gets deleted in a safe way. It could be reference counts, auto-objects, caller deletes/callee delets -- just decide on what you are going to do and read code to see that you are consistent about it.
Ice may be a more minor constituant of these things -- a lot of the water may be more in the form of hydrated minerals than just plain water. SiO2 may be more abundant out there than H2O. If someone were making book on this kind of thing, I am wagering at long odds that when the first spacecraft brings back a chunk of comet, it will be more like the piece of road spalled off a pothole than the dirty, sandy ice filling that pothole.
Yep, I am thinking road pothole leavings -- a conglomerate of silicates, hydrocarbons, with a little bit of ice mixed in. Arthur C Clark has a plot point in one of his 2001 spinoffs that a spaceship could land on Halley's Comet, load up on slush, and use this for thrusting mass for some kind of fusion-thermal rocket drive, only the carbon in the slush would make for a spectacular incandescent rocket exhaust. My view is that the comet surface may be kind of crumbly, but it won't more very well and likely clog up some valves if used as rocket fuel.
The Matisse layout manager allows direct placement, but it offers guidelines and snap-to-grid hints, and it auto-places anchors for resizing. On the other hand, there is this JAR file one has to distribute with one's apps to get this new layout capability.
Could this finally be Java Swing as the VB killer? What I mean by this is that Swing is criticized for clumsy repaint, for ugly look-and-feel, for slow, etc. But is it good enough? VB apps are not known for speed or well-thought GUI design. For a lot of apps (whipping off a bunch of forms as a front-end to something) these are not considerations. What is a consideration is that someone versed in VB is not going to put up with Swing layout managers. If VB was the killer development app that kept people on Windows, this thing may help people break free.
M31 is perhaps the most universal theme for a galaxy photo in an astronomy textbook -- it is after all the most nearby of the big spirals and I have seen more pictures of it than I can count. The pictures in a way are a cheat because they are deep time exposures with dodgy color rendition. When you look at M31, you are looking at it as it really is, and I have always thought there is some cool factor to that over looking at pictures.
The other thing about M31 is that the fuzzy blob that you see is only the central region -- M31 is not a tiny object, it is huge, but the spiral arms and dust lanes are so low contrast it takes very dark skies and experienced observing to see any of it. On the other hand, one can see M32 in the same field of a wide-field eyepiece and then one can also see M110 if you have a big enough scope, dark skies, and averted vision technique. Even if you don't see the spiral arms and dust lanes, a person can see the landmark satellite galaxies, well known in photos, and get a lay of the land -- that the fuzzy blob is just the bright central part and that the parts seen on photos go a ways off. People used to looking at Mars or Saturn are thinking that telescopes mainly magnify things that are tiny -- M31 would be quite viewable without magnification if you had enough light grasp.
For criticism of look-and-feel of TCL/TK, Java Swing, what have you relative to VB, a person needs to look at the hodge-podge of a lot of VB apps -- I can't see how a TCL/TK or Swing app would be much worse.
What about Java? What about NetBeans 5? There may be some hangup on getting serial port access, but for the GUI stuff, NetBeans 5 may be the new VB/Delphi.
The age old problem with visual GUI development is that you can do absolute placement and then what happens when you resize the form? Or you can use layout managers (Java Swing) and then you have to wrestle with the layout manager to get the placement you want. NetBeans 5 has the Matisse layout manager -- I played with it and it seems to be the best of both worlds. You can drop and drag widgets in the form designer, but it gives hints regarding good alignments and regarding anchoring to boundaries for resize. Oh, and NetBeans is a free-as-in-beer download.
Java Swing, you say, not the native look for Windows. A lot of native Windows software is a hodge-podge of look-and-feel anyway -- Swing is no big deal. Besides, if you go with Java, you are not tied down to Windows.
I have kind of wondered about this sort of outsourcing in my own work, but I am wondering about the degree of independent thought of the coders and what kind of spec I need to supply.
One of the projects I have is implementing a wait-for-vertical retrace in Java. Java has BufferStrategy, but you only get vertical sync on page flips in full-screen mode and only on Windows. I have gotten a wait-for-vertical retrace working under Debian Linux as a JNI module written in C++ using OpenGL/GLX/X calls, and I would like to port this to Solaris, OS X, etc. So can I tell some dude "Here are the C++ source files, here is my makefile, here is a Java test program, go make this work on all of the other platforms by finding where the headers and libs are and/or download the needed drivers to make it work or tell me why it won't work on a particular platform, and if GLX/X on OS X doesn't support vertical retrace, tell me if there is some other hack to use on OS X"?
A lot of what I spend my development time on is stuff like that -- the rote coding to a spec is something I know how to pound out the code and don't need to outsource. For large projects, one should draft and maintain specs instead of just hacking code until it sticks, but it seems the writing the specs is the bulk of the work and the outsource coder is a sort of human 4GL. And for tricky stuff -- that is using libraries and OS features that are not well documented -- there is no substitute for hacking.
But before going down that path, the folks in India should listen to this guy http://www.dunnspace.com/home.html#Columns. Getting into orbit is fundamentally different than flying an aircraft, and this Arthur Schnitt fellow argues that the max performance route used in aircraft is too costly. He got this idea of Minimum Cost Design from the Thor-Agena launcher for the Corona-Discoverer spy satellite -- the Thor booster was a lot cheaper than the Agena upper stage on top -- that cost had little to do with size in rockets, and by building big rockets with cheap methods (the Big Dumb Booster), you could reduce the cost of space launch
An old VB/Delphi/whatever Windows developer downloads NetBeans, fires up the GUI designer and asks, "this Java Swing stuff, how hard can this be?" So they click on a button widget, drag it to a form, and fire up the application. They get this big honkin button which takes up the entire form. "No problemo, I will simply drag this button over into a corner on the Form Designer." Fire up the program, and you still have a big honkin button taking up the entire form without any apparent way of changing its location.
You see, the VB/Delphi/whatever Windows school of GUI development is pixel-based and folks are used to using the Form Designer to place a widget on the form and then tweak locations and placement on a pixel level to satisfy their client/bosses/customers. Yeah, yeah, when you resize the form, now what? But for a lot of people, they do pixel-level layout using the form designer and kind of assume no one ever resizes the form. Also, a switch between large font/small font on Windows can jazz up a lot of Delphi widgets, but we will assume no one ever makes that switch either.
The Java Swing people know about layout managers, and layout managers solve all of the above problems -- font size changes, form resizes. But the layout manager world is a bizarro world to the form designer pixel-placement world. It is kind of like the gulf between WYSIWYG and TeX/LaTeX -- Word and its WYSIWYG cousins are like the pixel-placement world while the TeX world is related to layout managers. But just as TeX word processing is largely generic text editor plus document preview -- does anyone have a workable TeX/LaTeX WYSIWYG -- do layout manager GUI more properly belongs in the vi/emacs/pico and javac world -- does it even make sense to have a graphical form designer in the layout-manager world.
So to VB people, the .NET Form Designer is quite comfortable and familiar and Windows Forms is pixel-placement friendly while Swing/Netbeans is in the bizarro world of layout managers. I am not saying layout managers are bad -- I do a lot of word processing using LaTeX -- it is just that people who are not indoctrinated in them get frustrated real quick on Java Swing and return to what they are used to.
The first roadblock is how to run a program from the IDE. Yeah, yeah, in Java you have to specify which module contains a class with a static main method, but still, bringing up a project and figuring out the Run dialog can be an effort.
The second roadblock is how example programs are packaged -- some kind of .zip format and unzipping when you load projects -- still haven't cracked that on.
The third annoyance is if you have a bunch of .java files that compile to a bunch of .class files, and you just want to use Eclipse a text editor for the .java, as a compiler for the .class, and perhaps to run a .class file containing a static main(). Eclipse is real fussy about existing/new directories, and yes I have generated projects to encompass collections of .java files I had previously maintained with a text editor and compiled with javac, but I can never remember from one time to the next how to do it.
Last time I mentioned any of these issues I was modded Troll and told I was an idiot (gee, people are that sensitive about any criticism about Eclipse). Eclipse may be good, Eclipse may be powerful, but Eclipse has a lot of the stamp of IBM on it that they have their unique way of doing UI's, and I second that observation.
Linux (OK, OK, GNU/Linux) was meant as a Unix clone, and it is only natural that Linux has displaced Solaris, whatever Silicon Graphics was doing, and so on.
For people raised on the DOS/Windows culture, it is not as natural a progression. A lot of us (those doing lab computers for data collection, using computers for scientific computation, other academic pursuits) came to DOS and later Windows because . . . computers for this sort of thing (largely VAXes and later workstations) all ran Unix, and you had to have a big enough grant to afford not only the hardware but the Bearded Guru (TM) to keep such a system running. DOS and later Windows was in part a go-it-alone and do-it-yourself movement so the scientific luser community would have some financial and technical independence. While DOS/Windows came to require a guru culture of its own, a lot of us renegades acquired that expertise while we didn't know much Unix beyond ls, cat, hidden config files started with a dot, and VI has two modes: insert mode and beep mode.
The academic luser community could have adopted Linux as a go-it-alone replacement for big iron Unix, but for a variety of historical, cultural, and technical reasons, we went with DOS and Windows.
For the longest time, Microsoft was the "good guy upstarts" compared with the commercial Unix's. Microsoft acted tough with vendors and software developers crossing a certain threshold from the beginning, and the acting tough with users (product activation) is much more recent. But the academic luser community is stuck in the Windows world and is making toe-dipping attempt to try Linux out to break free, and it has been tough going.
But those NASA/JPL dudes running Linux come from people migrated from workstations I bet -- I would like to see an example of a luser community making a major effort to get going on Linux.
Forget want or need. I don't know where in my house I can even put a 50 inch TV.
Without going into personal details, Bernie Mac's standup routine in the Spike Lee "Kings of Comedy Movie" will disabuse you of those romantic notions regarding married sex life.