Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: 27 Years! (Score 1) 498

by WalterBright (#34672144) Attached to: What's the Oldest File You Can Restore?
Back in 1980 or so, I bought a Heathkit H11 which was a repackaged PDP-11. It had dual 8" floppy drives. I wanted it to implement my Empire game on it, which I did, and distributed a few copies of the binary. When I later got an IBM PC with 5.25" drives, I backed up the Empire source files from the H11 by writing them out to a serial port, and using a program I wrote for the PC that read from the serial port and wrote to a floppy. So far, so good. Eventually, I put all the PDP-11 version of the source code up on my website This year, a person who had a PDP-11 emulator tried to recompile Empire from those sources, and discovered one of the files was missing! Arggh. I had long ago copied all my 5.25 floppies to CD-ROMs, but the file wasn't there, either. I had obviously overlooked backing that one up when transferring the files to the PC. I had thrown out all my paper listings, and just had some handwritten code on notepaper (I use to write code that way, later typing it in). I gave away my H11 in the 80's, but the person I gave it to had thrown it in the trash (too bad, they are valuable collector's items now). But I did have the old 8" floppies. If only I could read them, and if only they were even readable after 27 years. I emailed my old friend from college, Shal Farley, who now runs Cheshire Engineering. He said he had an old 11 in the back room, it had an 8" drive and an ftp server on it, but he hadn't fired it up in years. I sent him the floppies, and wouldn't ya know, it worked perfectly and he imaged the floppies (about 8 of them). Every single byte read without error! I was amazed. He was kind enough to email me the contents, and I added it to the web site. I'm grateful to Shal for rescuing my data! When I backed up my 5.25" floppies to CD about 12 years ago, about 90% copied without errors. The ones before 1985 were nearly all thoroughly unreadable, though, which is why I figured the older 8" ones would be quite useless.

Comment: Re:Runtime design considerations (Score 1) 404

by WalterBright (#26961029) Attached to: Walter Bright Ports D To the Mac
Doing that would mean that, for example, all the #defines for constants in the C header file would have to be accessed via a C function. While this would make it much easier to port the D runtime library, it would have a significant deleterious effect on performance, as such could not be constant folded or optimized. This is unacceptable for a high performance systems language.

Comment: Re:Runtime design considerations (Score 1) 404

by WalterBright (#26960983) Attached to: Walter Bright Ports D To the Mac
D does not attempt to use FreeBSD header files on Linux. It does not use C header files at all. The point is, for each system, the C header files have to be translated to D import files. The C header files are different on each system, and so the D import files have to be different to match. If the D import files are correctly ported, the D user won't see any difference any more than the C user would. Any D program can use either read/write or stdio, as D has direct access to any C functions. The D I/O functions try to layer on top of stdio functions so that the programmer can mix and match using D and stdio as he pleases, including interfacing with C routines that use C stdio.

Comment: Re:Mac is UNIX on the desktop (Score 3, Informative) 404

by WalterBright (#26950557) Attached to: Walter Bright Ports D To the Mac
D does not use a text preprocessor. Often what is a standard C interface relies on macros in the standard C header files, which is perfectly standard C conforming. The D interface to the standard library has to look at those macro expansions, and write them as equivalent D declarations. Since the macro expansion text is not specified by the C standard, these all have to be gone through for each port of the D standard library. And yes, they do differ in sometimes dramatic ways. The interface to the D standard library needs to be portable, but that doesn't mean the implementation of that library needs to be portable. Some speedups in the D I/O library are possible, for example, by taking advantage of some linux specific api functions.

Chemist who falls in acid is absorbed in work.