>
> Cheers,
>
> Alan
>
> --
> *From:* BGB
> *To:* Fundamentals of New Computing
> *Sent:* Mon, May 10, 2010 5:50:31 PM
>
> *Subject:* Re: [fonc] Program representation
>
>
>
> - Original Message -
> *From:* John Nilsson
> *To:* Fundamen
: [fonc] Program representation
- Original Message -
>From: John Nilsson
>To: Fundamentals of New Computing
>Sent: Monday, May 10, 2010 3:33 PM
>Subject: Re: [fonc] Program
> representation
>
>
>
>On Mon, May 10, 2010 at 11:29 PM, BGB >wrote:
>
- Original Message -
From: John Nilsson
To: Fundamentals of New Computing
Sent: Monday, May 10, 2010 3:33 PM
Subject: Re: [fonc] Program representation
On Mon, May 10, 2010 at 11:29 PM, BGB wrote:
like having documentation in a hypertext form, and having code
On Mon, May 10, 2010 at 11:29 PM, BGB wrote:
>
> like having documentation in a hypertext form, and having code contain
> links into the docs, and from the docs back into the code?...
>
For example.
> I guess it would be a notable improvement on having to edit external files
> for the documents,
On Mon, May 10, 2010 at 8:55 PM, John Zabroski wrote:
> Can you provide an end-to-end exemplary situation in Enterprise Resource
> Planning (ERP) software where FONC ideas are relevant? You sort of jumped
> off that stream of thought and onto modeling sine waves graphically, etc.
>
Depends on wh
---
From: John Nilsson
To: Fundamentals of New Computing
Sent: Monday, May 10, 2010 11:22 AM
Subject: Re: [fonc] Program representation
On Mon, May 10, 2010 at 6:54 PM, John Zabroski wrote:
Schematic tables are a separate issue entirely.
First of all. Thanks for the
Can you provide an end-to-end exemplary situation in Enterprise Resource
Planning (ERP) software where FONC ideas are relevant? You sort of jumped
off that stream of thought and onto modeling sine waves graphically, etc.
I work in various roles of ERP/CRM/BI software, and so I understand the
doma
On Mon, May 10, 2010 at 6:54 PM, John Zabroski wrote:
>
> Schematic tables are a separate issue entirely.
>
First of all. Thanks for the explanation about the thinking wrt the TCP/IP
implementation. I'll have to peruse the code with that in mind.
My questions was, as you pointed out, about a sepa
On 2010/05/10, at 18:21 , John Nilsson wrote:
> When reading about the TCP/IP implementation in OMeta it strikes me
that parsing the
> ASCII-art is still text. Isn't it kind of silly to spend all that
syntax on representing
> something as fundamental as a table?
ASCII-art is not so bad. I
The ASCII-art is not what is important. The table is effectively loaded
directly from its source. In this way, an RFC document server negotiates
with the client seeking to build a TCP/IP stack. The client queries the
server and starts negotiating on the data interchange format for passing to
the
Hi,
When reading about the TCP/IP implementation in OMeta it strikes me that
parsing the ASCII-art is still text. Isn't it kind of silly to spend all
that syntax on representing something as fundamental as a table?
So I was wondering, have you, at vpri, been contemplating alternative
program repr
11 matches
Mail list logo
