From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31361 invoked from network); 25 Jan 2021 16:38:32 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 25 Jan 2021 16:38:32 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0B7749C823; Tue, 26 Jan 2021 02:38:31 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C9D329C63D; Tue, 26 Jan 2021 02:38:05 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="DUXkWAp1"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 0B9689C63D; Tue, 26 Jan 2021 02:38:03 +1000 (AEST) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 78EB49C5FD for ; Tue, 26 Jan 2021 02:38:02 +1000 (AEST) Received: by mail-oi1-f171.google.com with SMTP id m13so7435486oig.8 for ; Mon, 25 Jan 2021 08:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6YwFzYUIVlTu9glJCPi7WBRHqSnYX9NYZ2WZNGZOGKw=; b=DUXkWAp1a1adMJtpZqpQUbCCR2doQRKcS4WTPADpKhA2+ud9cH1aRNBTP3ccKmdwFO 5/7jv2LoDraAQfZZsG0roJPhRtclTgnvLEDOp/t2df+9DnQEUjAADEeQ1+5ureeC3sor k33uUurvDxrzS8TN0YEVawVbVu8E6A1MNY05B2dVDZe+hXey3JCtfCbn6Qtnf3kGd9pM Kb/4fPcTU2lJTVtiJsQkY9/hDBaq+A+hCiMbNT24zsPq55YbRGlk6T7n/N59O9cjpXvG y4RY6ZZtEZ6gMAdozg8864XoUrl1sq/uC9LBlzlZ24o4S0gieCtuDu/CrP5mYJRfTxaM /xww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6YwFzYUIVlTu9glJCPi7WBRHqSnYX9NYZ2WZNGZOGKw=; b=cJ7dnaDmhY7IHjpj2WnOmpceGgo8WXnstAtPcKn3LR3axhAZvxMjRr2B8U/FflxDzf wIQjNUTWN00jTQrmIZbsX2GZnZGLgytHElCd6JpbTjFczD0JirB40n62AhPCyjz0MY6k OYh0CT5y7cAuAx9vLbmR5BFVQ0bfK+tjFqSoQ8RCTcfX2RqD4D6qVJxuiVUEDhfAeWNd pfP1NrSvKMAQMkZ8UI3hI5xC4pglhwnnDJuY432olBeYMJGAnU53iLgl8qKzfiaN2fhi aYQgJTbJeJF/PIxb9V/jjInhm5AD643t+fBba7GveNWr9/R7NH54mQSTt7Q6MzfgYx9b CyYw== X-Gm-Message-State: AOAM532Z8IGSLG0fuVRy1VeXt4ME4IFVuINjPxAUaIgLbr1gFNd0b0I6 loo3cJDaPPrP6wVpSfg3vI+T7eB6IlFoVixfoJv497xO6TU= X-Google-Smtp-Source: ABdhPJzqbD5JK3Fdw+QaC5se8GwOOfz73jHGUcnnYyQ5T4AHkepzX4OaJb97WUuwtaGz5wpCDVoc2Ea4EJ4cCIKaplI= X-Received: by 2002:aca:110b:: with SMTP id 11mr629508oir.174.1611592681814; Mon, 25 Jan 2021 08:38:01 -0800 (PST) MIME-Version: 1.0 References: <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> <20210125160430.GR21030@mcvoy.com> In-Reply-To: <20210125160430.GR21030@mcvoy.com> From: Dan Cross Date: Mon, 25 Jan 2021 11:37:25 -0500 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="00000000000052803905b9bc2907" Subject: Re: [TUHS] tangential unix question: whatever happened to NeWS? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000052803905b9bc2907 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 25, 2021 at 11:05 AM Larry McVoy wrote: > On Mon, Jan 25, 2021 at 10:55:34AM -0500, Richard Salz wrote: > > Osterhout's Tk was beyond amazing. > > Still is, really. So far as I know, nobody has come up with anything > better. > I think one of the innovations that kept it alive was that people took Tk itself and separated it from Tcl, so one saw bindings from any number of languages. The Inferno operating system that was essentially a commercialization of plan9, implemented Tk with the Limbo programming language (which in many ways is perhaps the most direct ancestor of Go). That was neat to play with. Too bad it didn't have a lot of success. > It had no XDR because it was "reader makes it right" and datatypes > > were tagged. > > That's the first I've heard of that and I really like it. Most of the > time, you are on a network of machines that are the same, so why have > a network byte order, reader makes it right will just work. Neat. > I guess I don't quite understand that. I can get how it works for simple data types (integers, floating point numbers, perhaps strings) but it seems like it breaks down pretty quickly for anything with a more complex representation (structures with multiple members, for instance; how does one deal with padding, etc?). "Reader makes right" makes some sense for any pair of sender/receiver architectures, but once you have more than a handful of machine types with potentially different ABIs/representations/alignment requirements, etc, then it seems like you're an n^2 mutual ABI understanding issue. Perhaps I'm being naive in assuming that multi-data structures are just written out in host format, but if you, say, write element by element to avoid that, then it seems like you're already nearly at an architecture independent data representation anyway, so what does NOT having that buy you? I guess it's potentially faster if you don't have to swab bytes between similar architectures? - Dan C. --00000000000052803905b9bc2907 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 25, 2021 at 11:05 AM Larry Mc= Voy <lm@mcvoy.com> wrote:
On Mon, Jan 25, 2021 at 10:55:34AM -0500, Richard Salz wrote:
> Osterhout's Tk was beyond amazing.

Still is, really.=C2=A0 So far as I know, nobody has come up with anything = better.

I think one of the innovations = that kept it alive was that people took Tk itself and separated it from Tcl= , so one saw bindings from any number of languages.

The Inferno operating system that was essentially a commercialization of = plan9, implemented Tk with the Limbo programming language (which in many wa= ys is perhaps the most direct ancestor of Go). That was neat to play with. = Too bad it didn't have a lot of success.

> It had no XDR because it was "reader makes it right" and dat= atypes
> were tagged.

That's the first I've heard of that and I really like it.=C2=A0 Mos= t of the
time, you are on a network of machines that are the same, so why have
a network byte order, reader makes it right will just work.=C2=A0 Neat.
=

I guess I don't quite understand that.= I can get how it works for simple data types (integers, floating point num= bers, perhaps strings) but it seems like it breaks down pretty quickly for = anything with a more complex representation (structures with multiple membe= rs, for instance; how does one deal with padding, etc?). "Reader makes= right" makes some sense for any pair of sender/receiver architectures= , but once you have more than a handful of machine types with potentially d= ifferent ABIs/representations/alignment requirements, etc, then it seems li= ke you're an n^2 mutual ABI understanding issue. Perhaps I'm being = naive in assuming that multi-data structures are just written out in host f= ormat, but if you, say, write element by element to avoid that, then it see= ms like you're already nearly at an architecture independent data repre= sentation anyway, so what does NOT having that buy you? I guess it's po= tentially faster if you don't have to swab bytes between similar archit= ectures?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--00000000000052803905b9bc2907--