Re: Good Dungeon Mapping e-Tool?

Kyle Wilson <kyle@xxxxxxxxxxxxx> wrote:
On Tue, 10 Jun 2008 19:52:13 GMT, Keith Davies
<keith.davies@xxxxxxxxxxxx> wrote:

Kyle Wilson <kyle@xxxxxxxxxxxxx> wrote:
On Mon, 09 Jun 2008 01:54:58 GMT, Keith Davies
<keith.davies@xxxxxxxxxxxx> wrote:

Done much with .NET?

Some, but not too terribly much. The software system at ONI is C++
based and still has some ugly legacy coding hangovers. The .NET stuff
looks really interesting in many ways. I'm not at all sure that the
garbage collection is a real win as you lose C++ destructors (although
managed C++ in the latest version seems to add something similar back,
at least for locals).

The loss of dtors in Java annoyed me no end. I've come to accept GC, but
I still prefer deterministic finalization.

Agree very much, but since I'm doing semi-embedded work with recursion
intervals in the 100 mSec to 200 mSec range, I'm still writing C++ and
really can't ever move to a GCol'ed language for the core of the MRI
scanner.

I do find it amusing that they've removed deterministic destructors
(C# and Java) to enable GCol (get rid of memory leaks that I haven't
run into terrible problems with) and in the process make it much
easier to leak file/mutex/other handles to the garbage collected heap
where they cause all sorts of troublesome side effects until they're
finalized... This in contrast to C++ objects where if done right, the
DTOR will take care of that detail (and if you mess it up, there is
one and only one place to go looking for the problem).

Yeah, that's the galling thing. Resource management isn't *hard* if you
know what you're doing. Memory is only one resource to be concerned
about. I'd much rather depend on my getting it right, and being able to
predict -- know -- when things will be cleaned up.

Using a GCed language, especially one that purports to be Object
Oriented, and having to explicitly close files annoys me. Quite a bit,
actually.

Hmmm...I haven't run into that yet in my career. So far, Microsoft
has kept supporting things long after their sell-by date (we're still
tied to DAO for Jet database access for historical reasons, but aside
from deprecation warnings, the DAO code keeps working).

You're lucky, then. There's a *lot* of code out there affected by this.
Though I suspect that anyone who *chose* to use VB deserves whatever
happens to them.

The strange thing is that there is no VB in our system. Just an
inappropriate use of VB related components. I'm not sure what the
original design team was thinking...

Just saying. A former client of mine got hosed by this pretty
seriously.

They even asked my advice on the matter *before* building the damn thing
(having it built). I suggested using a crap language controlled by a
single company was a potentially risky decision, but I couldn't say the
contractors couldn't make it work, so the client went with it.

And they're taking it in the shorts because now that they've got it more
or less working, they have to replace it.

That makes sense, but once you start using threading, multiple
processes,

Both of which I try to avoid within a single system, just so you know.

I live in world where threading isn't really avoidable. UI programs
get off easier on this front... I've also worked on and had off-line
interest in distributed networked systems...keeps the multiple
processes thing in the front of my mind.

Fair enough. Bear in mind, though, than any system that can be built
multi-threaded can be built single-threaded. It might be easier one way
or the other, though. Maybe I've just found threading poorly chosen and
implemented by people who didn't know enough.

Ok, I've been pretty much entirely on Win32 for the last ten years or
so. I know where most of the bodies are buried and where there be
dragons in NT lineage systems.

That helps. I've leaned more toward *nix for a long time.

My memories of the Unix side of things are blurrier, but I do recall
real issues with modularity in particular (signal handling being a big
one, if you had multiple modules loaded into a single process and more
than one needed SIGIO, you were pretty much screwed unless you build a
dispatcher yourself).

No comment, I didn't have to go there.

I think that this was mostly a result of the Posix APIs being defined
when pretty much everything (including the kernel) was statically
linked into a single image and generally written by one team. I
assume that much of this has changed in recent Linux given that ld.so
images are supported and I believe that there are lots of programs
that run over there that dynamically load and bind to modules written
by third parties.

I would think so, yes.

I think the old-style answer to this was 'fork-exec' the new code and
talk to it over a pipe or Unix domain socket.

Perhaps so. I've done shared memory work in Solaris for just this sort
of thing... some 12 years ago. It's been a while.

This is less of an issue for something like a map creation program
than for a networked servent or similar, but I suspect that it will
raise its head. Hmm...for runtime loading of components, I'm not
sure how Linux/Unix handles loading an ld.so on demand...

