Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #53455 > unrolled thread
| Started by | awegel@arcor.de (Alexander Wegel) |
|---|---|
| First post | 2016-12-21 01:19 +0100 |
| Last post | 2017-01-08 16:55 -0800 |
| Articles | 20 on this page of 266 — 26 participants |
Back to article view | Back to comp.lang.forth
"Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-21 01:19 +0100
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-24 05:40 -0600
Re: "Hello world" using Hughs novice package Julian Fondren <julian.fondren@gmail.com> - 2016-12-24 06:01 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-25 19:27 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-26 18:16 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-27 14:27 +0100
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-27 14:29 +0100
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-27 14:27 +0100
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-28 11:35 +1100
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2016-12-27 17:38 -0800
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-29 10:11 +1100
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2016-12-29 17:06 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-28 05:39 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-27 22:37 -0800
Re: "Hello world" using Hughs novice package crc <charles.childers@gmail.com> - 2016-12-28 05:40 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-28 23:03 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-30 20:54 +0100
Re: "Hello world" using Hughs novice package Coos Haak <htrofhc@gmail.com> - 2017-01-02 20:17 +0100
Re: "Hello world" using Hughs novice package mhx@iae.nl - 2017-01-02 12:22 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-02 22:08 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-02 21:40 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-03 13:51 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-03 21:51 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-06 19:36 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 19:01 +0100
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-08 12:06 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-08 16:46 -0800
Re: "Hello world" using Hughs novice package "Robert L." <No_spamming@noWhere_7073.org> - 2017-01-03 15:59 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-27 23:12 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-30 20:54 +0100
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-28 04:57 -0600
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-28 11:23 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-28 23:16 -0800
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-30 16:31 +0000
Re: "Hello world" using Hughs novice package "David N. Williams" <williams@umich.edu> - 2016-12-30 15:21 -0500
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-05 12:00 +0000
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-05 13:30 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-05 17:32 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-06 02:50 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-05 18:20 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-06 17:58 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 16:15 +0000
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-10 08:43 +0000
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-30 14:37 +0000
Re: "Hello world" using Hughs novice package john <anon@example.com> - 2016-12-30 15:57 +0000
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-30 17:19 +0000
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-30 21:10 +0000
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2016-12-30 12:44 -1000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 15:43 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-31 00:09 +0000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-03 17:25 +0000
Re: "Hello world" using Hughs novice package john <anon@example.com> - 2016-12-30 22:47 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-31 03:31 -0600
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-30 15:46 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 15:05 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-31 00:26 +0000
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-31 11:49 +1100
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2016-12-30 15:21 -1000
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2017-01-02 11:11 +1100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 00:28 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-01 17:45 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-01 20:57 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 06:55 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 10:44 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 07:01 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 15:46 +0000
Re: "Hello world" using Hughs novice package john <anon@example.com> - 2017-01-02 16:54 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 10:23 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 10:06 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 19:13 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 14:08 -0800
Re: "Hello world" using Hughs novice package mhx@iae.nl - 2017-01-02 14:46 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 17:10 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-02 21:58 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-03 15:54 -0800
Re: "Hello world" using Hughs novice package JUERGEN <epldfpga@aol.com> - 2017-01-04 06:21 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-04 11:19 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-04 22:34 +0100
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-04 14:44 -0800
Re: "Hello world" using Hughs novice package JUERGEN <epldfpga@aol.com> - 2017-01-04 15:13 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-05 08:18 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-04 23:17 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 04:15 -0600
Re: "Hello world" using Hughs novice package mhx@iae.nl - 2017-01-08 01:18 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-08 15:52 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-08 21:00 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-09 15:58 -0800
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-09 17:39 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-09 18:53 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-12 06:27 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-12 13:44 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-12 17:36 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-13 03:17 -0600
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-13 14:44 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-13 14:43 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 00:23 +0000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 11:52 +0000
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 16:00 +0000
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-14 11:51 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-14 15:06 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 14:54 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-15 13:33 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-13 16:06 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 00:25 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-13 18:00 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-13 22:17 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-13 16:04 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-13 15:08 -1000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-13 17:21 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 11:26 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-13 18:21 -0800
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-13 18:30 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-13 22:20 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-14 10:43 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-14 15:47 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-14 17:30 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-14 18:16 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-15 13:53 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-15 14:09 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-15 15:48 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-15 16:00 -0800
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-15 12:48 +0100
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-14 10:10 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-15 17:56 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-15 17:05 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-15 17:35 -0800
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-15 19:20 -0800
Re: "Hello world" using Hughs novice package Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-15 23:51 -0500
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-15 19:22 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-18 16:24 -0800
Re: "Hello world" using Hughs novice package foxaudioresearch@gmail.com - 2017-01-18 18:40 -0800
Re: "Hello world" using Hughs novice package Ron Aaron <rambamist@gmail.com> - 2017-01-19 06:46 +0200
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-18 23:25 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 09:47 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 02:44 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 06:16 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 07:43 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 11:07 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 14:58 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-20 03:48 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 06:54 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-20 09:11 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 07:30 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-20 12:12 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 16:27 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-21 03:24 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-22 12:47 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-22 14:41 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-22 15:57 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-23 04:05 -0600
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-23 10:47 -0800
Re: "Hello world" using Hughs novice package Mark Wills <markwills1970@gmail.com> - 2017-01-24 01:02 -0800
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-24 01:12 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-23 16:28 -0800
Re: "Hello world" using Hughs novice package Mark Wills <markwills1970@gmail.com> - 2017-01-24 01:06 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 03:22 -0600
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 14:19 +0100
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 03:13 -0600
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-24 08:08 -0500
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 14:23 +0100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-24 09:10 -0500
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-24 15:35 +0000
Persitent memory (was Re: "Hello world" using Hughs novice package) Alex <alex@rivadpm.com> - 2017-01-24 14:19 -0500
Re: Persitent memory (was Re: "Hello world" using Hughs novice package) Alex <alex@rivadpm.com> - 2017-01-24 15:00 -0500
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-24 14:49 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-25 03:26 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-26 04:27 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 08:35 -0600
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-21 14:19 +0100
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-22 12:55 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 15:28 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 14:44 -0800
Re: "Hello world" using Hughs novice package Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-19 20:30 -0500
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-20 18:21 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-20 03:52 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 06:58 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-20 12:57 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 16:31 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-20 17:31 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-19 08:48 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 17:18 +0000
Re: "Hello world" using Hughs novice package alex@rivadpm.com - 2017-01-19 11:01 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 14:51 -0800
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-19 13:07 +0100
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 14:26 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-16 09:03 -0600
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-15 15:08 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-15 17:23 -0800
Re: "Hello world" using Hughs novice package Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-15 22:18 -0500
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-16 09:08 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-18 06:56 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 09:31 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-15 17:33 -0600
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-10 09:55 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-09 04:05 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-09 16:00 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-10 04:13 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-12 06:40 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-02 21:07 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-03 04:46 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-03 16:11 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-04 04:27 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-04 14:26 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-04 23:09 +0000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 00:02 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-05 02:19 -0800
Re: "Hello world" using Hughs novice package rickman <gnuarm@gmail.com> - 2017-01-05 05:56 -0500
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-05 06:33 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-05 16:56 +0100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-05 19:03 +0000
Re: "Hello world" using Hughs novice package rickman <gnuarm@gmail.com> - 2017-01-06 06:45 -0500
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 04:27 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-05 06:22 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 09:10 -0600
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-04 23:05 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-03 22:05 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-04 13:44 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-01 20:53 -1000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-01 19:55 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-01 21:13 -0800
Re: "Hello world" using Hughs novice package foxaudioresearch@gmail.com - 2017-01-02 07:14 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-02 07:42 -1000
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-03 02:00 +0100
Re: "Hello world" using Hughs novice package Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-03 00:13 -0500
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-02 22:02 -1000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-03 11:19 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-03 21:37 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-02 21:55 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-03 11:26 +0000
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 10:47 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-02 20:57 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 18:35 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-31 04:29 +0100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-31 10:19 +0000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-02 17:08 +0000
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2017-01-06 13:39 +1100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-05 19:13 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-27 23:57 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-30 20:54 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-29 19:05 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-29 19:38 -0800
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-30 15:24 +1100
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-30 16:01 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 14:33 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-29 16:04 -0800
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-30 12:42 +1100
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-30 07:24 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 12:50 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-30 21:43 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 14:38 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-31 10:31 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-31 07:04 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-31 07:07 -0800
Re: "Hello world" using Hughs novice package Julian Fondren <julian.fondren@gmail.com> - 2016-12-31 07:46 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-31 08:28 -0800
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-30 16:53 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-06 20:49 -0800
Re: "Hello world" using Hughs novice package Cecil Bayona <cbayona@cbayona.com> - 2017-01-06 23:28 -0600
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-06 22:22 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-07 21:20 +0000
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-07 22:57 +0100
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-08 17:02 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-08 16:55 -0800
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-24 08:08 -0500 |
| Message-ID | <o67jhb$vsb$1@dont-email.me> |
| In reply to | #54346 |
On 1/24/2017 04:13, Andrew Haley wrote: >> so it is your problem how to persuade others to agree. If many are >> disagree, what is the reason to declare file IO as a standard? It >> is library or even application-level words, not a part of >> language. > I don't think that's right. AFAIK the last time anyone tried to > standardize a language without I/O was ALGOL 60, and that was a > major mistake: it was effectively impossible to ALGOL programs to do > anything significant. There are some significant technology advances to look out for in the next few years (ok, a decade or so) in the area of persistent memory (PM). It's byte rather than block addressable technology; like DRAM but based on flash-like parts, it provides direct load/store operations rather than demanding a CPU expensive IO stack. Perhaps there's a future for a language that specifies memory mapping as an intrinsic feature, but that doesn't specify IO because it isn't required. http://www.snia.org/sites/default/files/PM-Summit/2017/presentations/Andy_Rudoff_The_SNIA_NVM_Programming_Model_Latest_Developments_Challenges.pdf http://pmem.io/ -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-24 14:23 +0100 |
| Message-ID | <o67kfr$ddb$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54353 |
In article <o67jhb$vsb$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >On 1/24/2017 04:13, Andrew Haley wrote: >>> so it is your problem how to persuade others to agree. If many are >>> disagree, what is the reason to declare file IO as a standard? It >>> is library or even application-level words, not a part of >>> language. >> I don't think that's right. AFAIK the last time anyone tried to >> standardize a language without I/O was ALGOL 60, and that was a >> major mistake: it was effectively impossible to ALGOL programs to do >> anything significant. > >There are some significant technology advances to look out for in the >next few years (ok, a decade or so) in the area of persistent memory >(PM). It's byte rather than block addressable technology; like DRAM but >based on flash-like parts, it provides direct load/store operations >rather than demanding a CPU expensive IO stack. > >Perhaps there's a future for a language that specifies memory mapping as >an intrinsic feature, but that doesn't specify IO because it isn't >required. > >http://www.snia.org/sites/default/files/PM-Summit/2017/presentations/Andy_Rudoff_The_SNIA_NVM_Programming_Model_Latest_Developments_Challenges.pdf Is there a text that goes with those slides? > >http://pmem.io/ > >-- >Alex -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-24 09:10 -0500 |
| Message-ID | <o67n6a$dv9$1@dont-email.me> |
| In reply to | #54355 |
On 1/24/2017 08:23, Albert van der Horst wrote: > In article <o67jhb$vsb$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >> On 1/24/2017 04:13, Andrew Haley wrote: >>>> so it is your problem how to persuade others to agree. If many are >>>> disagree, what is the reason to declare file IO as a standard? It >>>> is library or even application-level words, not a part of >>>> language. >>> I don't think that's right. AFAIK the last time anyone tried to >>> standardize a language without I/O was ALGOL 60, and that was a >>> major mistake: it was effectively impossible to ALGOL programs to do >>> anything significant. >> >> There are some significant technology advances to look out for in the >> next few years (ok, a decade or so) in the area of persistent memory >> (PM). It's byte rather than block addressable technology; like DRAM but >> based on flash-like parts, it provides direct load/store operations >> rather than demanding a CPU expensive IO stack. >> >> Perhaps there's a future for a language that specifies memory mapping as >> an intrinsic feature, but that doesn't specify IO because it isn't >> required. >> >> http://www.snia.org/sites/default/files/PM-Summit/2017/presentations/Andy_Rudoff_The_SNIA_NVM_Programming_Model_Latest_Developments_Challenges.pdf > > Is there a text that goes with those slides? https://www.youtube.com/watch?v=1Eyj3vOPe3Q start at 1:31:00. Sound sync a little out. > >> >> http://pmem.io/ >> >> -- >> Alex -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-24 15:35 +0000 |
| Message-ID | <2017Jan24.163551@mips.complang.tuwien.ac.at> |
| In reply to | #54353 |
Alex <alex@rivadpm.com> writes:
>On 1/24/2017 04:13, Andrew Haley wrote:
>>> so it is your problem how to persuade others to agree. If many are
>>> disagree, what is the reason to declare file IO as a standard? It
>>> is library or even application-level words, not a part of
>>> language.
>> I don't think that's right. AFAIK the last time anyone tried to
>> standardize a language without I/O was ALGOL 60, and that was a
>> major mistake: it was effectively impossible to ALGOL programs to do
>> anything significant.
>
>There are some significant technology advances to look out for in the
>next few years (ok, a decade or so) in the area of persistent memory
>(PM). It's byte rather than block addressable technology; like DRAM but
>based on flash-like parts, it provides direct load/store operations
>rather than demanding a CPU expensive IO stack.
Given that we have DMA, the CPU expense of I/O is not moving the data
between the device and memory, but getting the data to/from memory;
and the persistent memory technology does not change that.
>Perhaps there's a future for a language that specifies memory mapping as
>an intrinsic feature,
Such as Gforth's SLURP-FILE and SLURP-FID, or POSIX mmap()?
> but that doesn't specify IO because it isn't
>required.
I/O is not about persistence; as it's name says, it's actually about
input and output (e.g., KEY and EMIT in Forth), and its use for
persistence is just one use. A text editor needs I/O to get input
from the user, show (parts of) the text file to the user, and to load
and store text files; and the loading and storing of text files are
not primarily persistence features, but are important functionality:
The consumer of the text file (e.g., a compiler) reads these files.
I don't think that persistent memory will change much, for the
following reasons:
1) We did have persistent main memory (e.g., core memory) until DRAM
replaced core memory. We did have I/O in those times; admittedly core
memory was not the last level in the hierarchy in those times.
2) We have had image-based programming environments such as
Smalltalk-80, and more-or-less image-based applications such as MS
Word of old times. These programming environments did not catch on,
and MS Word switched to an XML-based document representation instead
of just using a memory dump of the word processor as document
representation.
3) We have had OSs (IIRC EROS) that provided a pretty good
approximation to persistent memory even on DRAM hardware; actually the
approximation is better than that provided by most file systems: in
case of a crash, you get the state of the system of some time (maybe
30s) before the crash. These OSs have not caught on.
4) People start a lot of software from scratch just to get rid of
leaked memory, bad internal state, etc. Software that cannot save and
restore the things that the user wants to preserve across the restart
is unlikely to fly (ok, people accepted MS Word despite this problem,
but even MS Word eventually gave up on the memory dump approach).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-24 14:19 -0500 |
| Subject | Persitent memory (was Re: "Hello world" using Hughs novice package) |
| Message-ID | <o6898b$jbg$1@dont-email.me> |
| In reply to | #54360 |
On 1/24/2017 10:35, Anton Ertl wrote: > Alex <alex@rivadpm.com> writes: >> On 1/24/2017 04:13, Andrew Haley wrote: >>>> so it is your problem how to persuade others to agree. If many are >>>> disagree, what is the reason to declare file IO as a standard? It >>>> is library or even application-level words, not a part of >>>> language. >>> I don't think that's right. AFAIK the last time anyone tried to >>> standardize a language without I/O was ALGOL 60, and that was a >>> major mistake: it was effectively impossible to ALGOL programs to do >>> anything significant. >> >> There are some significant technology advances to look out for in the >> next few years (ok, a decade or so) in the area of persistent memory >> (PM). It's byte rather than block addressable technology; like DRAM but >> based on flash-like parts, it provides direct load/store operations >> rather than demanding a CPU expensive IO stack. > > Given that we have DMA, the CPU expense of I/O is not moving the data > between the device and memory, but getting the data to/from memory; > and the persistent memory technology does not change that. It does change it, because unlike previous solutions, this memory is at considerable scale. The size of these parts is already in the TB range for a single NVDIMM-F (block access) or NVDIMM-P (byte). The big downside of I/O: as PM devices reduce latency down into the usec and then nsec range, the I/O stack becomes a bigger & bigger %age of it. The goal is to eliminate the software stack, buffering and so on, not mitigate it. Network assisted data transfer from memory to memory is already available, and a lot of protocols already support it; iWARP enables NFS, SMB, SCSI and iSCSI RDMA for example. The CPU doesn't need to be involved. I/O is a memory to memory transfer instead with no CPU load. > >> Perhaps there's a future for a language that specifies memory mapping as >> an intrinsic feature, > > Such as Gforth's SLURP-FILE and SLURP-FID, or POSIX mmap()? Yes, precisely. See http://pmem.io specifically http://pmem.io/nvml/ and the library support for mapping. A Forth interface would be ideal. > >> but that doesn't specify IO because it isn't >> required. > > I/O is not about persistence; as it's name says, it's actually about > input and output (e.g., KEY and EMIT in Forth), and its use for > persistence is just one use. A text editor needs I/O to get input > from the user, show (parts of) the text file to the user, and to load > and store text files; and the loading and storing of text files are > not primarily persistence features, but are important functionality: > The consumer of the text file (e.g., a compiler) reads these files. Hmmm. That is not the use case I was imagining; more HPC, database in memory, large scale simulations, genome anaysis etc. There, I/O is the necessary evil to get at persistent data, however it is stored. Memory on the bus gives us load/store capability, and persistence there is hardly a secondary characteristic. (At least, one hopes so, since a lack of persistence is generally fatal to an application.) > > I don't think that persistent memory will change much, for the > following reasons: > > 1) We did have persistent main memory (e.g., core memory) until DRAM > replaced core memory. We did have I/O in those times; admittedly core > memory was not the last level in the hierarchy in those times. But latency factors between core and the next memory medium were (and still are between DRAM and disk) of the order of 10^6. PM in the form of bus NVDIMM flash (based on stt-ram, 3d Xpoint etc) puts it at 10^3 or less; high 10s of nsecs of latency. Scale is a factor here. Spinning rust is just too expensive (certainly for latency & power, less so for bandwidth & initial $/bit). As flash becomes logarithmically cheaper, disk doesn't; we're almost at the end of the kind of growth exhibited by Kryder's law, and certainly manufacturers are innovating and slowly increasing areal density (HAMR, helium, shingling etc), but they're doing so without a great deal of enthusiasm as the margins are very small. 1TB+ parts are already available in NVDIMM form, and the density of that promises to grow rapidly. Disks are going to top out at probably 40TB in the 2020s, and be as slow (if not slower) than today's snail like performance when compared to solid state drives. SSDs will be less attractive, since flash on NVDIMM latencies are currently much lower (a factor of 100 or so). > > 2) We have had image-based programming environments such as > Smalltalk-80, and more-or-less image-based applications such as MS > Word of old times. These programming environments did not catch on, > and MS Word switched to an XML-based document representation instead > of just using a memory dump of the word processor as document > representation. > > 3) We have had OSs (IIRC EROS) that provided a pretty good > approximation to persistent memory even on DRAM hardware; actually the > approximation is better than that provided by most file systems: in > case of a crash, you get the state of the system of some time (maybe > 30s) before the crash. These OSs have not caught on. They will; but in another form. Snapshotting can be done by storage currently (a form of checkpointing but without requiring the application or OS to support it) and I fully expect to see it as a feature of PM. The OS need not be aware of it, and some softwares (especially filesystems and databases) are already crash restartable. Yes, there's much work needed here, but a great deal of investment has already been made; see https://lwn.net/Articles/610174/. DAX (a horrible acronym for "direct access") is supported by both Linux and Windows 2016, and XFS and ext4 both support PM based filesystems. > > 4) People start a lot of software from scratch just to get rid of > leaked memory, bad internal state, etc. Software that cannot save and > restore the things that the user wants to preserve across the restart > is unlikely to fly (ok, people accepted MS Word despite this problem, > but even MS Word eventually gave up on the memory dump approach). That is a significant problem that needs addressed; for one, the big red switch approach to clearing memory won't work here. https://lwn.net/Articles/610184/ discusses this. > > - anton > -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-24 15:00 -0500 |
| Subject | Re: Persitent memory (was Re: "Hello world" using Hughs novice package) |
| Message-ID | <o68bls$t2p$1@dont-email.me> |
| In reply to | #54364 |
On 1/24/2017 14:19, Alex wrote:
> But latency factors between core and the next memory medium were (and
> still are between DRAM and disk) of the order of 10^6. PM in the form of
> bus NVDIMM flash (based on stt-ram, 3d Xpoint etc) puts it at 10^3 or
> less; high 10s of nsecs of latency.
I found some Microsoft performance figures.
IOPS Avg Latency (ns) MB / Sec
NVMe SSD 14,553 66,632 56.85
Block Mode NVDIMM 148,567 6,418 580.34
DAX Mode NVDIMM 1,112,007 828 4,343.78
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-24 14:49 -0800 |
| Message-ID | <f959ed2c-4be0-469e-bfa4-981ead8c7f58@googlegroups.com> |
| In reply to | #54346 |
> I don't think that's right. AFAIK the last time anyone tried to > standardize a language without I/O was ALGOL 60, and that was a major > mistake: it was effectively impossible to ALGOL programs to > do anything significant. fopen() is not a part of C language. IO functions are defined in stdio.h, so it is a library, not a language. Alternative is stream library, for example. Pascal has write and read as a part of language, but this often considered as a trade-off for teaching purposes. > That one has already been asked and answered, in particular by > Elizabeth Rather. It's about portability for programs, libraries, and > programmers. Read my posts carefully, please. First, if I have questions, you cannot prove your answer by your other answer of same style. Second, 'because of Elizabeth Rather' is not an answer at all. Third, I see no logic here. I ask you, why don't use wide-know portable library (see what POSIX means, especially 'P'). You wrote this is about portability. Finally, you use a library, not compatible with known portable library, for portability? :) > > Of course yes. Type this in console and check. I mean Windows > > command prompt, not Forth. If no file1.txt present, you will receive > > a message, but console will not crash. > > Right, and that happens because "cp" very carefully checks everything. > It doesn't just throw an exception and exit the program. Try to write a program, doing system calls with simplest wrappers over fileIO API. Your program will not close, unless you explicitly write a handler, doing this on file IO error. This is what many compilers provide as a default handler, and this is why block, similar to CATCH THROW are required there. > > Again, you not imagine your position clearly and mixing different > > conditions of usage. I describe my use case several times. It is > > desktop application and simple scripts. Why do you try to switch me > > to real-time control systems? > > I don't care to switch you. I merely explain why things are the way > they are. Your explanation is not good. > > So, how critical systems must be designed and what part of this > > design focused on THROW mechanism? > > Very carefully. If so, THROW solves no problem. > > I know how it works. Errno is a global variable in Quark. > > What is Quark? Some kind of yogurty thing, isn't it? You were > talking about POSIX. I wrote before Quark Forth is my current main tool for PC. I use IEEE754, POSIX and OpenGL as close to their original guides as possible. > > You are thinking in the terms of word naming. > > I'm not. And I'll thank you for not telling me what I'm thinking of. Sorry, I have no plan to make you angry. However, if we want to discuss a real problem, we must not stop on the 'best we can'. Harder problem needs more efforts, so many questions, answers and arguments should be passed by. Usually peoples tell me 'thank you for questions, this helps us to present our project better and avoid trivial traps'.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-25 03:26 -0600 |
| Message-ID | <isSdnVguKvHW8hXFnZ2dnUU7-RHNnZ2d@supernews.com> |
| In reply to | #54369 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> I don't think that's right. AFAIK the last time anyone tried to >> standardize a language without I/O was ALGOL 60, and that was a major >> mistake: it was effectively impossible to ALGOL programs to >> do anything significant. > > fopen() is not a part of C language. So what? It is part of the C language standard. That's just as it is in Forth, with the optional File-Access word set. Forth does not distinguish between language and library. >> That one has already been asked and answered, in particular by >> Elizabeth Rather. It's about portability for programs, libraries, and >> programmers. > > Read my posts carefully, please. First, if I have questions, you > cannot prove your answer by your other answer of same style. Her explanation was perfectly adequate. > Second, 'because of Elizabeth Rather' is not an answer at > all. Third, I see no logic here. I ask you, why don't use wide-know > portable library (see what POSIX means, especially 'P'). POSIX is a standard for UNIX. C has its own portable file I/O, and it is not POSIX. Forth has its own portable file I/O, and it is not POSIX either. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-26 04:27 -0800 |
| Message-ID | <f08ee224-1ef0-4e79-aa98-213fc000546e@googlegroups.com> |
| In reply to | #54383 |
> > fopen() is not a part of C language. > > So what? It is part of the C language standard. That's just as it is > in Forth, with the optional File-Access word set. Forth does not > distinguish between language and library. Terminology is not too important. Officially, fopen() defines in stdio.h. From programmer's point of view, fopen() is a 'function for opening file in C'. This matters primarly as a code pattern to decrease code&debug time. Different format broke this pattern and forces programmer to remember how it works in Forth. > >> That one has already been asked and answered, in particular by > >> Elizabeth Rather. It's about portability for programs, libraries, and > >> programmers. > > > > Read my posts carefully, please. First, if I have questions, you > > cannot prove your answer by your other answer of same style. > > Her explanation was perfectly adequate. No, it is not adequate. It is a set of slogans. I don't plan to force someone to cancel OPEN-FILE usage, but just describe my position and reasons to choose syntax and calling format. Programming world is larger than Forth, and even someone known as a Forth expert, it is not enough to accept anything from him/her without any question. Other languages are exist and other experts are taking part in the programmers activity. Let me decide at least for myself, is it persuasively or not. I hope you don't think the fact I use Forth makes me you/Forth Inc/Rather's follower :) > > Second, 'because of Elizabeth Rather' is not an answer at > > all. Third, I see no logic here. I ask you, why don't use wide-know > > portable library (see what POSIX means, especially 'P'). > > POSIX is a standard for UNIX. C has its own portable file I/O, and it > is not POSIX. Forth has its own portable file I/O, and it is not > POSIX either. I use 'POSIX-style' and 'POSIX-like' many times during this thread. This is just a reference to common used library, with which ANS-Forth is incompatible. My general question is WHY. This relates not to our poor OPEN-FILE, but to overall approach to developing Forth. Cultivating weirdness is not a good strategy.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-26 08:35 -0600 |
| Message-ID | <092dneq2oLC8lBfFnZ2dnUU7-XvNnZ2d@supernews.com> |
| In reply to | #54423 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > >> >> That one has already been asked and answered, in particular by >> >> Elizabeth Rather. It's about portability for programs, libraries, and >> >> programmers. >> > >> > Read my posts carefully, please. First, if I have questions, you >> > cannot prove your answer by your other answer of same style. >> >> Her explanation was perfectly adequate. > > No, it is not adequate. It is a set of slogans. I don't plan to > force someone to cancel OPEN-FILE usage, but just describe my > position and reasons to choose syntax and calling > format. We understand your position. You understand mine. > Programming world is larger than Forth, and even someone known as a > Forth expert, it is not enough to accept anything from him/her > without any question. Obviously not. Nobody wants to force you to do anything. Nobody wants you to accept anything without question. Especially not me! What I want to do is answer your questions and complaints, and explain why things are the way they are. It's extremely unlikely that any standard will be a perfect fit for every particular use. All I can do is say that it has been thought about, and try to explain the patterns that led to a decision. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-21 14:19 +0100 |
| Message-ID | <o5vn4e$ib8$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54211 |
In article <63f6f376-378a-4ab0-97e1-a78647f87663@googlegroups.com>, Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> > Yes, by slightly delay ABORT (by THROW) or by ignoring the error (by >> > DROP). In any case, why this parameter ever leaved on stack? >>=20 >> So that you can say OPEN-FILE IF . > >I don't want to chaotically choose syntax when invent a workaround. I can u= >se ( -- handle, ior ) notation by many ways. Why I even must think about th= >is, if I have an experience in other languages and want just to copy that a= >pproach to Forth? This is what I want to say - be more customer-facing and = >don't dictate strange ways for common things if it is not critical. If this bothers you so much, start your file with: \ ---------------------8 < ---------------------------- \ WARNING: this may result in mysterious problems later on. : OPEN-FILE OPEN-FILE THROW ; : READ-FILE READ-FILE THROW ; : WRITE-FILE WRITE-FILE THROW ; : CLOSE-FILE CLOSE-FILE THROW ; \ ---------------------8 < ---------------------------- <SNIP> Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-22 12:55 -0800 |
| Message-ID | <4c6fe6b5-ac8c-402c-955b-f8e14fa13185@googlegroups.com> |
| In reply to | #54222 |
> If this bothers you so much, start your file with: > > \ ---------------------8 < ---------------------------- > \ WARNING: this may result in mysterious problems later on. Explain me please, why Borland and Microsoft don't face these mysterious problems? I just derive syntax of file IO from Borland Pascal and slightly modify this later for C programmers. What kind of problems do you mean? > : OPEN-FILE OPEN-FILE THROW ; > : READ-FILE READ-FILE THROW ; > : WRITE-FILE WRITE-FILE THROW ; > : CLOSE-FILE CLOSE-FILE THROW ; This is a way I already implement :) Ok, let's think a little. If OPEN-FILE leaves ior on stack, it seems you have several ways to use it, right? Executing THROW was claimed as an element of safety. What happens in this case: OPEN-FILE DROP Ior still present, but ignored. This is worse than THROW, right? Ok, so can we claim THROW is a best way to continue after OPEN-FILE? If yes, let's make a next step and add THROW inside OPEN-FILE to prevent improper error handling.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-19 15:28 +0000 |
| Message-ID | <2017Jan19.162836@mips.complang.tuwien.ac.at> |
| In reply to | #54157 |
Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
>Another trap. If file is missing or disk is damaged, what exactly my progra=
>m can do? How often THROW provide any kind of automatic workaround in real =
>programs? With built-in ABORT, any file IO word can just abort execution an=
>d return to command line. This is not a crash of entire Forth session.
If a THROW is not caught, it eventually performs an ABORT, so THROW
just provides additional capabilities.
Concerning dealing with missing files, we certainly do that in Gforth;
e.g., Gforth's INCLUDED tries to open the file in a number of
directories (specified in a search path) before finally giving up. Or
if Gforth cannot open it's history for writing, it just does not write
to its history.
However, my most common usage of CATCH is for cleaning up when leaving
a word that needs to clean up something, even if it is left through an
exception. Even if the reTHROW falls through to the system, this is
useful.
>Another side of a problem is server application. For servers, an ability to=
> recover from such kind of errors is important. This is why I highlight a p=
>reliminary planning work - one solution is preferrable for server applicati=
>ons, and other for desktop/embedded. Missing file or file read error in emb=
>edded application usually means hardware failure with no possible software =
>recovering.
A missing file is a common occurence in desktop usage; you don't want
to abort your word processor when the user types the wrong directory
name for saving the text.
For embedded usage, catching the error and continuing with reduced
functionality is often preferable to stopping the system.
>> >Btw, strings are ASCIIZ, because it is natural for MS Windows API.
>>=20
>> Other people tell me that the Windows API uses UTF-16 instead of
>> ASCII.
>
>Windows API use both encoding. Letter A or U is added for function name to =
>explicitly describe which kind of string format is required. So, MessageBox=
>A and MessageBoxU are exist.
Wow, definitely the system that should be used for determining Forth
interfaces. Not!
>> Complicating Forth interfaces for the benefit of simpler
>> implementation on some systems has proved to be a mistake in the past
>> (in particular, having the parameters of foreign functions in
>> reverse), and is a mistake in this case, too. We have a standard
>> string representation (c-addr u), and we should use it all the time in
>> Forth, and convert at the borders. The alternative of having ASCIIZ
>> strings here, UTF-16 strings there, c-addr u UTF-8 strings yonder,
>> byte-counted strings in another place, and cell-counted strings
>> elsewhere is confusing and therefore error-prone.
>
>With intensive use of API calls, many convertions are required.
If you are referring to the run-time cost of that: Yes, but that's ok.
The API call has a cost that usually far exceeds the conversion cost,
so adding the conversion cost does not make it much more expensive.
If you are referring to explicit conversions needed to be performed by
the programmer, my preference is to actually do the conversion in the
word for the API call. I.e., if you want to call the POSIX function
int creat(const char *pathname, mode_t mode);
the Forth interface to it should ideally be
creat ( c-addr u x -- n )
and the conversion is performed between calling CREAT on the Forth
level and calling creat() on the C level.
>> Take a look at the recognizer proposal.
>
>Recognizers looks opposite to Forth basics because raises complexity level =
>too high. The question is not just 'how to provide anything user ask for', =
>but 'what from user demands we can provide with minimum efforts'. Recognize=
>rs will lead to full-scale syntax analyzer, and this completely breaks the =
>simplicity of Forth. Programmers may not want to implement Forth, because w=
>ith an ability to write recognizers they certainly can implement other C-li=
>ke language.
Why would anybody use Forth to implement a C-like language? And if
they want to do it, they don't need recognizers for it. Chuck Moore
and Andrew Haley implemented BASIC without using recognizers, and
Julian Noble implemented his Formula Translator also without using
recognizers.
You suggested C syntax for strings, and recognizers can give you that.
But in general they are not particularly helpful for implementing C
syntax. Even the C-syntax strings are already outside the comfort
zone of recognizers (recognizing white-space-delimited things).
Recognizers normally just recognize single word-like things (e.g.,
numbers, FP numbers, dates, times), which is something else than what
I would expect from a "full-scale syntax analyzer" (but since you have
not defined the term, it's hard to know).
They give programmers flexibility (something you claim you want), and
the "too high" complexity you claim has not led to a significant code
size increase in AmForth.
My guess is that many system implementors react negatively to
recognizers because a part of their business model is to provide
enhancements like recognizing date syntax to customers as a service.
If the customers or a third party can then do it themselves through a
standardized interface, that may reduce revenue.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-19 14:44 -0800 |
| Message-ID | <7836c18e-1e25-4b23-b8d4-ebfdcc11f132@googlegroups.com> |
| In reply to | #54171 |
> If a THROW is not caught, it eventually performs an ABORT, so THROW > just provides additional capabilities. My observation: THROW (and similar blocks in other languages) uses rarely enough, unless professional programmers are taking part in the project. An additional word which cannot be avoided is annoying. > Concerning dealing with missing files, we certainly do that in Gforth; > e.g., Gforth's INCLUDED tries to open the file in a number of > directories (specified in a search path) before finally giving up. Or > if Gforth cannot open it's history for writing, it just does not write > to its history. Many ways may be applied, like many ways to miss file are exist. File may be deleted, moved, blocked by another process etc. Automatic workaround is too complex for simple programs. > A missing file is a common occurence in desktop usage; you don't want > to abort your word processor when the user types the wrong directory > name for saving the text. I see no problem in executing ABORT in Forth-based text editor. If designed properly, Forth just returns to prompt without losing entire text. Another attempt to open or save file may be started after this. If Forth is event-driven, wrong messages (like access to missing file) will be discarded by ABORT and message loop will be continued normally. Of course, if you try to write an outer interpreter, you must carefully handle each risky action. > For embedded usage, catching the error and continuing with reduced > functionality is often preferable to stopping the system. In general, no. Hardware failure means something is really bad. Embedded computer close to PC by programming style, if it has SD card, DDR memory and Linux onboard. For low-level embedded there is no possibility to reduce functionality - it works or not. > >Windows API use both encoding. Letter A or U is added for function name to = > >explicitly describe which kind of string format is required. So, MessageBox= > >A and MessageBoxU are exist. > > Wow, definitely the system that should be used for determining Forth > interfaces. Not! Yes. What is simplier - writing a Forth or rewriting OS? Someone claims he can write a Forth, optimized for a platform, but, when asked, tells about limitations? > If you are referring to explicit conversions needed to be performed by > the programmer, my preference is to actually do the conversion in the > word for the API call. I.e., if you want to call the POSIX function > > int creat(const char *pathname, mode_t mode); > > the Forth interface to it should ideally be > > creat ( c-addr u x -- n ) > > and the conversion is performed between calling CREAT on the Forth > level and calling creat() on the C level. From my point of view, programmer should read his favourite guide and call Forth word with the same interface. Why const char * name must be converted to c-addr u? How many else places are exist where conversions must be performed? > Why would anybody use Forth to implement a C-like language? And if No reasons. If programmer is so skilled to work with syntax analyzer, he definitely has more intresting things to implement. More specialists may need a programming language, and Forth may be a solution for them, unless too complex algorithms will be added as mandatory. > You suggested C syntax for strings, and recognizers can give you that. Why do I need recognizers for such simple thing? If next token is not found, we may simple check it's first chat is quote and pass it to string processign word. > But in general they are not particularly helpful for implementing C > syntax. Even the C-syntax strings are already outside the comfort > zone of recognizers (recognizing white-space-delimited things). > Recognizers normally just recognize single word-like things (e.g., > numbers, FP numbers, dates, times), which is something else than what > I would expect from a "full-scale syntax analyzer" (but since you have > not defined the term, it's hard to know). At the end of this way we may find 'Dragon Book' :)
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-19 20:30 -0500 |
| Message-ID | <20170119203005.6109a51f@_> |
| In reply to | #54171 |
On Thu, 19 Jan 2017 15:28:36 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Why would anybody use Forth to implement a C-like language? How did you intend for this statement to be understood? a) C is so bad compared to Forth that no Forth programmer would do this b) C is too complex to parse with Forth c) only and idiot would attempt this d) someone could do this, but it'd be a complete waste of their time e) why bother? f) all of the above g) other Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-20 18:21 +0000 |
| Message-ID | <2017Jan20.192158@mips.complang.tuwien.ac.at> |
| In reply to | #54191 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>On Thu, 19 Jan 2017 15:28:36 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Why would anybody use Forth to implement a C-like language?
>
>How did you intend for this statement to be understood?
>
>a) C is so bad compared to Forth that no Forth programmer would do this
>b) C is too complex to parse with Forth
>c) only and idiot would attempt this
>d) someone could do this, but it'd be a complete waste of their time
>e) why bother?
>f) all of the above
>g) other
Mostly e). People who are interested in C-like languages tend not to
program in Forth (they want to program in a C-like language, so Forth
does not look very attractive to them), and people who program in
Forth tend not to be interested in implementing C-like languages (they
like Forth, why would they invest time in implementing a C-like
language).
That being said, if somebody wants to implement a C-like language in
Forth, we have good tools for that, and have had for a while. E.g.,
the parser generator Gray has been available sind 1989, and Brad
Rodriguez' BNF parser is of similar age. Both are better suited for
implementing a C-like language than recognizers (which is not hard,
because recognizers provide exactly 0 support for implementing a
C-like language).
Some people may have the fear that recognizers will be used to
implement C syntax like 0xff. They can indeed be used to do that, but
why would one fear that? Nobody is forcing you to use this syntax or
the appropriate recognizer. Also, a number of Forth systems recognize
this syntax already anyway. As a purist, go check the Forth systems
you have right away, and delete all those that support 0xff (don't
forget to check if some have it as a loadable option).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-20 03:52 -0600 |
| Message-ID | <JoCdnSdLXctcQBzFnZ2dnUU7-cmdnZ2d@supernews.com> |
| In reply to | #54171 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > My guess is that many system implementors react negatively to > recognizers because a part of their business model is to provide > enhancements like recognizing date syntax to customers as a service. > If the customers or a third party can then do it themselves through > a standardized interface, that may reduce revenue. Haha, brilliant! Yes, that must be it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-20 06:58 -0800 |
| Message-ID | <4bc8a74f-5f38-408b-acb2-9e642ea69796@googlegroups.com> |
| In reply to | #54198 |
пятница, 20 января 2017 г., 12:52:06 UTC+3 пользователь Andrew Haley написал: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > > My guess is that many system implementors react negatively to > > recognizers because a part of their business model is to provide > > enhancements like recognizing date syntax to customers as a service. > > If the customers or a third party can then do it themselves through > > a standardized interface, that may reduce revenue. > > Haha, brilliant! Yes, that must be it. OMG! I met this long time ago. This is very tricky position 'big companies are bad and prevents Forth distribution because they afraid to lost their market'. One can hide behind this illusion forever. So you thinks recognizers are extremely effective and implementers just afraid to provide so smart feature? Because this can made them useless? I really need to send a link of your message to a couple of colleagues :)
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-20 12:57 -0800 |
| Message-ID | <o5ttg0$coc$1@dont-email.me> |
| In reply to | #54204 |
On 1/20/2017 06:58, Ilya Tarasov wrote: > пятница, 20 января 2017 г., 12:52:06 UTC+3 пользователь Andrew Haley > написал: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> >>> My guess is that many system implementors react negatively to >>> recognizers because a part of their business model is to provide >>> enhancements like recognizing date syntax to customers as a >>> service. If the customers or a third party can then do it >>> themselves through a standardized interface, that may reduce >>> revenue. >> >> Haha, brilliant! Yes, that must be it. > > OMG! I met this long time ago. This is very tricky position 'big > companies are bad and prevents Forth distribution because they afraid > to lost their market'. One can hide behind this illusion forever. So > you thinks recognizers are extremely effective and implementers just > afraid to provide so smart feature? Because this can made them > useless? I really need to send a link of your message to a couple of > colleagues :) > While Anton may be entirely, partly or not serious at all, I can assure you that Andrew does not mean what he wrote. Quite the opposite. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-20 16:31 -0800 |
| Message-ID | <41e73228-e1a2-4f0f-baae-e56b2f418381@googlegroups.com> |
| In reply to | #54210 |
пятница, 20 января 2017 г., 23:57:08 UTC+3 пользователь Alex написал: > On 1/20/2017 06:58, Ilya Tarasov wrote: > > пятница, 20 января 2017 г., 12:52:06 UTC+3 пользователь Andrew Haley > > написал: > >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> > >>> My guess is that many system implementors react negatively to > >>> recognizers because a part of their business model is to provide > >>> enhancements like recognizing date syntax to customers as a > >>> service. If the customers or a third party can then do it > >>> themselves through a standardized interface, that may reduce > >>> revenue. > >> > >> Haha, brilliant! Yes, that must be it. > > > > OMG! I met this long time ago. This is very tricky position 'big > > companies are bad and prevents Forth distribution because they afraid > > to lost their market'. One can hide behind this illusion forever. So > > you thinks recognizers are extremely effective and implementers just > > afraid to provide so smart feature? Because this can made them > > useless? I really need to send a link of your message to a couple of > > colleagues :) > > > > While Anton may be entirely, partly or not serious at all, I can assure > you that Andrew does not mean what he wrote. Quite the opposite. But this is a chance to tell something about really wrong position :) No matter how serious he is.
[toc] | [prev] | [next] | [standalone]
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web