Yeah, if you want that sort of stuff, then you have to read up on ActiveX, 
which is basically "COM with a UI."

Post a reply to this message

On 8/8/2011 14:46, Jim Henderson wrote:
> Now that one I haven't heard before....what's its origin?

CP/M, the proginator of MS-DOS.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Mon, 08 Aug 2011 15:00:46 -0700, Darren New wrote:

> On 8/8/2011 14:46, Jim Henderson wrote:
>> Now that one I haven't heard before....what's its origin?
> 
> CP/M, the proginator of MS-DOS.

Ah, that makes sense now.  If I'd had to guess, that would've been my 
guess. :)

Jim

Post a reply to this message

>    You are missing the point. You said:
>
>> OK, fair enough. However, I don't work with any file formats where such
>> trailing spaces would be significant.
>
>> I also don't work with any file formats which should ever contain a tab
>> character, so I've configured my editor to strip those too.
>
>    Which is contradictory with your earlier lamentation that you don't have
> any hex editor. (If you never work with any file formats where automatically
> stripping some characters breaks the file, what would you use a hex editor
> for?)

Sometimes I almost think you misunderstand me on purpose...

Binary files and text files aren't the same. Editing binary isn't the 
same as editing text. If I'm editing text, then I /want/ my editor to do 
helpful things like strip unnecessary spaces, convert tabs to spaces, 
and so on and so forth. If I'm editing binary [which currently I can't, 
but if I could...] I don't want anything to be changed unless I ask for it.

Post a reply to this message

> Incidentally, part of the point of DbC is that the pre/post/invariants
> are the actual important part. The rest is implementation details
> because you can change them around as long as you maintain the
> invariants. (Assuming, of course, that your invariants are complete.)

This doesn't work. (At least, not as implemented in Eiffel.) There will 
always be invariants which are in some sense "too hard" to express. (And 
even if there aren't, there will be some which are "too expensive" to 
verify.)

> Remember that DbC is a *design* technique, not a coding technique.

If that were true, then DbC would be /entirely/ orthogonal to the 
eventual implementation techniques.

> It's not so much whether it's a "class" or a "module", but rather
> whether there's well-defined places in your code where the invariants
> don't hold and well-defined places where they do.

This depends only on how well you structure your code.

>> It's not like turning the DVI file into PDF actually alters its
>> appearence in any way, shape or form.
>
> Sure it does. You stopped using metafont, for one thing.

Um, excuse me? MetaFont generates the typeface, which is then embedded 
in the PDF file. In what universe is that "not using MetaFont"?

Like I said, the visual appearance of the DVI and PDF versions are 
identical.

>>>> Has there ever /been/ a Unix that isn't distributed in source form?
>>>
>>> Of course.
>>
>> So... how would you compile it? I thought the entire reason Unix was so
>> popular is that it operates on arbitrary architectures.
>
> How would I compile what? Unix? Why would I compile Unix that works, any
> more than I'd compile Windows? Of course *somebody* has the source. Just
> not the end users.

Windows runs on 3 platforms. Unix runs on infinity. Indeed, I thought 
that was the main selling point.

>>> It's certainly possible with Windows. You just need to get the source
>>> code.
>> ...which you cannot ever have...
>
> Why do you say that? I had access to Windows source code at my previous
> job. Not the OS, but selected libraries.

You can actually do that?

>>> What part of Windows do you think is monolithic and can't be fairly
>>> easily replaced that *can* be replaced in Linux?
>>
>> When you install "Windows", it installs one giant binary blob. I'm sure
>> Microsoft probably structures it internally as many seperate modules, but
>> such seperation is not visible in the finished product.
>
> Not if you're not a coder. If you're writing a device driver or building
> a video card, I'm pretty sure it's lots of separate modules. Go into
> your control panel and look at the device drivers. Notice the
> "uninstall" bits there. Plug in a new USB device you never had before,
> or a new printer, or a new graphics tablet. What do you think happens,
> other than a new module being installed?

