That looks excellent, unwesen:) I'm impressed with the drive to modularity and working with multiple output, and kcachegrind looks just plain purdy:) It's nice to see profilers moving towards instrumenting behind the scenes at profile time, requiring no more from a user other than turning on standard debug information.
Thanks for the pointer!
(*laugh* Reading valgrind's documentation, I get a chuckle about having extra instrumentation specified with a "--skin" parameter)
There is a thery that there is little or no dark matter, and the difference is accounted for by the assumption that the inverse square law for gravity fails at large distances
I've read one paper that posits that very thing - this particular one is from amongst the push-gravity theorists, and basically states that the graviton "shadows", like light, can slowly fall off at faster than inverse-square due to interference with matter.
There are other possibilities, of course, including intergalactic space containing much more in the way of hydrogen molecules (from which it's difficult to get an absorption, never mind an emission, spectrum at such low temperatures, unlike hydrogen ions... well, protons:) than we would have suspected, or there's always the field of plasma cosmology, that puts a at least as much emphasis on currents as on gravity, and also provides for a non-black-hole-dependent theory for why galactic jets form.
After years of developing, I really take to heart two things:
Premature optimization often makes better optimizations down the line much more difficult
It's 90% guaranteed that the slowdown isn't where or what you thought it was
Profilers are the best thing to happen to performance since compilers - really. I encounter a number of truths, but many myths about what degrades performance. A few examples of each:
Performance degraders
Mass object construction
Searching sequentially through large arrays
Repeated string concatenation (there are techniques to mitigate this)
Staying inside critical sections for too long
Not performance degraders
Lots of object indirection
Lots of critical sections
The "lots of object indirection" myth is one I encounter frequently. Object A calls Object B calls Object C, and it "intuitively" looks like it must be slow (Computer A calling Computer B, etc. would be slow), but even with stack frame generation, these are lightning fast compared with even the likes of "date to string" functions, never mind line-drawing commands or notification-sending.
The reason that particular myth is dangerous is that it's the single most pervasive myth (IMHO) that leads to premature optimization. People take out layers of object indirection and make it harder to put in better solutions later. I had an object that recorded object IDs in a list and let you look them up later. If I had "flattened" that into the routine that needed it, I might have effected a 0.1% speed increase (typical range for many premature optimizations). As it stood, because it hid behind an interface (equivalent to an ABC for C++ folks), when I had finally implemented a unit-tested red/black tree, it was trivial (~5 minutes) to drop in the new functionality. That's not an isolated case, either.
Mind you, I profiled the program to determine the slowdown first. Searching on the list, because so many were misses (therefore full scans), the search was taking up 98.6% of the entire operation. Switching to the red/black tree dropped the search down to 2.1%.
All in all, if you have a slow program, profile it. There is no substitute for a well-written profiler. Stepping through and "feeling" how long it takes in a debugger, while it can point you in rough directions, will miss those things that take 50 ms out of the middle of each call to the operation you're checking. Manually inserting timing calls can be frustrating enough to maintain or slow down your program enough that you can't narrow down the performance hit.
gprof works well with gcc and its relatives (make sure to add -pg to your flags), but I'm not sure if there's a good open source option out there for people using other tools that doesn't require you to alter your source.
In the Windows world, we recently got in the professional version of AQTime 3. It's an astounding package, allowing you numerous reports, pie charts and call graphs, saving the last few runs, calculating differences in performance between runs, allowing attachment to running processes, on top of a pretty nice way to define areas of the program to profile. The single nicest thing about it, though, is the performance. We turned on full profiling (that is, profiling all methods in all modules, including all class library and third party components) on the largest project we had, and it ran with perhaps a 30% slowdown. If you've used profilers before, you know how astounding that is;)
Profiling applications always surprises me. In one case, a space-making algorithm I was running on controls seemed a little pokey; I found out more than 50% of the time spent was on constantly verifying that the lists were sorted. Today, I was investigating a dialog that looked like it must hav
If you're working in Java, you should add assertions to your toolkit.
Amen to that; that goes for any number of development environments that have assertions or pre/postconditions as an available construct.
I use assertions anywhere that a violation of the condition would be a programming error, instead of a configuration or input error. Pass in null into the constructor? No! Pass in a negative number for the distance? No! Use this resource object after return_to_pool() has been called on it? Nuh uh!
Just having assertions be a gatekeeper for "impossible" circumstances catches a lot of those very selfsame "impossibilities".
I do a lot of concurrent programming these days, so the rules count triple. It's almost always something stupid, too, like using the ID of a constant instead of the value of the constant (in COM programming, varNull instead of Null), or forgetting to declare support for an interface. Adding assertions to other peoples' code can really track down anomalies pretty fast - someone's red/black tree algorithm had some cases where the root object (which should have no parent) got assigned, causing all sorts of subtle mayhem.
Along with this, I would highly recommend unit testing - highly. Based on the number of failed unit tests I've had over the past year, some twenty very subtle bugs would be haunting me still. Now, at least to a much higher degree than otherwise possible, I can "prove" that my objects and algorithms work, at least as advertised.
Unit tests also really help out when swapping out algorithms. I swapped a list for a much faster red/black tree (was doing thousands of ID lookups). Two unit tests failed - and both had to do with what happens if your object ID matches a blank ID. Easy to fix, but I wouldn't have had a clue.
Unit test also help out when porting. I have a fairly hefty framework in Delphi. Porting that to.NET took about a week to get working - a few days for the syntax changes, a couple extra to get green lights on the unit tests again.
Unit tests are, unfortunately, one of those things that you can agree with in principle, but figuring out how to do useful ones that don't seem like makework takes a leap. A small leap in retrospect, but a leap that can be hard to find nonetheless. Techniques for cutting down repetition, emphasis on negative unit tests (i.e. equally important to explicitly state that you can't do X), creating mock objects that record actions to compare against expectations, all are techniques that are a little hard to extrapolate from simple examples.
Assertions and unit testing might not be "debugging tools" in and of themselves, but they certainly help prevent bugs from slipping in unnoticed.
Saying "mass warps spacetime" doesn't explain how it pulls that stunt anymore than answering who was pushing Kepler's brooms.
Have always been curious about that myself. After all, the usual analogy made is that of a rubber sheet, in order to reduce the dimensions... but the analogy requires gravity in order to work. The sole thing you gain by such an analogy is reducing gravity from something radial (in towards an object) to something linear ("down" through space).
...but why should there be a stream of... somethings... going from 'top' to 'bottom' in the fourth physical dimension... interacting with our cosmos?
I've heard some folks posit that gravity is 'resistance' of matter to whatever medium space is expanding "into" - space has much less resistance to it, and so you get little funnels from the difference. Mind you, that does rely on a 'closed' universe, and I don't think that's the one in favor in the presses at the moment:)
Personally, I'm most curious about the LeSage-type particle gravity theories - the "push" theories instead of the "pull". I've read a number of variations on the theme and all of them have some testable portion, whether it be gravity fall-off, shielding anomalies, precessions, thermalization of gravitons absorbed (causing planetary heating above any caused by radioactive breakdown), upper bounds of density (there would come a density point where ~100% graviton absorption happens - which would put a limit on compression by gravity)
I find the 'frame dragging' concept a little odd when applied to a framework that looks, for all intentions, as though it's geometric - spacetime bending, sure; spacetime twisting - ? Having spacetime be continuous, or even discrete-but-completely-connected, would imply somewhat that the 'twisting' of frame dragging should be resisted somehow. The only easy way out of the conundrum is to posit spacetime being particulate - water and air have no problem forming vortices when spun. So, is spacetime particulate?
The most annoying thing is that you really can get to the same formulae multiple ways, and often we get stuck with the first analogy that "explains" things until we start figuring out the edge cases. Case in point, it took a long time to turn Plato's optics around (although, to be fair, the theory of emitting rays from your eyes works really well for raytracing:)
Looking forward to hearing of the results of this. It would be pretty bizarre not to find frame-dragging at this point:)
...but not as bizarre as finding Kepler's Brooms:)
*laugh* I don't deny the worm's trivial requirements relative to ours, but rather, that our brain size and mass seems disproportionately large. Move up the tree a bit and take a look at bird brains - a lot going on in there, vocals, goal-seeking, social dynamics...
My main thought was sheer awe at the amount of extra space required for human-style intelligence, especially in the prefrontal cortex. We should be able to hold more than 5-9 things in our heads at once with all that;)
Well, in the case of blind people, the visual system of their brain is taken over by their auditory system.
I'd read that as well, although I'd like to know whether it's mostly a feature of blind-from-birth folks, or whether the recently-blinded can eventually end up with full visual cortex reuse.
One of the impressions I have from reading is that the olfactory, auditory and visual systems are near-clones of one another, right down to the triple layers (visual system has two sets) and generated contour maps (even smells make a "picture", although "pictures" of the same smell apparently drift from day to day).
What that might indicate is that the function of many parts of the visual and auditory systems isn't "pre-determined" per se, but comes from what they grow to be hooked up to, which is typically from the appropriate sense organ.
It's not too surprising that the brain's short-term visual cache would be closer to the visual cortex. What I would like to know is how closely the visual cache is related to intelligence. Does it need actual visual input, instead of just imagined, and if so... <facetious>do you become marginally dumber when you close your eyes?</facetious>
From reading Synaptic Self, the "general" cache and CPU area would seem to be the prefrontal cortex. It can activate memories to work on (the closer the current emotional state it was recorded in, the better), and hold a few things to work on. Perhaps there are many more specializations yet to be uncovered, but I'm struck at the sheer relative size of brain required to actively think and plan a next move. Considering that even a worm brain can get its owner around, you'd think our capacity for juggling thoughts would be encyclopaedic.
I'd be curious as to what connections this area has to the prefrontal cortex - I've heard of the spots tests before - I don't recall it being related to general intelligence.
Addressing the question of how cache gets spat out to hard drive, as it were, to keep thoughts in slightly longer-term storage, it looks like thoughts have to be put through the hippocampus and entorhinal cortex, where they will slowly get rewired (indexed?) over the course of about two weeks - about the length of memories you can lose under strong electroshock therapy.
So many small functional pieces of the brain; I'm struck by how independent the sections of the brain are, by and large. Large-scale coordination has to go through a secondary 'chemical drip' system, from neuromodulators released by non-connecting nerves throughout the brain. It's that level of coordination required to put your brain to sleep or wake it up, amongst other things.
I'm looking forward to more decoding of the brain's structures - narrowing down specific activities to a small area of the brain like they did is fantastic.
Re:For those with Celestia
on
Titanic Saturn
·
· Score: 1
I couldn't get your link to work, even with revisions, but the view from around Saturn's satellites is just gorgeous.
Perhaps it's not the sole job of future probes to get us better textures for Celestia, but it'll be a nice side-effect:)
For those without Celestia - do yourself a favor and download it! It's one of the best-feeling 'space exploration' simulators I've encountered, and you can't beat the price;)
Now, all we need is this as the base engine for Elite III: More Stars Than You Can Shake A Pretty Good Stick At.
No, but bright people have created some of the most awful rotten code I've ever maintained.
There are a number of reasons why seemingly bright people write latrine-awful code:
Avoided maintenance
Doing a lot of new development and never having to support/maintain it produces a significantly different impression of one's own coding than having to stay the course and add features into whatever minefield one has created.
It wasn't their hobby
Hobbyists bring a lot of enthusiasm, and often start relatively young, giving them a lot of exploratory experience, and often a passion for the craft.
Despite best intentions, it's simply harder to feel the same zeal for self-improvement or qualtify of workmanship when one has gone to school/college/university in order to learn programming "to get a job". All analogies between musicians and programmers in this vein apply:)
First time out of the blocks
Especially out of shorter courses, the survey given of technology and techniques can be relatively scattered, with a lot of focus on the technologies available, and much less, if anything, on how to do projects, testing, or design. OOP principles can help, but like principles of technical writing, they can only give you the guidelines, not the creative content.
Biting off more than they can chew
Some bright people will be positively filled with bright ideas and "wouldn't it be cool if...", and can put themselves on paths to the right functionality, but that require algorithms they don't have the foggiest about, or techniques they have little practice in, and they can get stuck trying to fill in the gaps.
If you doubt this is possible, ask someone with a starting set of skills whether they'd like to make a game, and how possible they think it is:)
In slightly larger projects, this can also manifest itself as an inability to delegate - which can start being problematic if team members are waiting on something to start with.
Distractable
Vis-a-vis your comment about professional development being boring, distractability is a common side-effect in bright folks who just want to play, and not get bogged down in the nose-to-the-grindstone details.
These are the folks who think of something cool, then spend two months trying to get a feature that isn't core, wasn't asked for, etc. to a working state. This can overlap with the next problem...
Procrastination
Whether it's the thrill of deadlines zooming by, poor vision by project managers, team leads or management, or just suddenly realizing that people are serious about wanting that program done by three weeks today, some code is written badly because it's written fast and at the last second.
Gizmophilia
Some code isn't so much bad as it is confusing, laden with whatever behaviors, syntax or components are out near the edge of what's defined in the class library and language syntax.
Whether it be quadruple-nested ternary operators, naming variables for appropriate characters from a favorite videogame, mixing in excessive amounts of system calls to 47 hard-to-install third-party libraries or trying to overload binary negation for strings to mean "how long is the string", these programs can work, or start out working, but the code is often not human-readable, or is hard to set up and build in another dev environment.
Poor debugging skills
Sometimes, programs start out readable, but then the code runs into a problem. Debugging skills and coding skills don't always live in the same person, and the desperate coder, wondering why something isn't getting called, or is refreshing in the wrong order, doesn't and can't properly trace what's happening, and so starts to add in duplicate calls, strange exit strategies, state variables all over the place. The wiring can start to cross really qu
I'm glad to see some DRM-free alternatives, especially for the purposes of buying music and playing it on a Linux box.
I asked the question in #linux on FreeNode a while back as to where I could go buy and download legitimate music through Linux, without owning an iPod (or using the DRM "crack"), or needing Windows Media Player 7.1 (or 9.0) on a Windows machine, or having to burn to CD under one OS so that I could have it on Linux. Not much in the way of answers, and one heart-felt "if it's only one track, you're just as well to use P2P". I'd still rather buy it if I could - I like some songs and can afford them - I'm not out for a free lunch.
For commodities like this, I want a no-nonsense license. I'd like e-music vendors to say,
"Buy it, listen to it, throw it on your machine at work, put it into a compilation for your significant other - anything reasonable you'd do with a live CD in your mitts. We trust you that far, we know that by coming here, you're not likely to be a P2P weenie with an entitlement attitude. We figure you'll be happy with your music, and come back and buy more and tell your friends. We're working on some forums and rating/comment systems to help you sort through the overwhelming amount of music to find what you'll probably like a lot faster. And thanks."
This, MagnaTunes and a few others, even if the selection may not be that great for someone with some mainstream or retro music tastes, is a good step in that direction.
It feels pretty strange in this connected day and age not to be able to track down music I'd like in record time. It's certainly not the lack of willingness to purchase:)
I think that Close is called in the destructor anyways, but the destruction is called when the garbage collector clears the object. And you don't known when this will happen.
I took a look at the reference material for the.NET framework, and apparently Finalizeis declared, so you can actually let it go out of scope and have it close for you. That seems to actually be by and large how.NET classes that wrap around external resources work.
So, you can keep your code as simple as you used to. No __finally required.
You do incur the finalizer overhead if you leave.NET to do the finalization for you, so if you for some reason need to make sure the file stream close is efficient and doesn't make the GC hiccup (e.g. if you had a lot of threads doing many file stream opens/closes), you'd use the much uglier, but more "efficient" syntax:
FileStream* fs = File::Create(path); try { AddText(fs, S"This is some text"); AddText(fs, S"This is some more text,"); AddText(fs, S"\r\nand this is on a new line"); } __finally { if (fs) __try_cast<IDisposable*>(fs)->Dispose(); }
finally is just a declarator for a section of code that runs whether you get an exception or not. I use them all the time for things like critical sections and constructs like setting "currently_updating" variables back to false no matter what goes wrong in a method.
But think about a case were you forget to implement the _finaly block. You write to the file and later you want to delete it (eg. because it is a temporary file). This delete works if the GC has finlaized the Stream, but fail sometimes when the GC has not yet finalized the Stream. I think this mistake is harder to find than the forgotten delete.
If they had forgotten to add in a Finalize, that's exactly what would happen. However, they did, so no worries:)
If you come across a class you're wondering about, take a look in the.NET documentation for the class, look under members, and see whether Finalize is in the "Protected Methods" section - if it is, you don't have to worry about their use. If you see Dispose in there, you can use the ugly Dispose syntax to get rid of the object more nicely for the GC. (The first thing most calls to Dispose do is GC->SuppressFinalization(this), which removes the object from the complex finalization chain.)
Hope that helps:)
P.S. Doh! Does anyone know how I use <ECODE> tags in HTML Formatted posts and have/. maintain the spacing? Is it browser dependent?
Garbage collection really does a number on disposal behavior; it's been driving me a little crazy as well.
There are, for performance/control reasons, four possible paths for getting rid of an object:
Just the memory gets reclaimed - by far the most efficient, but you either have to not have or not care about any resources your object may be holding onto.
Same as above, but you call something to let go of the resources manually, and usually wrap it in a finally (as in your example)
Implement IDispose - in many.NET languages, this is accomplished by making a virtual Dispose method. This way is mostly a convention; it gives you and others something standard to call. Wrap up your calls and call Dispose, or use the syntactic sugar someone here posted.
Implement a finalizer - the least efficient of all. In C#.NET and Managed C++ (IIRC), this is done by adding a virtual destructor. (In other languages, you make a protected Finalize method) The garbage collector watches finalizable objects closely (hence the reduced efficiency), running the finalizer (destructor) as soon as the object becomes unreachable.
So, in your example, if you wanted to make it easier to deal with files and were willing to take the hit on the finalizer, you could do:
class FileStreamEx : public FileStream { public: virtual ~FileStreamEx(); }
FileStreamEx::~FileStreamEx () { Close(); }
...and use FileStreamEx instead.
Might want to check, too, to make sure there isn't already something like that in the framework:)
For example, the braindamaged distinction between structs and classes as value and reference types respectively.
I, for one, am glad they put this distinction in. The difference in treatment between the two can have some profound effects on the way allocation, array handling, and memory footprint operate.
With an array of objects, you get an array of references (checked pointers) to the objects, requiring an allocation per object (the size of the allocation depending on the particular derivative) and indirection to access the pieces.
With an array of value types, the size can be predetermined (in much the same way stack-based object variables were in C++) and the items therein laid out end to end, giving a single block allocation and no extra reference per item required.
Some of these pieces are especially important because of the Managed Code model - you can't lay out a stretch of bytes and cast it directly back and forth to an object type. Having tricks like this that can let you keep your performance and still declare the code provably 'safe' is invaluable.
I've been playing with C# and Delphi-for-.NET, and ported one of my frameworks across. It's been an interesting experience - I was expecting something insubstantial when I first heard about the initiative, but now that I know Anders H. was behind much of it, its low disagreeability factor is well-explained:)
Operator overloading, automatic boxing and unboxing of primitive types, and properties come to mind. The first two, AFAIK, will be in Java soon,
I attended a seminar on the Java 1.5 extensions being introduced, and they were: generics, autoboxing/unboxing, varargs (for lack of a better term:), improved and generic-aware for syntax and enumerations. Interestingly, generics made a strong case for a number of the other features, especially boxing (we were treated to "before-and-after" syntax possibilities for each feature). Looks interesting.
and properties are just syntactic sugar to replace observer methods.
You're thinking of delegates, and in a way they're syntactic sugar on observer methods, but besides cutting out a lot of need for anonymous or named action observer classes, they implement some of the Active Object pattern with BeginInvoke, which will asynchronously delegate something until EndInvoke is called. Very useful with remoting calls.
Properties on the other hand are syntactic sugar. Goobery syntactic sugar over the myField()/setMyField() set. I do make a lot of use of them in Delphi, and all they do is basically tie the getter and setter together in an explicit way instead of relying on convention. The main beneficiary of this is the IDE/inspection tools, which can query reflection/RTTI to find out what to display and how to hook up a property update. JavaBeans was in part based on Borland's experience here (I was quite shocked looking at the docco for the JavaBeans and seeing things with names right out of DsgnIntf.pas:) - I believe they ended up relying on naming conventions for Java's purposes.
The ACS uncovered galaxies that existed 800 million years after the big bang (at a redshift of 7). But the NICMOS may have spotted galaxies that lived just 400 million years after the birth of the cosmos (at a redshift of 12). Thompson must confirm the NICMOS discovery with follow-up research.
July 21, 2004
Hubble's NICMOS may have just spotted galaxies that lived a mere 150 million years after the birth of the cosmos. "We should be seeing something less-defined by now," said Carrot Top's* father, "This would seem to indicate that galaxies form faster than we ever thought possible." Research scientists reacted to the news, "This is the strongest evidence yet for the presence of supersymmetric photino strings," said Ablebaker Charlie of Berkeley, "finally, we have a solid lead on the dark matter that guided galaxy formation in the early universe".
November 10, 2004
LATE BREAKING NEWS: Hubble's new IFDEF camera has picked up the oldest galaxies yet on record. If confirmed, these galaxies would be an astonishing 14.1 billion years old, approximately 400 million years before the creation of the universe. When the news was broken today, theoreticians and science publishers were quick to stat&]/@^@CCC!0__NO CARRIER
Unit testing does not require eXtreme Programming. On the other hand, eXtreme programming does require unit testing. We've studied XP's practices, and they seem to be roughly broken into two groups: programming for ever-changing requirements, and quality assurances (refactoring, unit testing) to make sure the code doesn't fall apart.
As many anti-XP pundits will point out, unit testing is worth applying to any project that you can apply it to, and there are precious few that can't.
I do a lot of framework-level programming, and I must say that stability, as well as my confidence in the code, has increased substantially from putting unit testing into the mix. Some folks advocate TDD (Test-Driven Development) in the canonical sense (test first), but I find that the completely up-front test creation works in practice only when you have rock-solid easy-to-translate-into-source-code checklisted requirements. I compromise, and build the tests after the interfaces, rough algorithm and rough support objects have been put together.
Here are a few things I've learned over my unit testing experiences:
If the individual test methods start to get beefy, spin off the pieces you can into English-sounding methods on their own, especially if it's something you find yourself using in multiple test methods. Methods for creating test objects and comparing the test results are usually prime candidates.
If you have a facility to use generics in your programming, use it for anything you've had to do exactly the same 3+ times over - you can cover off the generic with a single unit test module
Classes are easier to test if you make liberal use of interfaces or abstract base classes - this lets you create classes for use by the test that implement extremely rudimentary functionality (instead of asking a web service for a value, it returns "1", or gives back an error) and/or that can be used as counters/loggers for the number of times and with what parameters the services are requested.
Negative testing is important - if you don't explicitly test what out of bounds, null or otherwise invalid input parameters and states do to your object, you're leaving yourself open to a host of "undefined behaviors" which can cause bugs.
For unit testing lower-level classes, you'll often find that a unit-test-per-method works well. For unit testing higher-level classes, you'll find yourself keeping the class the same, but the test methods will vary the data that gets fed into it.
I haven't figured out a good means to unit test concurrent code, but you can often stack the deck for fast-running processes by adding in delays in key spots to extend the exposure to weak spots.
Unit testing isn't for everything. It coughs and sputters a bit when you don't have full control over the environment (databases, sockets, network configuration, user interaction). You can shoehorn it in, but it's usually better left for the likes of regression testing and functional integrated testing.
For a quick start to functional testing, we've started test-driving
TestComplete at our office; it's proven itself to be a capable tool (our lead QA man has put up a sign on the computer entitled, "I am Q-Tron; I Test Software While Mere Mortals Sleep" - it has been testing out communications while he sleeps:)
Now that I've got my machine back up and running with a full fresh install of Fedora (too much fighting trying to upgrade from RH7.3 the source code way - yikes:), I am back to running my background SETI@Home and Folding@Home.
I've compiled the 2.4 Kernel targetting Athlon before, and it made a significant difference in speed to those relatively intensive tasks. I informally benchmarked it simply by noting how fast./xsetiathome performed when you ran it with a custom kernel versus the i386 kernel (at the time, having to run NVidia's driver setup each time - just wasn't as happy linking against the custom kernel). Custom kernels, even ones where all you do is tell it which processor to -march against, are fast, and you can tell.
There sure were a lot of drumbeats in the pilot episodes, although we caught strains of it during the ceremony.
I surmise that they may get their own music once the go-ahead is on. It might take a little while to get some decent music unless they prepare well in advance; Stargate hobbled along with snippets of the original movie's music in a not-quite-audio-balanced form for a while until they managed to work in new arrangements more suited to a TV series:)
What if gravity doesn't quite work this way at galactic scales?
I remember reading through Pushing Gravity; one of the papers in it posited that gravity does weaken faster than r^-2 at larger distances. One of the by-products is that the outer edges of galaxies need less mass to keep their shape.
The details were more interesting than that - I'll have to dig the book out of hiding.
Re:Anders leaving Borland - a blessing in disguise
on
How C# Was Made
·
· Score: 1
I remember the scores of Chicken Littles that came out of the woodwork when Anders got 'fished' from Borland. Regardless, under the hands of Chuck J and others, it still went along swimmingly.
It's actually pretty interesting the ties between some parts of Borland and Microsoft's.NET team. (I was at BorCon a couple of years back when Anders did a keynote speech, and did demonstrations of ASP.NET... using Delphi 7's.NET Preview Compiler to very good effect.) They've had to face a number of the same challenges..NET actually has to approach the Windows API in the same manner as many decent class libraries have (glad to see that the.NET framework is miles away from the spaghetti vomitus of MFC, likely in part an Anders influence). Borland had to work around the idiosyncracies of the Windows rich-text APIs in making their TRichText control. Such experiences are valuable. In return, Borland gets some excellent heads-ups on the technology.
I've had a chance to use Delphi 8/for.NET, and I must say that Danny Thorpe, Corbin Dunn et al have done a marvellous job in making porting to.NET easy. Compared to porting to Kylix/CLX (which 'everyone wanted', but nobody would pay for - *laugh*), porting to.NET was a breeze. I even ported DUnit across while I was at it:)
As to missing generics, I, too, missed some sort of generics. I loved Ada's model for generics, loathed the way most C++ compilers handled templates (more specifically at the time, how they handled errors and tracing:), although I got good mileage out of them.
I have an implementation of Rossen Assenov's generics for Delphi (using a trick similar to that in C++ before the 2.1 standard) here on my web page. A few limitations (which you can get around if you're not averse to 2-layer-deep includes:), but works like an absolute charm, and it does still work in Delphi for.NET (though you will have to ensure you aren't using pointers in your list classes if you want to be managed-code compliant:).
Adventures in building KDE3.2
on
Review: KDE 3.2
·
· Score: 1
I'm a relative Linux newbie, but I've managed to build the Linux kernel before, managed to sort out various and sundry RPM dragon-eating-its-own-tail dependencies. *laugh* I didn't know what I was in for when I tried to build KDE3.2 on an ol' Red Hat 7.3 desktop.
Those in the know can imagine how many packages I needed to upgrade:) Probably on the order of 45, all told, and I think I was getting off lightly. zlib, freetype, fontconfig, libart, the gnu utilities, etc. etc. etc. Even that was fine:)
Not wanting to screw up the source code installation, I pulled down a copy of Konstruct to have it download and appropriately build things. I RTFM'd, I set it up, and watched it for the first little while. It was merrily getting files, so I went off to work.
When I came back home, all was not well. It couldn't find qInitImages_designercore(void) in the Qt 3.2 designer compilation. I couldn't resolve that one, even after I figured out the odd directory configuration (and it is odd - trying to locate the source for things libtools was running on). libdesignercore.a (I think that was the file) had the identifier in it, and Google didn't help me out. So I'll avoid the designer for now - I just want to get this compiled! So, out comes the// comment gun and bye bye to the extern reference in the two problem files.
Onward the compile went, just dandy (while I lazily web browsed and mahjongg'd in the background), and then spew out comes a list of errors in the (IIRC) librtld compile and screech goes the compilation. Ages of Googling later (how on earth would I do this without Google?!) I find out that Konstruct will inappropriately build the config.h file in that particular circumstance. My autoconf package had not been the right version for this, so off I upgrade again.
I got a clue from the discussion that it was the config.h and config.h.in that were problematic, so I look into trying to auto-configure things on my ownsome. Reading the man pages for autoheader, it seemed the right man for the job, so I autoheadered the kdetools directory, autoconf and./configure (it takes a little longer than last time, so I think it's making progress:), then make clean && make. Doesn't make it five seconds before encountering "unparseable tokens" in the config.h file (which looks just utterly fine, on visual inspection).
I then came across something on the 'Net which claimed that automake Makefile.cvs was something which could cure cancer, stop SCO in its tracks, and help people out of makefile conundrums. Off I upgrade again:) - the Makefile.cvs won't have anything to do with my current automake.
(It is nice that Linux is pretty good about facilities to make sure that you can be warned about obsolete versions, but I'm startled at how quickly libraries and programs are deprecated.)
automake, true to its word, runs through and sorts out the mess. Takes a goodly long while to recompile things (I was most of the way through kdetools when the error happened in the first place), but I'm happy to be off and running!
Some time else in the middle of all this was another configuration error, complaining that KDE couldn't continue compiling because my 'current version of aRts was too old'. Given that aRts is included in the distribution, that seemed pretty weird, GnoRPM and I resolved just fine. What a truckload of avoidable warnings, though - g++ was having a hissyfit! I thought errors in template files in VisualAge/C++ were mysterious and threatening, but <yoda>no candle to this did they hold</yoda>.
Hours later, it coughs up its lungs again. What's it this time? A g++ internal floating point error (147). Aaaaaaaaaaaaaa! (I was sensible enough not to pull out my own hair
No prediction of the cosmic microwave background's blackbody temperature prior to the CMBR's discovery was ever thought very likely correct
Predictions were made, though, from Steffan-Boltzmann laws, of blackbody cosmic background radiation in an infinite/static universe configuration by Guillaume in 1896 (5-6K), Eddington in 1926 (3.18K), Regener (2.8K) and Nernst (0.75K on a tired light model).
It is the mere existence of the microwave background -- its omnidirectional uniformity and amazing blackbody spectrum -- that is the prediction of interest. And contrary to assertions from people, these are extremely hard to contrive in other ways. Such alternative sources for the CMBR typically involve a local origin, in which starlight is thermalized by e.g. the intergalactic medium.
I had gathered that inflationary theory was employed to explain the uniformity due to horizon considerations; fluctuations contributing to the anisotropy would have had to be in contact. Without inflationary theory, it would/will be much harder to explain, at least on that basis.
I wasn't aware of a localized requirement for alternate explanations of the CMB, although many of the proponents in the early part of the last century employed them. I've heard in passing of the "whiskers and grains" afficionados, but don't know what to think of them. So the limitations of an alternate explanation would be: high density IGM so that it can be isotropic with an explanation of how it can avoid absorbing extragalactic signals, or low density IGM and a very old universe and an explanation of what would thermalize radiation independently of distance.
Such theories also tend to neglect the Sunyaev-Zel'dovich effect
One thing I found particularly odd about the effect was its independence from redshift. From an alternate standpoint, I would ask why it could not be considered a constant effect on a constant temperature of background radiation.
(On a side note: I must thank you for giving me some very interesting topics to look up. Here's one link for the S-Z effect for those watching the conversation not in the know.:)
Third, inflation does not give us an age of 13.7 Gyr for the Universe.
Fair enough.
From the WMAP data, NASA scientists precise estimate of 13.7 Gyr +/- 0.2 Gyr. It is said to discount certain models of inflationary theory, but appears to rely on it.
One gets an age of 13.7 Gyr if the Universe is flat, if its energy content is basically all matter, and if the Hubble constant is 50 km/s/Mpc.
The values from NASA give 4% visible matter, 23% dark matter, 73% dark energy, at a Hubble constant of between 68-75 km/s/Mpc, and indicate a flat universe.
If inflation turns out to be complete and utter crap, that does not say anything for or against the Big Bang model, since the Big Bang model does not have inflation as one of its components.
Perhaps not, but a lot has been invested in the inflationary path. It would look bad:)
And when it specifically comes to the acceleration of the expansion, that's been observationally detected, since 1997, by independent groups, and is one of the key pieces of evidence arguing for a nonzero vacuum energy density.
I can imagine how accelerating expansion could be deduced, but I've seen nothing (point me in the right direction?) to indicate that there are observations that would indicate acceleration independently of the current BBT models and equations.
I don't doubt that BBT is self-consistent, but for convincing "outsiders", stock must be taken of which observations whose interpretations shift depending on context, and which ones are more "static". If you've ever argued with a orthodoxie/fundie, you
I read a few days ago an article about figuring out how to bust apart the prions in BSE (mad cow) - but cannot for the life of me find the link. There's a similar disease in sheep, scrapie, which they've had some success using monoclonal antibodies to reduce the damage from.
That would be a next step in Alzheimer research - if we can bust apart the amyloid beta plaques in sufferers, we might not be able to get back all old function, but it would very likely help current sufferers. One we have the ounce of prevention - it would be nice to have the pound of cure, too.
I can appreciate that that took a few-hour chunk out of the middle of the day; you've given me a few things to track down.
There is a most excellent paper by Xinhe Ming and Peng Wang from August 31, 2003 that led to the decelerated-then-accelerating model that has raised my eyebrows so much located here.
The equations of state resemble (to me) the way computers use polynomials to approximate sines and other trigonometric functions (with less terms, mind you, but we already know the infinite polynomial sequences for sine). There are plenty of constants and terms to tweak, and a number of the equations are unstable (which reminds me a little of the limited polynomial sequences - taking sin(100*pi) with direct substitution would give the wrong value, but here it gives more the effect of tweaking a polynomial to fit an observed curve).
In summary, adding a R^-1 or the like terms to the Einstein-Hilbert action is an interesting idea, which may originate from some String/M-theory, and looks like a possible candidate for the explanation of recent cosmic expansion acceleration fact
For all I know, they could be right. I'll admit my current prejudice, though. It has the feel of tweakery, though, for BBT to have that much "play" in it. Equations aside, much of the current consternation appears to come from "tests of reasonability", (which are being stretched by observations) such as "galaxy string X couldn't have formed Y years after photon decoupling".
I don't think the theorists were trying to solve the age problem back in the day; the announcements in Omni were simply along the lines of "the universe is 10 billion years old". The cosmological constant was rejected as a 'hack' by Einstein himself - it was originally introduced as a term to keep a static universe from collapsing due to gravity; it was set to zero in early BBT. *laugh* I wouldn't ascribe nobility to the difficulty of accepting a nonzero cosmological constant in the face of observation; that's like asking software folks to refactor - it's grudgingly, not heroically, done, even though folks are happy about the results in retrospect:)
*laugh* Sorry, didn't mean to get on a rant here - thank you for a well-crafted response, Bootsy; I'm looking forward to more!
Slashdot Mirror
That looks excellent, unwesen :) I'm impressed with the drive to modularity and working with multiple output, and kcachegrind looks just plain purdy :) It's nice to see profilers moving towards instrumenting behind the scenes at profile time, requiring no more from a user other than turning on standard debug information.
Thanks for the pointer!
(*laugh* Reading valgrind's documentation, I get a chuckle about having extra instrumentation specified with a "--skin" parameter)
There is a thery that there is little or no dark matter, and the difference is accounted for by the assumption that the inverse square law for gravity fails at large distances
I've read one paper that posits that very thing - this particular one is from amongst the push-gravity theorists, and basically states that the graviton "shadows", like light, can slowly fall off at faster than inverse-square due to interference with matter.
There are other possibilities, of course, including intergalactic space containing much more in the way of hydrogen molecules (from which it's difficult to get an absorption, never mind an emission, spectrum at such low temperatures, unlike hydrogen ions... well, protons :) than we would have suspected, or there's always the field of plasma cosmology, that puts a at least as much emphasis on currents as on gravity, and also provides for a non-black-hole-dependent theory for why galactic jets form.
After years of developing, I really take to heart two things:
Profilers are the best thing to happen to performance since compilers - really. I encounter a number of truths, but many myths about what degrades performance. A few examples of each:
Performance degraders
Not performance degraders
The "lots of object indirection" myth is one I encounter frequently. Object A calls Object B calls Object C, and it "intuitively" looks like it must be slow (Computer A calling Computer B, etc. would be slow), but even with stack frame generation, these are lightning fast compared with even the likes of "date to string" functions, never mind line-drawing commands or notification-sending.
The reason that particular myth is dangerous is that it's the single most pervasive myth (IMHO) that leads to premature optimization. People take out layers of object indirection and make it harder to put in better solutions later. I had an object that recorded object IDs in a list and let you look them up later. If I had "flattened" that into the routine that needed it, I might have effected a 0.1% speed increase (typical range for many premature optimizations). As it stood, because it hid behind an interface (equivalent to an ABC for C++ folks), when I had finally implemented a unit-tested red/black tree, it was trivial (~5 minutes) to drop in the new functionality. That's not an isolated case, either.
Mind you, I profiled the program to determine the slowdown first. Searching on the list, because so many were misses (therefore full scans), the search was taking up 98.6% of the entire operation. Switching to the red/black tree dropped the search down to 2.1%.
All in all, if you have a slow program, profile it. There is no substitute for a well-written profiler. Stepping through and "feeling" how long it takes in a debugger, while it can point you in rough directions, will miss those things that take 50 ms out of the middle of each call to the operation you're checking. Manually inserting timing calls can be frustrating enough to maintain or slow down your program enough that you can't narrow down the performance hit.
gprof works well with gcc and its relatives (make sure to add -pg to your flags), but I'm not sure if there's a good open source option out there for people using other tools that doesn't require you to alter your source.
In the Windows world, we recently got in the professional version of AQTime 3. It's an astounding package, allowing you numerous reports, pie charts and call graphs, saving the last few runs, calculating differences in performance between runs, allowing attachment to running processes, on top of a pretty nice way to define areas of the program to profile. The single nicest thing about it, though, is the performance. We turned on full profiling (that is, profiling all methods in all modules, including all class library and third party components) on the largest project we had, and it ran with perhaps a 30% slowdown. If you've used profilers before, you know how astounding that is ;)
Profiling applications always surprises me. In one case, a space-making algorithm I was running on controls seemed a little pokey; I found out more than 50% of the time spent was on constantly verifying that the lists were sorted. Today, I was investigating a dialog that looked like it must hav
If you're working in Java, you should add assertions to your toolkit.
Amen to that; that goes for any number of development environments that have assertions or pre/postconditions as an available construct.
I use assertions anywhere that a violation of the condition would be a programming error, instead of a configuration or input error. Pass in null into the constructor? No! Pass in a negative number for the distance? No! Use this resource object after return_to_pool() has been called on it? Nuh uh!
Just having assertions be a gatekeeper for "impossible" circumstances catches a lot of those very selfsame "impossibilities".
I do a lot of concurrent programming these days, so the rules count triple. It's almost always something stupid, too, like using the ID of a constant instead of the value of the constant (in COM programming, varNull instead of Null), or forgetting to declare support for an interface. Adding assertions to other peoples' code can really track down anomalies pretty fast - someone's red/black tree algorithm had some cases where the root object (which should have no parent) got assigned, causing all sorts of subtle mayhem.
Along with this, I would highly recommend unit testing - highly. Based on the number of failed unit tests I've had over the past year, some twenty very subtle bugs would be haunting me still. Now, at least to a much higher degree than otherwise possible, I can "prove" that my objects and algorithms work, at least as advertised.
Unit tests also really help out when swapping out algorithms. I swapped a list for a much faster red/black tree (was doing thousands of ID lookups). Two unit tests failed - and both had to do with what happens if your object ID matches a blank ID. Easy to fix, but I wouldn't have had a clue.
Unit test also help out when porting. I have a fairly hefty framework in Delphi. Porting that to .NET took about a week to get working - a few days for the syntax changes, a couple extra to get green lights on the unit tests again.
Unit tests are, unfortunately, one of those things that you can agree with in principle, but figuring out how to do useful ones that don't seem like makework takes a leap. A small leap in retrospect, but a leap that can be hard to find nonetheless. Techniques for cutting down repetition, emphasis on negative unit tests (i.e. equally important to explicitly state that you can't do X), creating mock objects that record actions to compare against expectations, all are techniques that are a little hard to extrapolate from simple examples.
Assertions and unit testing might not be "debugging tools" in and of themselves, but they certainly help prevent bugs from slipping in unnoticed.
Saying "mass warps spacetime" doesn't explain how it pulls that stunt anymore than answering who was pushing Kepler's brooms.
Have always been curious about that myself. After all, the usual analogy made is that of a rubber sheet, in order to reduce the dimensions... but the analogy requires gravity in order to work. The sole thing you gain by such an analogy is reducing gravity from something radial (in towards an object) to something linear ("down" through space).
...but why should there be a stream of... somethings... going from 'top' to 'bottom' in the fourth physical dimension... interacting with our cosmos?
I've heard some folks posit that gravity is 'resistance' of matter to whatever medium space is expanding "into" - space has much less resistance to it, and so you get little funnels from the difference. Mind you, that does rely on a 'closed' universe, and I don't think that's the one in favor in the presses at the moment :)
Personally, I'm most curious about the LeSage-type particle gravity theories - the "push" theories instead of the "pull". I've read a number of variations on the theme and all of them have some testable portion, whether it be gravity fall-off, shielding anomalies, precessions, thermalization of gravitons absorbed (causing planetary heating above any caused by radioactive breakdown), upper bounds of density (there would come a density point where ~100% graviton absorption happens - which would put a limit on compression by gravity)
I find the 'frame dragging' concept a little odd when applied to a framework that looks, for all intentions, as though it's geometric - spacetime bending, sure; spacetime twisting - ? Having spacetime be continuous, or even discrete-but-completely-connected, would imply somewhat that the 'twisting' of frame dragging should be resisted somehow. The only easy way out of the conundrum is to posit spacetime being particulate - water and air have no problem forming vortices when spun. So, is spacetime particulate?
The most annoying thing is that you really can get to the same formulae multiple ways, and often we get stuck with the first analogy that "explains" things until we start figuring out the edge cases. Case in point, it took a long time to turn Plato's optics around (although, to be fair, the theory of emitting rays from your eyes works really well for raytracing :)
Looking forward to hearing of the results of this. It would be pretty bizarre not to find frame-dragging at this point :)
...but not as bizarre as finding Kepler's Brooms :)
*laugh* I don't deny the worm's trivial requirements relative to ours, but rather, that our brain size and mass seems disproportionately large. Move up the tree a bit and take a look at bird brains - a lot going on in there, vocals, goal-seeking, social dynamics...
My main thought was sheer awe at the amount of extra space required for human-style intelligence, especially in the prefrontal cortex. We should be able to hold more than 5-9 things in our heads at once with all that ;)
Well, in the case of blind people, the visual system of their brain is taken over by their auditory system.
I'd read that as well, although I'd like to know whether it's mostly a feature of blind-from-birth folks, or whether the recently-blinded can eventually end up with full visual cortex reuse.
One of the impressions I have from reading is that the olfactory, auditory and visual systems are near-clones of one another, right down to the triple layers (visual system has two sets) and generated contour maps (even smells make a "picture", although "pictures" of the same smell apparently drift from day to day).
What that might indicate is that the function of many parts of the visual and auditory systems isn't "pre-determined" per se, but comes from what they grow to be hooked up to, which is typically from the appropriate sense organ.
Interesting :)
It's not too surprising that the brain's short-term visual cache would be closer to the visual cortex. What I would like to know is how closely the visual cache is related to intelligence. Does it need actual visual input, instead of just imagined, and if so... <facetious>do you become marginally dumber when you close your eyes?</facetious>
From reading Synaptic Self, the "general" cache and CPU area would seem to be the prefrontal cortex. It can activate memories to work on (the closer the current emotional state it was recorded in, the better), and hold a few things to work on. Perhaps there are many more specializations yet to be uncovered, but I'm struck at the sheer relative size of brain required to actively think and plan a next move. Considering that even a worm brain can get its owner around, you'd think our capacity for juggling thoughts would be encyclopaedic.
I'd be curious as to what connections this area has to the prefrontal cortex - I've heard of the spots tests before - I don't recall it being related to general intelligence.
Addressing the question of how cache gets spat out to hard drive, as it were, to keep thoughts in slightly longer-term storage, it looks like thoughts have to be put through the hippocampus and entorhinal cortex, where they will slowly get rewired (indexed?) over the course of about two weeks - about the length of memories you can lose under strong electroshock therapy.
So many small functional pieces of the brain; I'm struck by how independent the sections of the brain are, by and large. Large-scale coordination has to go through a secondary 'chemical drip' system, from neuromodulators released by non-connecting nerves throughout the brain. It's that level of coordination required to put your brain to sleep or wake it up, amongst other things.
I'm looking forward to more decoding of the brain's structures - narrowing down specific activities to a small area of the brain like they did is fantastic.
I couldn't get your link to work, even with revisions, but the view from around Saturn's satellites is just gorgeous.
Perhaps it's not the sole job of future probes to get us better textures for Celestia, but it'll be a nice side-effect :)
For those without Celestia - do yourself a favor and download it! It's one of the best-feeling 'space exploration' simulators I've encountered, and you can't beat the price ;)
Now, all we need is this as the base engine for Elite III: More Stars Than You Can Shake A Pretty Good Stick At.
No, but bright people have created some of the most awful rotten code I've ever maintained.
There are a number of reasons why seemingly bright people write latrine-awful code:
Avoided maintenance
Doing a lot of new development and never having to support/maintain it produces a significantly different impression of one's own coding than having to stay the course and add features into whatever minefield one has created.
It wasn't their hobby
Hobbyists bring a lot of enthusiasm, and often start relatively young, giving them a lot of exploratory experience, and often a passion for the craft.
Despite best intentions, it's simply harder to feel the same zeal for self-improvement or qualtify of workmanship when one has gone to school/college/university in order to learn programming "to get a job". All analogies between musicians and programmers in this vein apply :)
First time out of the blocks
Especially out of shorter courses, the survey given of technology and techniques can be relatively scattered, with a lot of focus on the technologies available, and much less, if anything, on how to do projects, testing, or design. OOP principles can help, but like principles of technical writing, they can only give you the guidelines, not the creative content.
Biting off more than they can chew
Some bright people will be positively filled with bright ideas and "wouldn't it be cool if...", and can put themselves on paths to the right functionality, but that require algorithms they don't have the foggiest about, or techniques they have little practice in, and they can get stuck trying to fill in the gaps.
If you doubt this is possible, ask someone with a starting set of skills whether they'd like to make a game, and how possible they think it is :)
In slightly larger projects, this can also manifest itself as an inability to delegate - which can start being problematic if team members are waiting on something to start with.
Distractable
Vis-a-vis your comment about professional development being boring, distractability is a common side-effect in bright folks who just want to play, and not get bogged down in the nose-to-the-grindstone details.
These are the folks who think of something cool, then spend two months trying to get a feature that isn't core, wasn't asked for, etc. to a working state. This can overlap with the next problem...
Procrastination
Whether it's the thrill of deadlines zooming by, poor vision by project managers, team leads or management, or just suddenly realizing that people are serious about wanting that program done by three weeks today, some code is written badly because it's written fast and at the last second.
Gizmophilia
Some code isn't so much bad as it is confusing, laden with whatever behaviors, syntax or components are out near the edge of what's defined in the class library and language syntax.
Whether it be quadruple-nested ternary operators, naming variables for appropriate characters from a favorite videogame, mixing in excessive amounts of system calls to 47 hard-to-install third-party libraries or trying to overload binary negation for strings to mean "how long is the string", these programs can work, or start out working, but the code is often not human-readable, or is hard to set up and build in another dev environment.
Poor debugging skills
Sometimes, programs start out readable, but then the code runs into a problem. Debugging skills and coding skills don't always live in the same person, and the desperate coder, wondering why something isn't getting called, or is refreshing in the wrong order, doesn't and can't properly trace what's happening, and so starts to add in duplicate calls, strange exit strategies, state variables all over the place. The wiring can start to cross really qu
I'm glad to see some DRM-free alternatives, especially for the purposes of buying music and playing it on a Linux box.
I asked the question in #linux on FreeNode a while back as to where I could go buy and download legitimate music through Linux, without owning an iPod (or using the DRM "crack"), or needing Windows Media Player 7.1 (or 9.0) on a Windows machine, or having to burn to CD under one OS so that I could have it on Linux. Not much in the way of answers, and one heart-felt "if it's only one track, you're just as well to use P2P". I'd still rather buy it if I could - I like some songs and can afford them - I'm not out for a free lunch.
For commodities like this, I want a no-nonsense license. I'd like e-music vendors to say,
"Buy it, listen to it, throw it on your machine at work, put it into a compilation for your significant other - anything reasonable you'd do with a live CD in your mitts. We trust you that far, we know that by coming here, you're not likely to be a P2P weenie with an entitlement attitude. We figure you'll be happy with your music, and come back and buy more and tell your friends. We're working on some forums and rating/comment systems to help you sort through the overwhelming amount of music to find what you'll probably like a lot faster. And thanks."
This, MagnaTunes and a few others, even if the selection may not be that great for someone with some mainstream or retro music tastes, is a good step in that direction.
It feels pretty strange in this connected day and age not to be able to track down music I'd like in record time. It's certainly not the lack of willingness to purchase :)
I think that Close is called in the destructor anyways, but the destruction is called when the garbage collector clears the object. And you don't known when this will happen.
I took a look at the reference material for the .NET framework, and apparently Finalize is declared, so you can actually let it go out of scope and have it close for you. That seems to actually be by and large how .NET classes that wrap around external resources work.
So, you can keep your code as simple as you used to. No __finally required.
You do incur the finalizer overhead if you leave .NET to do the finalization for you, so if you for some reason need to make sure the file stream close is efficient and doesn't make the GC hiccup (e.g. if you had a lot of threads doing many file stream opens/closes), you'd use the much uglier, but more "efficient" syntax:
finally is just a declarator for a section of code that runs whether you get an exception or not. I use them all the time for things like critical sections and constructs like setting "currently_updating" variables back to false no matter what goes wrong in a method.
But think about a case were you forget to implement the _finaly block. You write to the file and later you want to delete it (eg. because it is a temporary file). This delete works if the GC has finlaized the Stream, but fail sometimes when the GC has not yet finalized the Stream. I think this mistake is harder to find than the forgotten delete.
If they had forgotten to add in a Finalize, that's exactly what would happen. However, they did, so no worries :)
If you come across a class you're wondering about, take a look in the .NET documentation for the class, look under members, and see whether Finalize is in the "Protected Methods" section - if it is, you don't have to worry about their use. If you see Dispose in there, you can use the ugly Dispose syntax to get rid of the object more nicely for the GC. (The first thing most calls to Dispose do is GC->SuppressFinalization(this), which removes the object from the complex finalization chain.)
Hope that helps :)
P.S. Doh! Does anyone know how I use <ECODE> tags in HTML Formatted posts and have /. maintain the spacing? Is it browser dependent?
<obligatory with-apologies="yes">
Bounder: Anyway, you're interested in one of our adventure holidays?
Tourist: Yes I saw your advert in the bolour supplement
Bounder: The what?
Tourist: The bolour supplement
Bounder: The colour supplement?
Tourist: Yes. I'm sorry, I can't say the letter 'B'
Bounder: C?
Tourist: Yes that's right. It's all due to a trauma I suffered when I was a sboolboy. I was attacked by a bat
Bounder: A cat?
Tourist: No, a bat
Bounder: Can you say the letter 'K'?
Tourist: Oh yes, Khaki, king, kettle, Kuwait, Keble Bollege Oxford
Bounder: Why don't you say the letter 'K' instead of the letter 'C'?
Tourist: What, you mean...spell bolour with a K?
Bounder: Yes
Tourist: Kolour. Oh that's very good, I never thought of that! What a silly bunt
</obligatory>
Garbage collection really does a number on disposal behavior; it's been driving me a little crazy as well.
There are, for performance/control reasons, four possible paths for getting rid of an object:
So, in your example, if you wanted to make it easier to deal with files and were willing to take the hit on the finalizer, you could do:
...and use FileStreamEx instead.
Might want to check, too, to make sure there isn't already something like that in the framework :)
For example, the braindamaged distinction between structs and classes as value and reference types respectively.
I, for one, am glad they put this distinction in. The difference in treatment between the two can have some profound effects on the way allocation, array handling, and memory footprint operate.
With an array of objects, you get an array of references (checked pointers) to the objects, requiring an allocation per object (the size of the allocation depending on the particular derivative) and indirection to access the pieces.
With an array of value types, the size can be predetermined (in much the same way stack-based object variables were in C++) and the items therein laid out end to end, giving a single block allocation and no extra reference per item required.
Some of these pieces are especially important because of the Managed Code model - you can't lay out a stretch of bytes and cast it directly back and forth to an object type. Having tricks like this that can let you keep your performance and still declare the code provably 'safe' is invaluable.
I've been playing with C# and Delphi-for-.NET, and ported one of my frameworks across. It's been an interesting experience - I was expecting something insubstantial when I first heard about the initiative, but now that I know Anders H. was behind much of it, its low disagreeability factor is well-explained :)
Operator overloading, automatic boxing and unboxing of primitive types, and properties come to mind. The first two, AFAIK, will be in Java soon,
I attended a seminar on the Java 1.5 extensions being introduced, and they were: generics, autoboxing/unboxing, varargs (for lack of a better term :), improved and generic-aware for syntax and enumerations. Interestingly, generics made a strong case for a number of the other features, especially boxing (we were treated to "before-and-after" syntax possibilities for each feature). Looks interesting.
and properties are just syntactic sugar to replace observer methods.
You're thinking of delegates, and in a way they're syntactic sugar on observer methods, but besides cutting out a lot of need for anonymous or named action observer classes, they implement some of the Active Object pattern with BeginInvoke, which will asynchronously delegate something until EndInvoke is called. Very useful with remoting calls.
Properties on the other hand are syntactic sugar. Goobery syntactic sugar over the myField()/setMyField() set. I do make a lot of use of them in Delphi, and all they do is basically tie the getter and setter together in an explicit way instead of relying on convention. The main beneficiary of this is the IDE/inspection tools, which can query reflection/RTTI to find out what to display and how to hook up a property update. JavaBeans was in part based on Borland's experience here (I was quite shocked looking at the docco for the JavaBeans and seeing things with names right out of DsgnIntf.pas :) - I believe they ended up relying on naming conventions for Java's purposes.
The real reason it's being pulled... :)
<tinfoil>
March 9, 2004
The ACS uncovered galaxies that existed 800 million years after the big bang (at a redshift of 7). But the NICMOS may have spotted galaxies that lived just 400 million years after the birth of the cosmos (at a redshift of 12). Thompson must confirm the NICMOS discovery with follow-up research.
July 21, 2004
Hubble's NICMOS may have just spotted galaxies that lived a mere 150 million years after the birth of the cosmos. "We should be seeing something less-defined by now," said Carrot Top's* father, "This would seem to indicate that galaxies form faster than we ever thought possible." Research scientists reacted to the news, "This is the strongest evidence yet for the presence of supersymmetric photino strings," said Ablebaker Charlie of Berkeley, "finally, we have a solid lead on the dark matter that guided galaxy formation in the early universe".
November 10, 2004
LATE BREAKING NEWS: Hubble's new IFDEF camera has picked up the oldest galaxies yet on record. If confirmed, these galaxies would be an astonishing 14.1 billion years old, approximately 400 million years before the creation of the universe. When the news was broken today, theoreticians and science publishers were quick to stat&]/@^@CCC!0__NO CARRIER
</tinfoil> :)
* He's the son of a NASA scientist; go figure :)
Unit testing does not require eXtreme Programming. On the other hand, eXtreme programming does require unit testing. We've studied XP's practices, and they seem to be roughly broken into two groups: programming for ever-changing requirements, and quality assurances (refactoring, unit testing) to make sure the code doesn't fall apart.
As many anti-XP pundits will point out, unit testing is worth applying to any project that you can apply it to, and there are precious few that can't.
I do a lot of framework-level programming, and I must say that stability, as well as my confidence in the code, has increased substantially from putting unit testing into the mix. Some folks advocate TDD (Test-Driven Development) in the canonical sense (test first), but I find that the completely up-front test creation works in practice only when you have rock-solid easy-to-translate-into-source-code checklisted requirements. I compromise, and build the tests after the interfaces, rough algorithm and rough support objects have been put together.
Here are a few things I've learned over my unit testing experiences:
I haven't figured out a good means to unit test concurrent code, but you can often stack the deck for fast-running processes by adding in delays in key spots to extend the exposure to weak spots.
Unit testing isn't for everything. It coughs and sputters a bit when you don't have full control over the environment (databases, sockets, network configuration, user interaction). You can shoehorn it in, but it's usually better left for the likes of regression testing and functional integrated testing.
For a quick start to functional testing, we've started test-driving TestComplete at our office; it's proven itself to be a capable tool (our lead QA man has put up a sign on the computer entitled, "I am Q-Tron; I Test Software While Mere Mortals Sleep" - it has been testing out communications while he sleeps :)
Now that I've got my machine back up and running with a full fresh install of Fedora (too much fighting trying to upgrade from RH7.3 the source code way - yikes :), I am back to running my background SETI@Home and Folding@Home.
I've compiled the 2.4 Kernel targetting Athlon before, and it made a significant difference in speed to those relatively intensive tasks. I informally benchmarked it simply by noting how fast ./xsetiathome performed when you ran it with a custom kernel versus the i386 kernel (at the time, having to run NVidia's driver setup each time - just wasn't as happy linking against the custom kernel). Custom kernels, even ones where all you do is tell it which processor to -march against, are fast, and you can tell.
I think I'll be back to recompiling my own kernel so I can get me some speed again :)
Any brave souls tried to get the 2.6 kernel compiled and running under Fedora Core 1?
There sure were a lot of drumbeats in the pilot episodes, although we caught strains of it during the ceremony.
I surmise that they may get their own music once the go-ahead is on. It might take a little while to get some decent music unless they prepare well in advance; Stargate hobbled along with snippets of the original movie's music in a not-quite-audio-balanced form for a while until they managed to work in new arrangements more suited to a TV series :)
What if gravity doesn't quite work this way at galactic scales?
I remember reading through Pushing Gravity; one of the papers in it posited that gravity does weaken faster than r^-2 at larger distances. One of the by-products is that the outer edges of galaxies need less mass to keep their shape.
The details were more interesting than that - I'll have to dig the book out of hiding.
I remember the scores of Chicken Littles that came out of the woodwork when Anders got 'fished' from Borland. Regardless, under the hands of Chuck J and others, it still went along swimmingly.
It's actually pretty interesting the ties between some parts of Borland and Microsoft's .NET team. (I was at BorCon a couple of years back when Anders did a keynote speech, and did demonstrations of ASP.NET... using Delphi 7's .NET Preview Compiler to very good effect.) They've had to face a number of the same challenges. .NET actually has to approach the Windows API in the same manner as many decent class libraries have (glad to see that the .NET framework is miles away from the spaghetti vomitus of MFC, likely in part an Anders influence). Borland had to work around the idiosyncracies of the Windows rich-text APIs in making their TRichText control. Such experiences are valuable. In return, Borland gets some excellent heads-ups on the technology.
I've had a chance to use Delphi 8/for .NET, and I must say that Danny Thorpe, Corbin Dunn et al have done a marvellous job in making porting to .NET easy. Compared to porting to Kylix/CLX (which 'everyone wanted', but nobody would pay for - *laugh*), porting to .NET was a breeze. I even ported DUnit across while I was at it :)
As to missing generics, I, too, missed some sort of generics. I loved Ada's model for generics, loathed the way most C++ compilers handled templates (more specifically at the time, how they handled errors and tracing :), although I got good mileage out of them.
I have an implementation of Rossen Assenov's generics for Delphi (using a trick similar to that in C++ before the 2.1 standard) here on my web page. A few limitations (which you can get around if you're not averse to 2-layer-deep includes :), but works like an absolute charm, and it does still work in Delphi for .NET (though you will have to ensure you aren't using pointers in your list classes if you want to be managed-code compliant :).
I'm a relative Linux newbie, but I've managed to build the Linux kernel before, managed to sort out various and sundry RPM dragon-eating-its-own-tail dependencies. *laugh* I didn't know what I was in for when I tried to build KDE3.2 on an ol' Red Hat 7.3 desktop.
Those in the know can imagine how many packages I needed to upgrade :) Probably on the order of 45, all told, and I think I was getting off lightly. zlib, freetype, fontconfig, libart, the gnu utilities, etc. etc. etc. Even that was fine :)
Not wanting to screw up the source code installation, I pulled down a copy of Konstruct to have it download and appropriately build things. I RTFM'd, I set it up, and watched it for the first little while. It was merrily getting files, so I went off to work.
When I came back home, all was not well. It couldn't find qInitImages_designercore(void) in the Qt 3.2 designer compilation. I couldn't resolve that one, even after I figured out the odd directory configuration (and it is odd - trying to locate the source for things libtools was running on). libdesignercore.a (I think that was the file) had the identifier in it, and Google didn't help me out. So I'll avoid the designer for now - I just want to get this compiled! So, out comes the // comment gun and bye bye to the extern reference in the two problem files.
Onward the compile went, just dandy (while I lazily web browsed and mahjongg'd in the background), and then spew out comes a list of errors in the (IIRC) librtld compile and screech goes the compilation. Ages of Googling later (how on earth would I do this without Google?!) I find out that Konstruct will inappropriately build the config.h file in that particular circumstance. My autoconf package had not been the right version for this, so off I upgrade again.
I got a clue from the discussion that it was the config.h and config.h.in that were problematic, so I look into trying to auto-configure things on my ownsome. Reading the man pages for autoheader, it seemed the right man for the job, so I autoheadered the kdetools directory, autoconf and ./configure (it takes a little longer than last time, so I think it's making progress :), then make clean && make. Doesn't make it five seconds before encountering "unparseable tokens" in the config.h file (which looks just utterly fine, on visual inspection).
I then came across something on the 'Net which claimed that automake Makefile.cvs was something which could cure cancer, stop SCO in its tracks, and help people out of makefile conundrums. Off I upgrade again :) - the Makefile.cvs won't have anything to do with my current automake.
(It is nice that Linux is pretty good about facilities to make sure that you can be warned about obsolete versions, but I'm startled at how quickly libraries and programs are deprecated.)
automake, true to its word, runs through and sorts out the mess. Takes a goodly long while to recompile things (I was most of the way through kdetools when the error happened in the first place), but I'm happy to be off and running!
Some time else in the middle of all this was another configuration error, complaining that KDE couldn't continue compiling because my 'current version of aRts was too old'. Given that aRts is included in the distribution, that seemed pretty weird, GnoRPM and I resolved just fine. What a truckload of avoidable warnings, though - g++ was having a hissyfit! I thought errors in template files in VisualAge/C++ were mysterious and threatening, but <yoda>no candle to this did they hold</yoda>.
Hours later, it coughs up its lungs again. What's it this time? A g++ internal floating point error (147). Aaaaaaaaaaaaaa! (I was sensible enough not to pull out my own hair
No prediction of the cosmic microwave background's blackbody temperature prior to the CMBR's discovery was ever thought very likely correct
Predictions were made, though, from Steffan-Boltzmann laws, of blackbody cosmic background radiation in an infinite/static universe configuration by Guillaume in 1896 (5-6K), Eddington in 1926 (3.18K), Regener (2.8K) and Nernst (0.75K on a tired light model).
It is the mere existence of the microwave background -- its omnidirectional uniformity and amazing blackbody spectrum -- that is the prediction of interest. And contrary to assertions from people, these are extremely hard to contrive in other ways. Such alternative sources for the CMBR typically involve a local origin, in which starlight is thermalized by e.g. the intergalactic medium.
I had gathered that inflationary theory was employed to explain the uniformity due to horizon considerations; fluctuations contributing to the anisotropy would have had to be in contact. Without inflationary theory, it would/will be much harder to explain, at least on that basis.
I wasn't aware of a localized requirement for alternate explanations of the CMB, although many of the proponents in the early part of the last century employed them. I've heard in passing of the "whiskers and grains" afficionados, but don't know what to think of them. So the limitations of an alternate explanation would be: high density IGM so that it can be isotropic with an explanation of how it can avoid absorbing extragalactic signals, or low density IGM and a very old universe and an explanation of what would thermalize radiation independently of distance.
Such theories also tend to neglect the Sunyaev-Zel'dovich effect
One thing I found particularly odd about the effect was its independence from redshift. From an alternate standpoint, I would ask why it could not be considered a constant effect on a constant temperature of background radiation.
(On a side note: I must thank you for giving me some very interesting topics to look up. Here's one link for the S-Z effect for those watching the conversation not in the know. :)
Third, inflation does not give us an age of 13.7 Gyr for the Universe.
Fair enough.
From the WMAP data, NASA scientists precise estimate of 13.7 Gyr +/- 0.2 Gyr. It is said to discount certain models of inflationary theory, but appears to rely on it.
One gets an age of 13.7 Gyr if the Universe is flat, if its energy content is basically all matter, and if the Hubble constant is 50 km/s/Mpc.
The values from NASA give 4% visible matter, 23% dark matter, 73% dark energy, at a Hubble constant of between 68-75 km/s/Mpc, and indicate a flat universe.
If inflation turns out to be complete and utter crap, that does not say anything for or against the Big Bang model, since the Big Bang model does not have inflation as one of its components.
Perhaps not, but a lot has been invested in the inflationary path. It would look bad :)
And when it specifically comes to the acceleration of the expansion, that's been observationally detected, since 1997, by independent groups, and is one of the key pieces of evidence arguing for a nonzero vacuum energy density.
I can imagine how accelerating expansion could be deduced, but I've seen nothing (point me in the right direction?) to indicate that there are observations that would indicate acceleration independently of the current BBT models and equations.
I don't doubt that BBT is self-consistent, but for convincing "outsiders", stock must be taken of which observations whose interpretations shift depending on context, and which ones are more "static". If you've ever argued with a orthodoxie/fundie, you
I read a few days ago an article about figuring out how to bust apart the prions in BSE (mad cow) - but cannot for the life of me find the link. There's a similar disease in sheep, scrapie, which they've had some success using monoclonal antibodies to reduce the damage from.
That would be a next step in Alzheimer research - if we can bust apart the amyloid beta plaques in sufferers, we might not be able to get back all old function, but it would very likely help current sufferers. One we have the ounce of prevention - it would be nice to have the pound of cure, too.
I can appreciate that that took a few-hour chunk out of the middle of the day; you've given me a few things to track down.
There is a most excellent paper by Xinhe Ming and Peng Wang from August 31, 2003 that led to the decelerated-then-accelerating model that has raised my eyebrows so much located here.
The equations of state resemble (to me) the way computers use polynomials to approximate sines and other trigonometric functions (with less terms, mind you, but we already know the infinite polynomial sequences for sine). There are plenty of constants and terms to tweak, and a number of the equations are unstable (which reminds me a little of the limited polynomial sequences - taking sin(100*pi) with direct substitution would give the wrong value, but here it gives more the effect of tweaking a polynomial to fit an observed curve).
In summary, adding a R^-1 or the like terms to the Einstein-Hilbert action is an interesting idea, which may originate from some String/M-theory, and looks like a possible candidate for the explanation of recent cosmic expansion acceleration fact
For all I know, they could be right. I'll admit my current prejudice, though. It has the feel of tweakery, though, for BBT to have that much "play" in it. Equations aside, much of the current consternation appears to come from "tests of reasonability", (which are being stretched by observations) such as "galaxy string X couldn't have formed Y years after photon decoupling".
I don't think the theorists were trying to solve the age problem back in the day; the announcements in Omni were simply along the lines of "the universe is 10 billion years old". The cosmological constant was rejected as a 'hack' by Einstein himself - it was originally introduced as a term to keep a static universe from collapsing due to gravity; it was set to zero in early BBT. *laugh* I wouldn't ascribe nobility to the difficulty of accepting a nonzero cosmological constant in the face of observation; that's like asking software folks to refactor - it's grudgingly, not heroically, done, even though folks are happy about the results in retrospect :)
*laugh* Sorry, didn't mean to get on a rant here - thank you for a well-crafted response, Bootsy; I'm looking forward to more!