With no particular difficulty.

Ok, not suggesting you can't, just noting that I don't know how.

Yep. Just saying it's not hard *g*

I'd have to go look it up myself, I have a habit of either statically
binding everything (lazy bugger I am) or going with the 'normal' dynamic
loading and let the loader take care of it. I've dynamically loaded
stuff before and it was reasonably easy, but it's been a while.

I have also run into compiler issues in the past. I suspect that in
the present day these are less trouble as g++ sounds pretty solid
and Microsoft has mostly gotten over their aversion to standards.

That's a big help, that.

Indeed...I was supervised and very happy when the new C++ development
team (for VC 7.0) indicated that they didn't agree with the previous
folks and that they intended to fix the compatibility issues that VC
6.0 (and its many service packs) had propagated. They seem to have
doe the job too...VC 2003 is pretty close to the standard and I've
heard that VC 2008 even includes TR.1 stuff (I've got it around, but
haven't had any time to look at what it contains). I may even be able
to pull Boost out of our build tree at work.

<3 boost libraries. That's some damn useful stuff.

It has been quite a few years since I had any need to deal with multi
platform coding. Lately, I've been doing technical lead for
semi-embedded platforms that mostly run on XP (or real XPe).

I haven't been doing anything nearly so hardcore lately.

Thank you lucky stars then. It is pretty cool stuff, but the system
was written by physicists who could code (and they are about as good
at software engineering as the software engineers would be at MRI
physics...passable, but lacking deep understanding).

I remember porting FORTRAN code written by mathematicians to C.
This sounds rather much the same.

What do I do now? At work, not very much. Hired as a programmer
analyst eight months ago, I've built a couple of source decks provided
by the contractors and installed them. I've done a *lot* of business
analysis in that time, though.

I go *looking* for things to program at work, to save my sanity.


Keith
--
Keith Davies I married the moonshiner's daughter
keith.davies@xxxxxxxxxxxx How could I go wrong?
keith.davies@xxxxxxxxx The moonshiner's daughter
http://www.kjdavies.org/ Put some corn in the water
And makes me liquor all night long
-- Hayseed Dixie, _Moonshiner's Daughter_
.

Relevant Pages

  • Re: Ubuntu in Space
    ... I built ZX Spectrums in late 1980's, while in High School; however I have NOT designed 99% of it; in Russia we had these flea markets where people sold components stolen from work, blue collar folks mixed with highly educated upward to professors - all engaged in computer building. ... "Building" was mor einvolving than today - in those years you soldered motherboards from ZERO to a complete motherboard, and it had little to be complemented with - storage was a tape recorder thru OPamp-based comparator circuit, display was a TV thru RF modulated by RGB out of this motherboard, video was a joke built on that board, audio, etc; ... The entire purpose of ZX Spectrum faded away, I returned back to MK80 calculator which was a shameles copy of American Texas Instruments. ... I can see it's motherboard in my head at this very moment, with photographic memory, from 16 to 128KB memory versionbs. ...
    (microsoft.public.windows.vista.general)
  • Re: Conservation of Energy
    ... Nor does analog adders, integrators, etc. built from OP amps. ... Digital adders can be built from gates - no feedback paths, no memory ... have a massive combinatorial core with massive number of inputs, ... you could replace the ROM ...
    (comp.dsp)
  • Re: Ask EU
    ... Well, my own first computer was the Tangerine I built myself, initially with 1K of memory (including the half K that was the screen RAM - yes, you _could_ run software in the screen memory, as long as you didn't do enough carriage returns to cause a scroll!). ... But the first computer, as opposed to programmable calculator or similar, I used was BRENDA, the Barnardian Electronic Numerical Demonstration Apparatus; it was a computer by Mr. Parr's definition, which was that the sequence in which it obeyed instructions could be varied - i. e. ...
    (uk.media.radio.archers)
  • Re: + allow-proc-configgz-to-be-built-as-a-module.patch added to 
    ... allow /proc/config.gz to be built as a module ... Can you try to quantify "rather a lot of memory"? ... compiling kernel/configs.c isn't necessarily the same as the .config which was ... There had been need of rain for many days. ...
    (Linux-Kernel)
  • Re: sensors vs 2.6
    ... It does NOT work when i2c-dev, i2c-algo-bit and rest of sensors stuff ... are built INTO kernel. ... Loading other i2c modules before via modules ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)