Sure. Device drivers are loadable modules. (Apparently with Linux, they 
aren't. You actually have to recompile the entire kernel to add a new 
device driver. Which is just weird...)

But if I wanted, say, to change the way services are managed... that's 
hard-wired in. (Unlike Linux, where it's just a shell script. And also 
doesn't work nearly as well.)

>> You mean there's more than one program that uses that particular shortcut
>> (for the same thing)?
>
> Anything with a text box. One of the nifty things about Windows is that
> early on, back when Gates was still making tech decisions, they built a
> text box object that *everyone* can use.

Isn't that how every OS works?

Oh, wait. Linux. The OS where every X Windows program has an utterly 
unrelated look and feel. (And usually a sucky one.) >_<

>> That's unlikely to ever be a problem for me. What /is/ a problem is
>> that Vi was utterly incomprehensible...
>
> True, it's unlikely to be a problem nowadays. Unless you wind up on an
> 8-bit machine again for some reason.

I wasn't on an 8-bit machine. I was on a normal PC, where I'd just 
installed RedHat. (Fortunately, these days installing Linux doesn't 
usually require manually editing X11Config to tell it which RAMDAC you 
have or whatever...)

> I was highly amused when I saw the icon for one of the emacs
> distributions was a kitchen sink.

Sounds about right.

>>> The point is not "here's a useful plug-in for Haskell", but to show you
>>> a counter-example to your assertion that VS doesn't support third-party
>>> languages.
>>
>> I didn't say that VS doesn't support third-party languages. I said it was
>> far too /hard/ to implement support for third-party languages.
>
> Too hard for who?

Of course, /everything/ is possible given enough manpower. My point is 
that writing a handful of lines of elisp is easier than writing 
something as complex and monolithic as a VS plugin.

> Well, no, adding libraries to Tcl when you're using freewrap is going to
> make anything difficult.

Oh, that's the problem, is it?

>> I don't actually /like/ Tcl all that much. I'd prefer something a bit
>> safer,
>> but hey... from the way you're talking, you make it sound as if almost
>> /every/ programming language can trivially access COM.
>
> Not necessarily "trivially". I don't know that I'd call the C++
> interface "trivial", since it requires a somewhat more complex build
> system and more data than just the COM object itself. But most scripting
> languages have a pretty easy way of invoking COM even if they don't well
> support writing servers for COM.

M'kay...

Post a reply to this message

On 08/08/2011 06:34 PM, Jim Henderson wrote:

> Pah, edlin.  Real programmers use copy con: ;)

Under AmigaDOS, CON: opens up a GUI console window. I forget the exact 
syntax, but you can do something like

   CON:/0/0/320/240/My window title

to open a window positioned at (0,0) that is 320 by 240 pixels large, 
with the specified title. There's even syntax for deciding which 
"gadgets" (widgets) it should have.

Those Amiga guys had some pretty sophisticated stuff happening, man.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Binary files and text files aren't the same.

  Clearly you aren't enough of a hacker.

-- 
                                                          - Warp

Post a reply to this message

Stephen <mcavoys_at@aoldotcom> wrote:
> I just checked and Edlin is not included in Win7 64 bit.

  What?! The sacrilege!

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 8/8/2011 7:01, Warp wrote:
> >> If you /need/ to generate large chunks of code automatically, you're
> >> writing your program wrong.
> >
> >    You could use the same argument for any of the several features in your
> > text editor that you, personally, never use.

> I'd more say that if you need to generate large chunks of code 
> automatically, your programming language is too low-level for the code 
> you're writing. Boilerplate is a sign that your language needs to be able to 
> automate the boilerplate.

  I don't think nemesis was restricting his reference to using templates
to generate content to program code. You could have all kinds of templates
to generate all kinds of documents, such as html, latex, etc.

-- 
                                                          - Warp

Post a reply to this message

On Tue, 09 Aug 2011 12:42:29 -0400, Warp wrote:

> Invisible <voi### [at] devnull> wrote:
>> Binary files and text files aren't the same.
> 
>   Clearly you aren't enough of a hacker.

Indeed, it's just data, after all.

Jim

Post a reply to this message