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 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-14 11:51 -0800 |
| Message-ID | <87pojpxvvr.fsf@nightsong.com> |
| In reply to | #54002 |
Alex <alex@rivadpm.com> writes: > The benefit of supporting outer locals with a lifetime that's limited > to the execution lifetime of the containing word is small to none. What? No that's called a downward funarg and it's useful. Whether it's useful enough to be worth complicating Forth implementations is debatable, but it's useful. In languages that's support it, it's used frequently.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-14 15:06 -0800 |
| Message-ID | <335385af-9338-4cd7-8074-4bde0e26f0bd@googlegroups.com> |
| In reply to | #54010 |
On Saturday, January 14, 2017 at 12:51:54 PM UTC-7, Paul Rubin wrote:
> Alex <alex@rivadpm.com> writes:
> > The benefit of supporting outer locals with a lifetime that's limited
> > to the execution lifetime of the containing word is small to none.
>
> What? No that's called a downward funarg and it's useful. Whether it's
> useful enough to be worth complicating Forth implementations is
> debatable, but it's useful. In languages that's support it, it's used
> frequently.
I like the term "downward funarg" --- I might as well use common terms --- it is not like I invented this stuff.
I messed up the code. Here is a fixed version:
0
w field pt.x
w field pt.y
constant pt
: init-pt local{ x y node -- node }
x node pt.x !
y node pt.y !
;
: new-pt ( x y -- )
pt alloc
init-pt ;
chain
w field snake.pt
constant snake
: init-snake local{ pt node -- }
pt node snake.pt !
;
: new-snake ( pt -- )
snake alloc
init-snake ;
: draw-segment ( pt1 pt2 color -- )
... ; \ this code is going to be non-standard
: draw-snake local{ snake color -- }
snake @ ptr!
ptr@ not if exit then
head drop \ PTR@ is now the 1st node
ptr@ snake.pt @ \ -- first
rite if \ PTR@ is now the 2nd node
{ ptr@ snake.pt @ tuck color @ draw-segment } |full-rite
then
drop ;
My locals SNAKE and COLOR provide an address in Straight Forth so they need a @ after them to get the value.
One of the worst things about ANS-Forth is that it is screwing up my mind. In ANS-Forth we have pointless redundancy, such as VALUE and VARIABLE which do pretty much the same thing, but in a different way. I hate VALUE and TO and ignore them completely, but locals are stupidly made to be like VALUE rather than VARIABLE and so I have to switch over to the different way for locals. This is screwing up my mind! This is what caused me to forget that SNAKE and COLOR needed a @ after them in the above code.
The best thing that can happen to Forth is that ANS-Forth should be forgotten completely --- it is all idiocy --- it is screwing up people's minds!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-15 14:54 +0000 |
| Message-ID | <2017Jan15.155430@mips.complang.tuwien.ac.at> |
| In reply to | #54002 |
Alex <alex@rivadpm.com> writes:
>The benefit of
>supporting outer locals with a lifetime that's limited to the execution
>lifetime of the containing word is small to none.
As it happens, the FIND-NAME-IN implementation based on
TRAVERSE-WORDLIST is an example where it would be useful. My original
code (where I worked around the absence of quotations and access to
outer locals) is:
\ replace COMPARE with a case-insensitive variant for mainstream systems
: fni-helper ( c-addr u nt1 nt -- c-addr u nt f )
>r drop 2dup r@ name>string compare r> swap ;
: find-name-in ( c-addr u wid -- nt | 0 )
0 ['] fni-helper rot traverse-wordlist ( c-addr u nt )
>r r@ name>string compare 0= r> and ;
Using a quotation instead of an external word, this becomes:
: find-name-in ( c-addr u wid -- nt | 0 )
0 [: >r drop 2dup r@ name>string compare r> swap ;] rot traverse-wordlist
( c-addr u nt )
>r r@ name>string compare 0= r> and ;
Using access to outer locals, this becomes:
: find-name-in ( c-addr u wid -- nt | 0 )
0 {: nt :}
[: to nt nt name>string 2over compare ;] swap traverse-wordlist
nt name>string compare 0= nt and ;
Neither of these versions works on empty wordlists, so let's fix that:
: find-name-in ( c-addr u wid -- nt | 0 )
0 {: nt :}
[: to nt nt name>string 2over compare dup if 0 to nt then ;]
swap traverse-wordlist ( c-addr u ) 2drop nt ;
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-15 13:33 -0800 |
| Message-ID | <2a5de2c8-0496-45ef-b8f8-a2bd1e8e2695@googlegroups.com> |
| In reply to | #54026 |
On Sunday, January 15, 2017 at 8:13:21 AM UTC-7, Anton Ertl wrote:
> Neither of these versions works on empty wordlists, so let's fix that:
>
> : find-name-in ( c-addr u wid -- nt | 0 )
> 0 {: nt :}
> [: to nt nt name>string 2over compare dup if 0 to nt then ;]
> swap traverse-wordlist ( c-addr u ) 2drop nt ;
That is a bug in TRAVERSE-WORDLIST then.
All of my HOFs work on empty data-structures. This is not something that the user should have to explicitly test for --- this should be handled internally.
Every time that the subject of quotations and HOFs comes up, you guys trot out TRAVERSE-WORDLIST as your example of a HOF that you have. Is this the only HOF that you have ever written?
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-13 16:06 -0800 |
| Message-ID | <a4c6c1dd-e89c-4f7e-972d-18a38a432064@googlegroups.com> |
| In reply to | #53971 |
> Two decades. Would Ilya have the patience? I doubt it. For me, it requires two days (or two hours) to add a feature I want.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-14 00:25 +0000 |
| Message-ID | <o5br1t$p9r$2@dont-email.me> |
| In reply to | #53983 |
On 1/14/2017 00:06, Ilya Tarasov wrote: > >> Two decades. Would Ilya have the patience? I doubt it. > > For me, it requires two days (or two hours) to add a feature I want. > Is that also the expected lifespan? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-13 18:00 -0800 |
| Message-ID | <a8dcdc1e-a5e1-4fd9-9362-6890c3451cb2@googlegroups.com> |
| In reply to | #53986 |
> > For me, it requires two days (or two hours) to add a feature I want.
> >
>
> Is that also the expected lifespan?
If you really want to know - no, it is for years to use. I add in the core only features impossible to write in Forth or which requires a kind of hack. It includes OS-specific things, interpreter engine modifications, some assembler-accelerated words etc.
Compare three ways to draw a box.
: BOX // X1, Y1, X2, Y2, COLOR
4 PICK 4 PICK 4 PICK 7 PICK - 3 PICK HLINE
4 PICK 4 PICK 3 PICK 6 PICK - 3 PICK VLINE
4 PICK 2 PICK 4 PICK 7 PICK - 3 PICK HLINE
2 PICK 4 PICK 3 PICK 6 PICK - 3 PICK VLINE
DROP DROP DROP DROP DROP
;
100 150 200 180 0xFFFF BOX
: BOX // X1, Y1, X2, Y2, COLOR
// 4 3 2 1 0
FRAME{
ARG4 @ ARG3 @ ARG2 @ ARG4 @ - ARG0 @ HLINE
ARG4 @ ARG3 @ ARG1 @ ARG3 @ - ARG0 @ VLINE
ARG4 @ ARG1 @ ARG2 @ ARG4 @ - ARG0 @ HLINE
ARG2 @ ARG3 @ ARG1 @ ARG3 @ - ARG0 @ VLINE
}FRAME
;
300 150 400 180 0xFF00 BOX
: BOX
LOC[
QUAN X1 QUAN X2 QUAN Y1 QUAN Y2 QUAN COLOR
]LOC
TO COLOR TO Y2 TO X2 TO Y1 TO X1
X1 Y1 X2 X1 - COLOR HLINE
X1 Y1 Y2 Y1 - COLOR VLINE
X1 Y2 X2 X1 - COLOR HLINE
X2 Y1 Y2 Y1 - COLOR VLINE
;
500 150 600 180 0xFF0000 BOX
=====================================
Also, take a look on the code and find places with difference from the ANS
CREATE Point1 3 FLOATS ALLOT
CREATE Point2 3 FLOATS ALLOT
CREATE Point3 3 FLOATS ALLOT
CREATE Point4 3 FLOATS ALLOT
: SET3D // POINT, F: X, Y, Z --
DUP 2 -TH F!
DUP 1 -TH F!
F!
;
FLOAT NX
FLOAT NY
FLOAT NZ
: X+ NX F@ 10.0 F+ NX F! NX F@ 360.0 F> IF NX F@ 360.0 F- NX F! THEN ;
: X- NX F@ 10.0 F- NX F! NX F@ 0.0 F< IF NX F@ 360.0 F+ NX F! THEN ;
: Y+ NY F@ 10.0 F+ NY F! NY F@ 360.0 F> IF NY F@ 360.0 F- NY F! THEN ;
: Y- NY F@ 10.0 F- NY F! NY F@ 0.0 F< IF NY F@ 360.0 F+ NY F! THEN ;
: Z+ NZ F@ 10.0 F+ NZ F! NZ F@ 360.0 F> IF NZ F@ 360.0 F- NZ F! THEN ;
: Z- NZ F@ 10.0 F- NZ F! NZ F@ 0.0 F< IF NZ F@ 360.0 F+ NZ F! THEN ;
: MY_SCENE
0 0 500 500 glViewPort
GL_DEPTH_TEST glEnable
GL_DEPTH_BUFFER_BIT glClear
GL_LIGHTING glEnable
GL_LIGHT0 glEnable
GL_LIGHT1 glEnable
GL_COLOR_MATERIAL glEnable
GL_LINE_SMOOTH glEnable
0 0x7FFFFFFF 0 glColor3i
glPushMatrix
NX F@ ROTATEANGLE SF!
1.0 glX SF!
0.0 glY SF!
0.0 glZ SF!
3DROTATE
NY F@ ROTATEANGLE SF!
0.0 glX SF!
1.0 glY SF!
0.0 glZ SF!
3DROTATE
NZ F@ ROTATEANGLE SF!
0.0 glX SF!
0.0 glY SF!
1.0 glZ SF!
3DROTATE
-0.5 0.0 0.0 Point1 SET3D
0.5 0.0 0.0 Point2 SET3D
-0.5 0.0 0.5 Point3 SET3D
0.5 0.0 -0.5 Point4 SET3D
GL_LINES glBegin
Point1 glVertex3dv
Point2 glVertex3dv
glEnd
GL_LINES glBegin
Point3 glVertex3dv
Point4 glVertex3dv
glEnd
glPopMatrix
;
' MY_SCENE TO 3D
' X+ TO K_UP
' X- TO K_DOWN
' Y+ TO K_LEFT
' Y- TO K_RIGHT
' Z+ TO K_PGUP
' Z- TO K_PGDOWN
This is a base for 3D representation of modelling. I wonder how this maybe done without some changes to standard engine. I propose some additions before, but nobody interested. When tell me, why I must forget this kind of results, just because committee members don't need this?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-13 22:17 -0800 |
| Message-ID | <3c4db965-3e7f-4292-8c8f-f3e9c66ac3d8@googlegroups.com> |
| In reply to | #53989 |
On Friday, January 13, 2017 at 7:00:31 PM UTC-7, Ilya Tarasov wrote:
> : BOX
> LOC[
> QUAN X1 QUAN X2 QUAN Y1 QUAN Y2 QUAN COLOR
> ]LOC
> TO COLOR TO Y2 TO X2 TO Y1 TO X1
>
> X1 Y1 X2 X1 - COLOR HLINE
> X1 Y1 Y2 Y1 - COLOR VLINE
> X1 Y2 X2 X1 - COLOR HLINE
> X2 Y1 Y2 Y1 - COLOR VLINE
> ;
>
> 500 150 600 180 0xFF0000 BOX
Other than your different way to define locals, this could be done in ANS-Forth --- I am assuming that QUAN defines a single-precision integer --- your example would have not been able to be done in ANS-Forth if you had locals of different types than single-precision integers.
Anyway, I didn't like any of your ways to draw a box. This is how I would do it in Straight Forth (untested):
0
w field pt.x
w field pt.y
constant pt
: init-pt local{ x y node -- node }
x node pt.x !
y node pt.y !
;
: new-pt ( x y -- )
pt alloc
init-pt ;
chain
w field snake.pt
constant snake
: init-snake local{ pt node -- }
pt node snake.pt !
;
: new-snake ( pt -- )
snake alloc
init-snake ;
: draw-segment ( pt1 pt2 color -- )
... ; \ this code is going to be non-standard
: draw-snake local{ snake color -- }
snake ptr!
ptr@ not if exit then
head \ PTR@ is now the 1st node
ptr@ snake.pt @ \ -- first
rite if \ PTR@ is now the 2nd node
{ ptr@ snake.pt @ tuck color draw-segment } |full-rite
then
drop ;
I didn't like your VLINE and HLINE because you can't always know ahead of time that the line will be vertical or horizontal. What if your box gets rotated? It is better to have DRAW-SEGMENT and let it internally check if the line is vertical or horizontal and then special-case these for better efficiency (it can call your VLINE or HLINE as needed) --- DRAW-SEGMENT is more robust because it doesn't make any assumptions --- this is a better design.
I don't want to have data-types specific to shapes, such as BOX etc.. Instead, I would just have the SNAKE data-type that is a sequence of points linked by line segments. There can be a MAKE-BOX function that takes two points and builds a snake that is a box with those two points as diagonal corners. I will leave writing this as an exercise for the student.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-13 16:04 -0800 |
| Message-ID | <40a9432d-bab3-461d-bb1b-3341a3e00bf1@googlegroups.com> |
| In reply to | #53967 |
> Here's the right way to do it: first persuade people to use your > design, and only then think about standardization. With a decently > long time interval to allow any disadvantages to be revealed. Ok, let's start to persuade ME I need ANS :) > But of course we'll never get to find out what any of your ideas are, > so all of this is moot anyway. I'm not talking about how to add my Forth words to ANS. It is not a major achievement for me. I wrote here I have several success stories with Forth, its customization, Forth CPUs etc. When I see anyone who use Forth I'm trying to understand, is it the same vision, and, if not, is it principal mismatch between us. I think this is normal. If you think you only need to collect benefits, you are definitely wrong. First you need to accept there is other points of view and some may be correct (and even better than ANS). So if there are other Forth systems, other reasons to create them should exist. Compare your position with a hypotetical tribe, who claims a first wheel in history was invented at their land :) They are collecting together and issuing a worldwide standards for wheels... but wheel is so simple and many companies feel themselves absolutely free to create their own standards for internal use. Did you hear any rumors about wheel standard, issued by man who claim his grandgrand(*1000 times).....father made a first wheel? Is it actual now for a team who design a wheel for sportcar?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-13 15:08 -1000 |
| Message-ID | <77idnS1Pkae15-TFnZ2dnUU7-fHNnZ2d@supernews.com> |
| In reply to | #53982 |
On 1/13/17 2:04 PM, Ilya Tarasov wrote: >> Here's the right way to do it: first persuade people to use your >> design, and only then think about standardization. With a decently >> long time interval to allow any disadvantages to be revealed. > > Ok, let's start to persuade ME I need ANS :) It's up to you to decide you don't need it. If you feel you don't, why are you still posting about it? >> But of course we'll never get to find out what any of your ideas are, >> so all of this is moot anyway. > > I'm not talking about how to add my Forth words to ANS. Ok. What are you trying to achieve, then? Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-13 17:21 -0800 |
| Message-ID | <0217ac80-c47a-433b-b5d2-bfc799bb8ce6@googlegroups.com> |
| In reply to | #53987 |
On Friday, January 13, 2017 at 6:09:01 PM UTC-7, Elizabeth D. Rather wrote: > On 1/13/17 2:04 PM, Ilya Tarasov wrote: > > I'm not talking about how to add my Forth words to ANS. > > Ok. What are you trying to achieve, then? Ilya has given me some good ideas that I will incorporate into Straight Forth --- whether that was something he was trying to achieve, I don't know --- I find it worthwhile to talk to people who have Forth programming experience because they have ideas to contribute. Andrew Haley and Alex McDonald say that Ilya's success stories are meaningless --- they aren't meaningless to me --- I want to exchange ideas with people who have been successful at Forth. You have never posted any code on comp.lang.forth except what you copied directly out of the "Starting Forth" book --- Forth Inc. just keeps the corpse of Charles Moore's 1970s Forth work warm, but adds nothing of value --- you are not a Forth programmer and you are not worth talking to.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-14 11:26 +0000 |
| Message-ID | <o5d1ps$ici$1@dont-email.me> |
| In reply to | #53988 |
On 1/14/2017 01:21, hughaguilar96@gmail.com wrote: > On Friday, January 13, 2017 at 6:09:01 PM UTC-7, Elizabeth D. Rather > wrote: >> On 1/13/17 2:04 PM, Ilya Tarasov wrote: >>> I'm not talking about how to add my Forth words to ANS. >> >> Ok. What are you trying to achieve, then? > > Ilya has given me some good ideas that I will incorporate into > Straight Forth --- whether that was something he was trying to > achieve, I don't know --- I find it worthwhile to talk to people who > have Forth programming experience because they have ideas to > contribute. What good ideas have you got from Ilya? > > Andrew Haley and Alex McDonald say that Ilya's success stories are > meaningless --- they aren't meaningless to me --- I want to exchange > ideas with people who have been successful at Forth. > Making stuff up again. Meaningless isn't a synonym for irrelevant. My argument with Ilya is quite simple; he keeps saying that the standard (or any standard) doesn't matter, that he's been rejected when he has proposed changes, that it's interfering with getting the job done, but he's still here, banging away without any evidence beyond anecdotes. > You have never posted any code on comp.lang.forth except what you > copied directly out of the "Starting Forth" book --- Forth Inc. just > keeps the corpse of Charles Moore's 1970s Forth work warm, but adds > nothing of value --- you are not a Forth programmer and you are not > worth talking to. > Yet here you are, trying to get her attention. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-13 18:21 -0800 |
| Message-ID | <451a2217-3e17-481e-9a6b-4a43dfb151a6@googlegroups.com> |
| In reply to | #53987 |
> > Ok, let's start to persuade ME I need ANS :) > > It's up to you to decide you don't need it. If you feel you don't, why > are you still posting about it? I'm not posting about ANS content. I think there is a wrong way to develop Forth, because the whole idea is too simple to be limited so strong, as it appears in ANS. For a while, most of discussions are going to a single question - is it ANS-compatible or not? The only way to develop is claiming as 'propose this to a committee meeting'. Don't you think this is too arrogantly? > > I'm not talking about how to add my Forth words to ANS. > > Ok. What are you trying to achieve, then? I state this before. I'm sure this must be an equal abilities to share ideas and compare approaches, which show success, no matter how close it to ANS. Forth has too wide spectrum of applicability and many non-compatible implementation may exist independently, but authors still can share ideas. Even if I don't need a feature, or it is blocking some functions in my Forth, it is not a reason to discard. Maybe later I will use it in another implementation, so I may add it to my knowledge base. Also, relations with customers, project management, teaching materials etc are questions to discuss too. Programmers should feel themselves free to discuss many things, without a risk to be blamed they are Standard-haters.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-13 18:30 -0800 |
| Message-ID | <87tw92xtie.fsf@nightsong.com> |
| In reply to | #53991 |
Ilya Tarasov <ilya74.tarasov@gmail.com> writes: >> Ok. What are you trying to achieve, then? > I state this before. I'm sure this must be an equal abilities to share > ideas and compare approaches, which show success, no matter how close > it to ANS. I keep waiting to see examples comparing your approach vs. the ANS approach. If your way is better, that's great, I want to look closely. If it's only equally good, why not use ANS?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-13 22:20 -0800 |
| Message-ID | <6868c722-bde2-422b-8672-04632cc1d2f3@googlegroups.com> |
| In reply to | #53992 |
On Friday, January 13, 2017 at 7:00:31 PM UTC-7, Ilya Tarasov wrote:
> : BOX
> LOC[
> QUAN X1 QUAN X2 QUAN Y1 QUAN Y2 QUAN COLOR
> ]LOC
> TO COLOR TO Y2 TO X2 TO Y1 TO X1
>
> X1 Y1 X2 X1 - COLOR HLINE
> X1 Y1 Y2 Y1 - COLOR VLINE
> X1 Y2 X2 X1 - COLOR HLINE
> X2 Y1 Y2 Y1 - COLOR VLINE
> ;
>
> 500 150 600 180 0xFF0000 BOX
Other than your different way to define locals, this could be done in ANS-Forth --- I am assuming that QUAN defines a single-precision integer --- your example would have not been able to be done in ANS-Forth if you had locals of different types than single-precision integers.
Anyway, I didn't like any of your ways to draw a box. This is how I would do it in Straight Forth (untested):
0
w field pt.x
w field pt.y
constant pt
: init-pt local{ x y node -- node }
x node pt.x !
y node pt.y !
;
: new-pt ( x y -- )
pt alloc
init-pt ;
chain
w field snake.pt
constant snake
: init-snake local{ pt node -- }
pt node snake.pt !
;
: new-snake ( pt -- )
snake alloc
init-snake ;
: draw-segment ( pt1 pt2 color -- )
... ; \ this code is going to be non-standard
: draw-snake local{ snake color -- }
snake ptr!
ptr@ not if exit then
head drop \ PTR@ is now the 1st node
ptr@ snake.pt @ \ -- first
rite if \ PTR@ is now the 2nd node
{ ptr@ snake.pt @ tuck color draw-segment } |full-rite
then
drop ;
I didn't like your VLINE and HLINE because you can't always know ahead of time that the line will be vertical or horizontal. What if your box gets rotated? It is better to have DRAW-SEGMENT and let it internally check if the line is vertical or horizontal and then special-case these for better efficiency (it can call your VLINE or HLINE as needed) --- DRAW-SEGMENT is more robust because it doesn't make any assumptions --- this is a better design.
I don't want to have data-types specific to shapes, such as BOX etc.. Instead, I would just have the SNAKE data-type that is a sequence of points linked by line segments. There can be a MAKE-BOX function that takes two points and builds a snake that is a box with those two points as diagonal corners. I will leave writing this as an exercise for the student.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-14 10:43 -0800 |
| Message-ID | <1586b419-039b-4d86-ab79-9b679f62b741@googlegroups.com> |
| In reply to | #53994 |
суббота, 14 января 2017 г., 9:20:11 UTC+3 пользователь hughag...@gmail.com написал: > On Friday, January 13, 2017 at 7:00:31 PM UTC-7, Ilya Tarasov wrote: > > : BOX > > LOC[ > > QUAN X1 QUAN X2 QUAN Y1 QUAN Y2 QUAN COLOR > > ]LOC > > TO COLOR TO Y2 TO X2 TO Y1 TO X1 > > > > X1 Y1 X2 X1 - COLOR HLINE > > X1 Y1 Y2 Y1 - COLOR VLINE > > X1 Y2 X2 X1 - COLOR HLINE > > X2 Y1 Y2 Y1 - COLOR VLINE > > ; > > > > 500 150 600 180 0xFF0000 BOX > > Other than your different way to define locals, this could be done in ANS-Forth --- I am assuming that QUAN defines a single-precision integer --- your example would have not been able to be done in ANS-Forth if you had locals of different types than single-precision integers. This is not a special type of locals. Inside the block LOC[ ]LOC any code may be inserted. : MYWORD LOC[ VARIABLE X FLOAT Y : SQR DUP * ; \ yes, even this way ]LOC ; : NEWWORD ... This requires a pair of push/pop of CURRENT content at : and ; respectively. In normal case, it is useless, but when LOC[ switches Forth to interpreting mode, any text after this will be interpreted/compiled, and all variables, arrays or even words will be compiled inside a MYWORD. A linked list will be expanded until final ; will restore CURRENT value, so NEWWORD will point to MYWORD, not to the latest definition inside LOC[ ]LOC. A chain 'MYWORD - X - Y - SQR' is visible only while MYWORD definition is not completed. This code is static and local object of this kind are not created every time for recursive words. This is not important limitation for me and for a man who asks me for doing something with name visibility. > I didn't like your VLINE and HLINE because you can't always know ahead of time that the line will be vertical or horizontal. What if your box gets rotated? It is better to have DRAW-SEGMENT and let it internally check if the line is vertical or horizontal and then special-case these for better efficiency (it can call your VLINE or HLINE as needed) --- DRAW-SEGMENT is more robust because it doesn't make any assumptions --- this is a better design. You can take a look on Bresenham's line algorithm. A line for any pair of pixels can be drawn with it, but each iteration requires some calculations. Direct form for vertical and horizontal lines is recommended in the sources describing 2D graphics. Filling a screen will show the performance difference even for Core i7. Assembler-coded words, such as VLINE HLINE SPRITE etc allows to draw a fast 2D without special attention to optimization. > I don't want to have data-types specific to shapes, such as BOX etc.. I have no strict counterarguments here. This is an idea to have an ability to implement things by the most comfortable way. An example with BOX appears here some time ago, and earlier at fforum.winglion.ru It is for demonstrating ways to work with parameters on stack.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-14 15:47 -0800 |
| Message-ID | <5399a1f4-2c56-4272-9588-9544e7b661e2@googlegroups.com> |
| In reply to | #54009 |
On Saturday, January 14, 2017 at 11:43:03 AM UTC-7, Ilya Tarasov wrote: > суббота, 14 января 2017 г., 9:20:11 UTC+3 пользователь hughag...@gmail.com написал: > > On Friday, January 13, 2017 at 7:00:31 PM UTC-7, Ilya Tarasov wrote: > > > : BOX > > > LOC[ > > > QUAN X1 QUAN X2 QUAN Y1 QUAN Y2 QUAN COLOR > > > ]LOC > > > TO COLOR TO Y2 TO X2 TO Y1 TO X1 > > > > > > X1 Y1 X2 X1 - COLOR HLINE > > > X1 Y1 Y2 Y1 - COLOR VLINE > > > X1 Y2 X2 X1 - COLOR HLINE > > > X2 Y1 Y2 Y1 - COLOR VLINE > > > ; > > > > > > 500 150 600 180 0xFF0000 BOX > > > > Other than your different way to define locals, this could be done in ANS-Forth --- I am assuming that QUAN defines a single-precision integer --- your example would have not been able to be done in ANS-Forth if you had locals of different types than single-precision integers. > > This is not a special type of locals. Inside the block LOC[ ]LOC any code may be inserted. > > : MYWORD > LOC[ > VARIABLE X > FLOAT Y > : SQR DUP * ; \ yes, even this way > ]LOC > ; > > : NEWWORD ... > > This requires a pair of push/pop of CURRENT content at : and ; respectively. In normal case, it is useless, but when LOC[ switches Forth to interpreting mode, any text after this will be interpreted/compiled, and all variables, arrays or even words will be compiled inside a MYWORD. A linked list will be expanded until final ; will restore CURRENT value, so NEWWORD will point to MYWORD, not to the latest definition inside LOC[ ]LOC. A chain 'MYWORD - X - Y - SQR' is visible only while MYWORD definition is not completed. > > This code is static and local object of this kind are not created every time for recursive words. This is not important limitation for me and for a man who asks me for doing something with name visibility. This is an interesting idea. I will give some thought to it. > > I didn't like your VLINE and HLINE because you can't always know ahead of time that the line will be vertical or horizontal. What if your box gets rotated? It is better to have DRAW-SEGMENT and let it internally check if the line is vertical or horizontal and then special-case these for better efficiency (it can call your VLINE or HLINE as needed) --- DRAW-SEGMENT is more robust because it doesn't make any assumptions --- this is a better design. > > You can take a look on Bresenham's line algorithm. A line for any pair of pixels can be drawn with it, but each iteration requires some calculations. Direct form for vertical and horizontal lines is recommended in the sources describing 2D graphics. Filling a screen will show the performance difference even for Core i7. Assembler-coded words, such as VLINE HLINE SPRITE etc allows to draw a fast 2D without special attention to optimization. I don't think there is any performance difference. It is trivial to check if the Y values for the two points are the same, in which case HLINE can be used, or the X values for the two points are the same, in which case VLINE can be used. The question is whether I want to standardize graphics or not. Maybe I will. Straight Forth is for desktop computers, and they all support graphics. In this case, DRAW-SEGMENT and a lot of other graphics words will become part of Straight Forth, most likely as an optional extension. > > I don't want to have data-types specific to shapes, such as BOX etc.. > > I have no strict counterarguments here. This is an idea to have an ability to implement things by the most comfortable way. An example with BOX appears here some time ago, and earlier at fforum.winglion.ru It is for demonstrating ways to work with parameters on stack. Well, I don't like to work with a lot of parameters on the stack. I prefer to hold data in structs and chains.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-14 17:30 -0800 |
| Message-ID | <70fda27f-dec5-4951-a4fd-5694d3f80068@googlegroups.com> |
| In reply to | #54015 |
> > This code is static and local object of this kind are not created every time for recursive words. This is not important limitation for me and for a man who asks me for doing something with name visibility.
>
> This is an interesting idea. I will give some thought to it.
There are some notes:
1. A JMP code must be used to skip local definitions (mark at LOC[, resolve at ]LOC )
2. Nesting is allowed without any efforts:
: MYWORD
LOC[
: nested
LOC[
: deeply_nested ;
]LOC
;
]LOC
> I don't think there is any performance difference. It is trivial to check if the Y values for the two points are the same, in which case HLINE can be used, or the X values for the two points are the same, in which case VLINE can be used.
There is no difference between HLINE and VLINE, but significant between them and DRAW-SEGMENT.
> The question is whether I want to standardize graphics or not. Maybe I will. Straight Forth is for desktop computers, and they all support graphics. In this case, DRAW-SEGMENT and a lot of other graphics words will become part of Straight Forth, most likely as an optional extension.
All of these may be iplemented in Forth based on the single PIXEL word (for my forths)
PIXEL ( x, y, color -- )
I define other words in Assembler for acceleration mainly. Screen redrawing is visible otherwise.
> Well, I don't like to work with a lot of parameters on the stack. I prefer to hold data in structs and chains.
Exactly, stack is not a magic feature, but just a forced solution to avoid syntax analyze and expression tree building. Parameters swapping and moving should be minimized as possible.
We are experimentig with STRUCT word with the next use case:
STRUCT POINT
CELL X
CELL Y
END-STRUCT
POINT p1
10 p1.X ! 20 p1.Y !
So, STRUCT is creating word, but different than CREATE, because must define another creating words. This is a code I want to write, but I don't like our current results. Dedicated arrays and special rules for processing is not what I want.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-14 18:16 -0800 |
| Message-ID | <a3ab5334-905a-4cf4-b756-2723273dd3a3@googlegroups.com> |
| In reply to | #54017 |
On Saturday, January 14, 2017 at 6:30:39 PM UTC-7, Ilya Tarasov wrote:
> > > This code is static and local object of this kind are not created every time for recursive words. This is not important limitation for me and for a man who asks me for doing something with name visibility.
> >
> > This is an interesting idea. I will give some thought to it.
>
> There are some notes:
> 1. A JMP code must be used to skip local definitions (mark at LOC[, resolve at ]LOC )
> 2. Nesting is allowed without any efforts:
>
> : MYWORD
> LOC[
> : nested
> LOC[
> : deeply_nested ;
> ]LOC
> ;
> ]LOC
An advantage here is that you get quotations that can access the parent function's locals (not actually locals, but globals) without the restrictions of my rquotations. My restrictions aren't onerous though, so this isn't a big advantage.
Another advantage is that you get locals (actually globals) of any type you want --- double-precision integers, floats, etc. --- you don't get this with rquotations. In Straight Forth however you do get this because the locals are big enough (128-bit) to hold any type (single-precision fixed, double-precision fixed, bfi, ratio, or float).
The major disadvantage is the lack of reentrancy, which you already mentioned. Another disadvantage is that the source-code is bloated and complicated for little or no benefit.
I'm dubious of your method. It is intriguing though --- I am glad that you mentioned it --- it gives me something to think about, and I haven't totally dismissed the idea yet.
I had a similar method in my eZ80 Forth (which never got off the ground, really) --- on that processor, indexed addressing is not efficient, so direct access to globals would have improved efficiency considerably (a moot point now, as the eZ80 is obsolete).
> > I don't think there is any performance difference. It is trivial to check if the Y values for the two points are the same, in which case HLINE can be used, or the X values for the two points are the same, in which case VLINE can be used.
>
> There is no difference between HLINE and VLINE, but significant between them and DRAW-SEGMENT.
You are still not understanding that DRAW-SEGMENT can call HLINE or VLINE internally when this works, and checking to see if this works is both trivial and fast.
All I'm saying is that HLINE and VLINE shouldn't be exposed to the user because this is complication that he doesn't need to worry about --- this complication should be hidden inside of DRAW-SEGMENT --- we want to make the user's job easy and uncomplicated!
> > The question is whether I want to standardize graphics or not. Maybe I will. Straight Forth is for desktop computers, and they all support graphics. In this case, DRAW-SEGMENT and a lot of other graphics words will become part of Straight Forth, most likely as an optional extension.
>
> All of these may be iplemented in Forth based on the single PIXEL word (for my forths)
>
> PIXEL ( x, y, color -- )
>
> I define other words in Assembler for acceleration mainly. Screen redrawing is visible otherwise.
If I do provide graphics as an extension to Straight Forth, I will likely just use Cairo and write wrappers around those C functions --- I don't want to write all of this myself --- this is a subject that I don't want to become an expert on.
If you already are an expert on graphics though, you could volunteer to write the graphics extension and do it mostly in assembly-language for speed. There is a lot of work involved in putting together Straight Forth --- I don't want to do all the work myself --- a lot of this, such as graphics, I don't have any expertise on anyway.
> > Well, I don't like to work with a lot of parameters on the stack. I prefer to hold data in structs and chains.
>
> Exactly, stack is not a magic feature, but just a forced solution to avoid syntax analyze and expression tree building. Parameters swapping and moving should be minimized as possible.
>
> We are experimentig with STRUCT word with the next use case:
>
> STRUCT POINT
> CELL X
> CELL Y
> END-STRUCT
>
> POINT p1
>
> 10 p1.X ! 20 p1.Y !
>
> So, STRUCT is creating word, but different than CREATE, because must define another creating words. This is a code I want to write, but I don't like our current results. Dedicated arrays and special rules for processing is not what I want.
You might be interested in my OOP stuff that I have added to the novice-package but haven't used (because I already wrote LIST.4TH ASSOCIATION.4TH etc. without it, and don't want to rewrite them). This is it:
\ ******
\ ****** This provides the IS-A function for classes.
\ ******
98769876 constant class-id \ used to make sure a class is actually a class; must be a distinctive value
0
w field .class-parent \ pointer to parent class \ must be first field
w field .class-size \ size of object
w field .class-id \ should always be CLASS-ID
constant class-struct
\ Every object has a W field in front which is a pointer to the class-struct for its class.
: check-class ( class -- )
.class-id @ class-id <> abort" *** tried to use a class that wasn't actually a class ***" ;
: create-nada ( -- ) \ create a class that has no parent
create
nil , \ .class-parent \ there is no parent
w , \ .class-size \ room for the object's pointer to its class-struct
class-id , \ .class-id \ this is for error-checking
does> ( -- )
true abort" *** it is illegal to make objects of class NADA ***" ;
create-nada nada \ NADA is the only class that has no parent
\ NADA is only available so it can be the parent of classes that have no parent.
\ It is not really a class that can be used as such.
' alloc constant heap-new \ give this to the class to get a new object in the heap
' concrete-alloc constant dict-new \ give this to the class to get a new object in the dictionary
: class-size ( class -- size )
.class-size @
dup 0< abort" *** CLASS-SIZE given a class that never had its .CLASS-SIZE field set by END-CLASS ***" ;
: size' ( -- size ) \ stream: class-name
' >body dup check-class
class-size ;
: object-size ( object -- size )
@ \ -- class
.class-size @ ; \ -- size
: class ( -- class offset ) \ stream: class-name parent-name
create here \ -- class
' >body \ -- class parent
dup check-class \ -- class parent \ make sure PARENT is a class
dup , \ -- class parent \ .class-parent
-1 , \ -- class parent \ .class-size \ this will get filled in by END-CLASS
class-id , \ -- class parent \ .class-id \ this is for error-checking
class-size \ -- class offset
does> ( 'alloc -- adr ) \ make a new object ( 'ALLOC is either HEAP-NEW or DICT-NEW)
>r \ 'alloc -- \ r: -- class
r@ class-size swap execute \ -- object
dup r@ class-size erase \ zero out the object
r> over ! ; \ first field of object is pointer to class
: end-class ( class offset -- )
over check-class \ make sure CLASS is a class
swap .class-size ! ;
char & comment \ this was an attempt at a METHOD similar to what is in Mini-OOF
\ This is commented out because it is too inefficient.
\ Just use the obvious technique as demonstrated in the example code later on (the TEXT.SHOW method).
67896789 constant method-id \ used to make sure a method is actually a method; must be a distinctive value
0
w field .method-offset
w field .method-id
constant method-struct
: method ( offset -- new-offset ) \ like FIELD except only for pointers to functions
create
dup , w + \ -- new-offset \ .method-offset
method-id , \ -- new-offset \ .method-id
does> ( object base-adr -- )
.method-offset @ \ -- object field-offset
over + perform ;
: <set-method> ( xt object 'method -- )
>body
dup .method-id @ method-id <> abort" *** <SET-METHOD> given a method that wasn't actually a method ***"
.method-offset @ + ! ;
: set-method ( xt object -- ) \ stream: method-name
' <set-method> ;
: [set-method] ( xt object -- ) \ stream: method-name
postpone ['] postpone <set-method> ;
immediate
\ METHOD is like FIELD in that it is used to define a field. It doesn't take a field-size but assumes one cell.
\ The method, when executed, will EXECUTE whatever is stored in that field (unlike a field that provides the address).
\ [SET-METHOD] is used in constructors to set the method to a particular xt (the user doesn't have direct access to the offset).
&
: <<is-a>> ( object target -- flag )
over check-class over check-class
= ;
: <is-a> ( object 'target -- flag )
swap @ swap >body <<is-a>> ;
: is-a ( object -- flag ) \ stream: target-class-name
' <is-a> ;
: [is-a] ( object -- flag ) \ stream: target-class-name
postpone ['] postpone <is-a> ;
immediate
: <<is-child-of>> ( ancestor class -- flag )
over check-class over check-class
begin
2dup = if 2drop true exit then
@ \ -- ancestor parent \ .class-parent is first field
dup 0= if 2drop false exit then
again ;
: <is-child-of> ( object 'ancestor )
>body swap @ <<is-child-of>> ;
: is-child-of ( object -- flag ) \ stream: ancestor-class-name
' <is-child-of> ;
: [is-child-of] ( object -- flag ) \ stream: ancestor-class-name
postpone ['] postpone <is-child-of> ;
immediate
\ IS-CHILD-OF tests if the object has ANCESTOR as an ancestor, meaning that it can use ANCESTOR's methods.
: <is-parent-of> ( object 'child )
>body swap @ swap <<is-child-of>> ;
: is-parent-of ( object -- flag ) \ stream: child-class-name
' <is-parent-of> ;
: [is-parent-of] ( object -- flag ) \ stream: child-class-name
postpone ['] postpone <is-parent-of> ;
immediate
\ IS-PARENT-OF tests if the object has CHILD as a child, meaning that it can be upgraded to be a CHILD.
: <become> ( object 'class -- new-object )
>body >r \ -- object \ r: -- class
r@ class-size realloc \ -- new-object
r> over ! ; \ -- new-object \ class is object's first field
\ <BECOME> converts an object into a new class.
\ The new class must either be an ancestor or a child of the object's class.
\ Use IS-CHILD-OF to find out if the object is a child of the new class (can be downgraded to the parent class).
\ Use IS-PARENT-OF to find out if the object is a parent of the new-class (can be upgraded to the child class).
: become ( object -- new-object ) \ stream: class-name
' <become> ;
: [become] ( object -- new-object ) \ stream: class-name
postpone ['] postpone <become> ;
immediate
char & comment \ this is a demonstration of a simple usage
class slnk nada
w field slnk.fore
end-class
: slnk.init ( node -- node )
nil over slnk.fore ! ;
: <slnk.kill> ( node -- )
drop ;
: slnk.each ( head rq -- ) \ rq: i*x node -- j*x
{ rq | next -- }
begin ?dup while \ -- node
dup slnk.fore @ to next
rq rex
next repeat ;
: slnk.tail ( head -- node )
nil swap begin dup while \ -- prev node
nip dup slnk.fore @ repeat drop ;
: slnk.link ( 1stHead 2ndHead -- NewHead ) \ makes one list
over 0= if nip exit then
dup 0= if drop exit then
over slnk.tail slnk.fore ! ;
class text slnk
w field text.adr
w field text.cnt
w field 'text.show
end-class
: text.show ( node -- )
dup 'text.show perform ;
: <text.show> ( node -- )
>r
cr r@ text.adr @ r@ text.cnt @ type
rdrop ;
: text.init ( adr cnt node -- node ) \ if adr:cnt came from $> then it is on the heap already
slnk.init >r
r@ text.cnt !
r@ text.adr !
['] <text.show> r@ 'text.show !
r> ;
: text.new ( adr cnt -- node )
heap-new text
text.init ;
: <text.kill> ( node -- ) \ assumes that the string was made with ALLOC or CONCRETE-ALLOC
dup <slnk.kill>
dup text.adr @ dealloc
drop ;
: text.kill ( node -- )
dup <text.kill>
dealloc ;
: text.show-all ( head -- )
['] text.show slnk.each ;
&
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-15 13:53 -0800 |
| Message-ID | <92cbc21b-b0cd-4ba6-9b10-48787a8060a4@googlegroups.com> |
| In reply to | #54018 |
> The major disadvantage is the lack of reentrancy, which you already mentioned. Another disadvantage is that the source-code is bloated and complicated for little or no benefit. No reentrancy is a predicted property. Note, a word with LOC[ don't become not-reentrant automatically. Only local definitions must not be used recursively. I'm rarely use recursion, and locals are good addition for me. I don't see major bloating here. Of course, LOC[ is not required or any word. More bloating code may appears with many stack manipulation words, when 5-10 parameters are required (this is poor architecture, but BOX is an example of word where 4 or more parameters is an objective requirement). So I hope code will be easier to read. > I'm dubious of your method. It is intriguing though --- I am glad that you mentioned it --- it gives me something to think about, and I haven't totally dismissed the idea yet. This is an example of Forth engine modification leading to obvious effect. More auxiliary structures may be implemented with existing words, such as another stack with >L L> words to hold parameters temporarily. This is application-level solution and no changes to main engine required. For LOC[ ]LOC, several base words as : ; must be slightly corrected. Just like LITERAL, which cannot be avoided without making it vectored. I think efforts must be applied to this kind of features. > You are still not understanding that DRAW-SEGMENT can call HLINE or VLINE internally when this works, and checking to see if this works is both trivial and fast. I note this in my previous posts :) Books and articles about 2D graphics recommends to check vertical and horizontal lines first. I did it explicitly, so VLINE and HLINE just words inside LINE (your DRAW-SEGMENT), but defined as Forth words, accessible from vocabulary. > All I'm saying is that HLINE and VLINE shouldn't be exposed to the user because this is complication that he doesn't need to worry about --- this complication should be hidden inside of DRAW-SEGMENT --- we want to make the user's job easy and uncomplicated! It is just my 'internal patterns'. Since I pay a lot of time to 2D graphics, I remember my internal words very good and apply this kind of minor optimization automatically. > If I do provide graphics as an extension to Straight Forth, I will likely just use Cairo and write wrappers around those C functions --- I don't want to write all of this myself --- this is a subject that I don't want to become an expert on. In general, I think graphics is a kind of feature must be studied separately. If Forth implementation strongly based on a graphics library, that library should prevail. > If you already are an expert on graphics though, you could volunteer to write the graphics extension and do it mostly in assembly-language for speed. There is a lot of work involved in putting together Straight Forth --- I don't want to do all the work myself --- a lot of this, such as graphics, I don't have any expertise on anyway. Graphics is not heavily depend on other Forth parts. Some vectors may be required for avoiding interference between our graphics and, for example, console output. Theoretically, PIXEL is enough to build all graphics support (including EMIT and other character output words). Vectoring is highly recommended. > You might be interested in my OOP stuff that I have added to the novice-package but haven't used (because I already wrote LIST.4TH ASSOCIATION.4TH etc. without it, and don't want to rewrite them). This is it: Yes, this is another example of features, enabled with little addition to core. As I understand, memory allocation must be built-in or at least emulated.
[toc] | [prev] | [next] | [standalone]
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web