Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42092 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2015-09-20 08:45 +0000 |
| Last post | 2015-11-09 13:21 -0800 |
| Articles | 20 on this page of 191 — 29 participants |
Back to article view | Back to comp.lang.forth
EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-20 08:45 +0000
Re: EuroForth 2015 paper deadline approaching Matthias Trute <matthias.trute@gmail.com> - 2015-09-20 06:34 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-21 20:11 +0200
Re: EuroForth 2015 paper deadline approaching Matthias Trute <matthias.trute@gmail.com> - 2015-09-23 11:29 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-23 21:03 +0200
Re: EuroForth 2015 paper deadline approaching Matthias Trute <matthias.trute@gmail.com> - 2015-09-27 03:02 -0700
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-09-21 01:13 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-21 09:26 +0000
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-03 03:46 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-03 22:56 -0700
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-04 02:44 -0400
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-04 01:14 -0700
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-04 05:08 -0400
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-04 04:06 -0700
Re: EuroForth 2015 paper deadline approaching Richard Owlett <rowlett@cloud85.net> - 2015-10-04 07:25 -0500
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-04 06:49 -0700
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-10-04 09:21 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-09 13:24 -0700
Re: EuroForth 2015 paper deadline approaching "WJ" <w_a_x_man@yahoo.com> - 2015-10-08 22:18 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 06:59 +0000
Re: EuroForth 2015 paper deadline approaching Mikael Nordman <oh2aun@gmail.com> - 2015-10-08 04:24 -0700
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-10-08 05:08 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 13:57 +0000
Re: EuroForth 2015 paper deadline approaching Mikael Nordman <oh2aun@gmail.com> - 2015-10-08 13:36 -0700
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-08 13:50 -1000
Re: EuroForth 2015 paper deadline approaching Jason Damisch <jasondamisch@yahoo.com> - 2015-10-10 12:10 -0700
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-10-08 18:10 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-10 14:10 +0000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-10 23:12 -0700
Re: EuroForth 2015 paper deadline approaching visualforth@rocketmail.com - 2015-10-12 10:18 -0700
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-12 14:02 -0400
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-12 08:03 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-12 14:58 -0700
Re: EuroForth 2015 paper deadline approaching Coos Haak <chforth@hccnet.nl> - 2015-10-13 01:25 +0200
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-12 17:38 -0700
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-12 16:39 -1000
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-10 19:12 -0400
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-08 07:31 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-17 22:44 +0200
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-17 21:47 -0700
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-18 01:51 -0400
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-17 20:26 -1000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-18 21:34 +0200
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-10-19 17:00 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-20 01:51 +0200
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-19 16:24 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-20 02:44 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-20 13:01 +0000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-20 22:59 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-20 23:57 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-21 10:58 -0700
Re: EuroForth 2015 paper deadline approaching krishna.myneni@ccreweb.org - 2015-11-11 14:06 -0800
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-11-11 14:48 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-11 14:59 -0800
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-11-12 05:28 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-12 18:18 -0800
Re: EuroForth 2015 paper deadline approaching krishna.myneni@ccreweb.org - 2015-11-11 15:12 -0800
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-11-12 05:35 -0800
Re: EuroForth 2015 paper deadline approaching krishna.myneni@ccreweb.org - 2015-11-12 06:24 -0800
Re: EuroForth 2015 paper deadline approaching Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-12 14:44 +0000
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-11 15:18 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-20 12:36 +0000
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-18 12:54 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-19 02:47 +0200
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-08 07:24 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 15:10 +0000
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-08 09:15 -0700
Re: EuroForth 2015 paper deadline approaching "WJ" <w_a_x_man@yahoo.com> - 2015-11-02 20:35 +0000
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-10-13 17:30 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-13 19:36 -0700
Re: EuroForth 2015 paper deadline approaching lehs <skydda.barnen@gmail.com> - 2015-10-13 23:54 -0700
Re: EuroForth 2015 paper deadline approaching lehs <skydda.barnen@gmail.com> - 2015-10-14 00:04 -0700
Re: EuroForth 2015 paper deadline approaching lehs <skydda.barnen@gmail.com> - 2015-10-14 00:09 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-14 09:45 +0000
Re: EuroForth 2015 paper deadline approaching Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-10-14 14:54 +0300
Re: EuroForth 2015 paper deadline approaching Brad Eckert <hwfwguy@gmail.com> - 2015-10-28 10:13 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-28 11:38 -0700
Re: EuroForth 2015 paper deadline approaching Brad Eckert <hwfwguy@gmail.com> - 2015-10-30 22:03 -0700
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-31 02:10 -0700
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-31 02:50 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 18:58 +0100
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-31 14:18 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 23:43 +0100
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-11-07 10:44 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-07 23:02 +0100
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-31 14:48 -0700
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 01:03 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 01:44 -0800
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 01:59 -0800
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 02:19 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-02 17:32 -0800
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 02:14 -0800
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 12:10 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-02 16:45 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 10:26 +0000
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 02:57 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 16:06 +0000
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 09:36 -0800
Re: EuroForth 2015 paper deadline approaching Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-02 21:18 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 11:56 +0000
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 18:16 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 10:53 +0000
16-bit Forth for Linux Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-20 11:13 +0100
Re: 16-bit Forth for Linux Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-20 15:08 +0000
Re: 16-bit Forth for Linux Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-20 20:11 +0100
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 11:10 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 12:43 -0800
Re: EuroForth 2015 paper deadline approaching Howerd <howerdo@yahoo.co.uk> - 2015-11-03 03:05 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-03 11:11 -0800
Re: EuroForth 2015 paper deadline approaching Howerd <howerdo@yahoo.co.uk> - 2015-11-03 03:07 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-03 11:15 -0800
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 12:18 -1000
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 12:07 -1000
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 15:41 -0800
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 20:27 -1000
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 11:00 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 11:28 +0000
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 12:18 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 17:03 +0000
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 19:29 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:47 +0000
Re: EuroForth 2015 paper deadline approaching "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-04 21:15 -0500
Re: EuroForth 2015 paper deadline approaching Coos Haak <chforth@hccnet.nl> - 2015-11-05 03:19 +0100
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-04 16:37 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-04 20:54 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-05 06:32 +0000
Re: EuroForth 2015 paper deadline approaching "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-04 21:17 -0500
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-04 16:44 -1000
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-05 01:24 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-05 14:50 +0000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-05 12:49 -0800
CMFORTH Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-06 08:43 +0100
Re: EuroForth 2015 paper deadline approaching Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-02 10:46 +0000
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 05:52 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 14:52 +0000
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 08:06 -0800
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 08:32 -0800
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 20:04 +0000
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 22:31 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-03 18:49 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 12:24 +0000
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 19:45 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:30 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 10:42 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:08 +0100
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-04 14:07 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:34 +0000
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-04 17:32 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-05 23:00 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-06 07:27 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-06 22:04 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-07 16:07 +0000
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-04 13:58 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 15:04 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:30 +0000
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-04 11:57 -0800
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-04 12:06 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-04 14:53 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-07 14:44 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-08 00:02 +0100
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-08 15:22 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-09 01:15 +0100
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-08 17:06 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-08 22:12 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-10 16:17 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-11 02:57 +0100
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-10 19:56 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-11 10:13 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-12 01:53 +0100
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-12 09:19 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-13 17:30 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-14 20:31 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-15 14:50 -0800
Re: EuroForth 2015 paper deadline approaching Alfred Singlestone <vitonis@gmail.com> - 2015-11-17 05:07 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-18 22:20 -0800
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-02 09:27 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 10:51 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-02 14:37 +0100
Re: EuroForth 2015 paper deadline approaching franck.bensusan@gmail.com - 2015-11-02 23:20 -0800
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 10:01 +0000
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-03 02:30 -0800
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 18:08 +0000
Re: EuroForth 2015 paper deadline approaching franck.bensusan@gmail.com - 2015-11-03 06:05 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 19:35 +0100
Re: EuroForth 2015 paper deadline approaching franck.bensusan@gmail.com - 2015-11-03 12:27 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:37 +0100
Re: EuroForth 2015 paper deadline approaching franck.bensusan@gmail.com - 2015-11-03 14:39 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:54 +0100
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-04 06:21 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-31 15:00 -0700
Re: EuroForth 2015 paper deadline approaching Brad Eckert <hwfwguy@gmail.com> - 2015-11-09 13:21 -0800
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-04 14:47 +0000 |
| Message-ID | <2015Nov4.154747@mips.complang.tuwien.ac.at> |
| In reply to | #43190 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Tue, 03 Nov 2015 17:03:26 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>There's plenty of usefulness in non-standard programs.
>>
>>Which is a red herring in the context of the present discussion, which
>>was about the shortcomings of the present standard.
>
>The three examples illustrate why being able to ' IF is useful.
Not at all. There is no need to be able to ' IF in order to SEE IF,
LOCATE IF, or HELP IF. E.g., in Gforth 0.7:
' if
:1: Cannot tick compile-only word (try COMP' ... DROP)
' >>>if<<<
Backtrace:
$7FC864B86AD0 throw
$7FC864B86E88 ticking-compile-only-error
$7FC864B87890 name?int
see if
: compile-only-error
-14 throw ;
latestxt
: IF
6394072 compile, >mark ;
latestxt
interpret/compile: IF ok
And if a standard program could ' IF, it would be no closer to SEEing,
LOCATEing, or HELPing, because there are no standard words for
decompiling, locating, of helping based on an xt.
>A starting point is to acknowledge that ' and friends are used for
>purposes other than EXECUTE and COMPILE,
Sure, they are also used for >BODY (but only for CREATEd words) in
standard programs.
> - your refusal to accept this is itself a weakness in the standard process.
I accept that you (VFX) uses the xt for other things. You refuse to
accept that other systems work differently.
> You are very fond
>of pointing out other people's mistakes - please consider being a bit
>more humble in accepting your own. My view of mistakes is that if you
>don't make any, you aren't working hard enough.
>
>You should also realise
I love being patronized.
>that the tools being discussed have existed
>in many Forth systems for 20-30 years and more. They have *always*
>been non-standard.
SEE has been standard at least since Forth-94. LOCATE and HELP have
not been standard. But what is your point in pointing that out?
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-11-04 21:15 -0500 |
| Message-ID | <op.x7lu79uwyfako5@localhost> |
| In reply to | #43235 |
On Wed, 04 Nov 2015 09:47:47 -0500, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > There is no need to be able to ' IF in order to SEE IF, > LOCATE IF, or HELP IF. E.g., in Gforth 0.7: > > ' if > :1: Cannot tick compile-only word (try COMP' ... DROP) > ' >>>if<<< > Backtrace: > $7FC864B86AD0 throw > $7FC864B86E88 ticking-compile-only-error > $7FC864B87890 name?int > > see if > : compile-only-error > -14 throw ; > latestxt > > : IF > 6394072 compile, >mark ; > latestxt > interpret/compile: IF ok > Sorry to intrude, but how does Gforth find the dictionary entry for IF from words SEE LOCATE or HELP without using ' (tick) or FIND or perhaps (FIND) ? ... What I'm asking is if the definitions for SEE LOCATE or HELP use the same mechanism as FIND or ' (tick) in Gforth or if they use an entirely different mechanism or a modified mechanism. Rod Pemberton -- When El Chapo is the most beloved man in Mexico and Trump is the most hated, it shows that Mexico is truly fouled up.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-11-05 03:19 +0100 |
| Message-ID | <1ge06zsplyr0d.1eyehxhkthle0.dlg@40tude.net> |
| In reply to | #43243 |
Op Wed, 04 Nov 2015 21:15:35 -0500 schreef Rod Pemberton: > On Wed, 04 Nov 2015 09:47:47 -0500, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> There is no need to be able to ' IF in order to SEE IF, >> LOCATE IF, or HELP IF. E.g., in Gforth 0.7: >> >> ' if >>:1: Cannot tick compile-only word (try COMP' ... DROP) >> ' >>>if<<< >> Backtrace: >> $7FC864B86AD0 throw >> $7FC864B86E88 ticking-compile-only-error >> $7FC864B87890 name?int >> >> see if >>: compile-only-error >> -14 throw ; >> latestxt >> >>: IF >> 6394072 compile, >mark ; >> latestxt >> interpret/compile: IF ok >> > > Sorry to intrude, but how does Gforth find the dictionary entry for > IF from words SEE LOCATE or HELP without using ' (tick) or FIND or > perhaps (FIND) ? ... > > What I'm asking is if the definitions for SEE LOCATE or HELP use > the same mechanism as FIND or ' (tick) in Gforth or if they use > an entirely different mechanism or a modified mechanism. > > > Rod Pemberton Just type ' if or see see in Gforth and all will be revealed. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-04 16:37 -1000 |
| Message-ID | <6O-dnVaLgYiaXKfLnZ2dnUU7-eWdnZ2d@supernews.com> |
| In reply to | #43243 |
On 11/4/15 4:15 PM, Rod Pemberton wrote: > On Wed, 04 Nov 2015 09:47:47 -0500, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: > >> There is no need to be able to ' IF in order to SEE IF, >> LOCATE IF, or HELP IF. E.g., in Gforth 0.7: >> >> ' if >> :1: Cannot tick compile-only word (try COMP' ... DROP) >> ' >>>if<<< >> Backtrace: >> $7FC864B86AD0 throw >> $7FC864B86E88 ticking-compile-only-error >> $7FC864B87890 name?int >> >> see if >> : compile-only-error >> -14 throw ; >> latestxt >> >> : IF >> 6394072 compile, >mark ; >> latestxt >> interpret/compile: IF ok >> > > Sorry to intrude, but how does Gforth find the dictionary entry for > IF from words SEE LOCATE or HELP without using ' (tick) or FIND or > perhaps (FIND) ? ... > > What I'm asking is if the definitions for SEE LOCATE or HELP use > the same mechanism as FIND or ' (tick) in Gforth or if they use > an entirely different mechanism or a modified mechanism. I don't know about gForth, yes, we do a FIND. All these words are in the system, where they can rely in knowing details of the implementation. The problem you're fussing about re ' IF isn't about finding the word in the dictionary, that's easy. The issue is the extent to which a standard should constrain implementations so that an outside program can expect a certain memory layout or behavior in the definition once found. For outside programs to be able to do these things means they must have knowledge of specific implementation details, rather than the prescribed semantics (behavior) of words when used as they are *intended* to be used, which is what is standardized today. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-04 20:54 -0800 |
| Message-ID | <2925cd76-0b44-48b1-8aef-8f676d974153@googlegroups.com> |
| In reply to | #43246 |
On Wednesday, November 4, 2015 at 7:38:00 PM UTC-7, Elizabeth D. Rather wrote: > On 11/4/15 4:15 PM, Rod Pemberton wrote: > > Sorry to intrude, but how does Gforth find the dictionary entry for > > IF from words SEE LOCATE or HELP without using ' (tick) or FIND or > > perhaps (FIND) ? ... > > > > What I'm asking is if the definitions for SEE LOCATE or HELP use > > the same mechanism as FIND or ' (tick) in Gforth or if they use > > an entirely different mechanism or a modified mechanism. > > I don't know about gForth, yes, we do a FIND. All these words are in the > system, where they can rely in knowing details of the implementation. > > The problem you're fussing about re ' IF isn't about finding the word in > the dictionary, that's easy. The issue is the extent to which a standard > should constrain implementations so that an outside program can expect a > certain memory layout or behavior in the definition once found. For > outside programs to be able to do these things means they must have > knowledge of specific implementation details, rather than the prescribed > semantics (behavior) of words when used as they are *intended* to be > used, which is what is standardized today. > > Cheers, > Elizabeth Elizabeth Rather is lying again! The issue was never that I wanted to have carnal knowledge about the dictionary header. The issue is that I wanted the xt when given to EXECUTE to have the same behavior as the word itself when executed. This is the thread: https://groups.google.com/forum/#!searchin/comp.lang.forth/bug$20in$20vfx/comp.lang.forth/oXXQAGDKP7w/iMLU1ExXOAIJ This is the code (VFX) that demonstrates the bug: : my-if [ ' if ] literal execute ; immediate : ttt ( flag -- ) my-if ." true" else ." false" then ; Err# -14 ERR: Attempt to interpret a compile only definition. -> : ttt ( flag -- ) my-if ." true" else ." false" then ; gForth also fails, but differently --- gForth crashes when IF is ticked. This is how my disambiguifiers fix the bug: : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : my-if [ ' if ] literal execute ; immediate : ttt ( flag -- ) my-if ." true" else ." false" then ; 1 ttt true 0 ttt false The disambiguifiers make all ANS-Forth systems behave the same way, despite the fact that they behaved in different ways previously and usually crashed, and the dismabiguifiers make the behavior conform to Forth-83 and every other Forth system ever written (this weird problem is only in ANS-Forth of all the Forth systems in existence). ANS-Forth was sabotaged to prevent the common Forth programmers from writing their own outer-interpreter, and this was done to prevent the common Forth programmers from writing cross-compilers --- Forth Inc. and MPE wanted to prevent ANS-Forth from being used to write cross-compilers because that is where they make most of their money. Ultimately, ANS-Forth is all about supporting the corporate compiler-vendors and hamstringing the Forth community. Cheers!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-05 06:32 +0000 |
| Message-ID | <2015Nov5.073221@mips.complang.tuwien.ac.at> |
| In reply to | #43243 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>On Wed, 04 Nov 2015 09:47:47 -0500, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>> There is no need to be able to ' IF in order to SEE IF,
>> LOCATE IF, or HELP IF. E.g., in Gforth 0.7:
>>
>> ' if
>> :1: Cannot tick compile-only word (try COMP' ... DROP)
>> ' >>>if<<<
>> Backtrace:
>> $7FC864B86AD0 throw
>> $7FC864B86E88 ticking-compile-only-error
>> $7FC864B87890 name?int
>>
>> see if
>> : compile-only-error
>> -14 throw ;
>> latestxt
>>
>> : IF
>> 6394072 compile, >mark ;
>> latestxt
>> interpret/compile: IF ok
>>
>
>Sorry to intrude, but how does Gforth find the dictionary entry for
>IF from words SEE LOCATE or HELP without using ' (tick) or FIND or
>perhaps (FIND) ? ...
SEE uses FIND-NAME, which provides the nt, from which you can access
everything there is to know about the word, while the xt returned by '
represents only the interpretation semantics (and if the word is
compile-only, like IF, it gives an error in Gforth 0.7).
LOCATE in the current development version is just an interface to
Emacs' find-tag functionality (which uses information in the file
TAGS), but if we put that information with the header, it would use
FIND-NAME, too.
>What I'm asking is if the definitions for SEE LOCATE or HELP use
>the same mechanism as FIND or ' (tick) in Gforth or if they use
>an entirely different mechanism or a modified mechanism.
FIND and ' also call FIND-NAME.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-11-04 21:17 -0500 |
| Message-ID | <op.x7lva7jjyfako5@localhost> |
| In reply to | #43190 |
On Tue, 03 Nov 2015 14:29:01 -0500, Stephen Pelc <stephen@mpeforth.com> wrote: > I have publicly stated before that it is useful to be able to tick > all words that have a header. I happen to like that ability, but I'm not a Forth programmer. It would also seem to be a historical trait of interpreted Forths that all of the words in the dictionary are exposed to the user. Is there any reason, other than SMUDGE and NONAME functionality, why a word shouldn't be ' tick-ed ? E.g., safety, security? Why shouldn't IF be ' tick-ed? It's XT can be COMPILE, or EXECUTEd or viewed. What harm does any of that do? So, I currently don't recognize a reason to _not_ allow the ' tick-ing IF. Sorry, those question probably should've been asked of Anton ... Rod Pemberton -- When El Chapo is the most beloved man in Mexico and Trump is the most hated, it shows that Mexico is truly fouled up.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-04 16:44 -1000 |
| Message-ID | <StqdnQzw2dwJX6fLnZ2dnUU7-fGdnZ2d@supernews.com> |
| In reply to | #43244 |
On 11/4/15 4:17 PM, Rod Pemberton wrote: > On Tue, 03 Nov 2015 14:29:01 -0500, Stephen Pelc <stephen@mpeforth.com> > wrote: > >> I have publicly stated before that it is useful to be able to tick >> all words that have a header. > > I happen to like that ability, but I'm not a Forth programmer. > > It would also seem to be a historical trait of interpreted Forths > that all of the words in the dictionary are exposed to the user. > > Is there any reason, other than SMUDGE and NONAME functionality, > why a word shouldn't be ' tick-ed ? E.g., safety, security? > Why shouldn't IF be ' tick-ed? It's XT can be COMPILE, or EXECUTEd > or viewed. What harm does any of that do? So, I currently don't > recognize a reason to _not_ allow the ' tick-ing IF. Sorry, those > question probably should've been asked of Anton ... The problem isn't with ticking the word, it's knowing what you've found and what you can do with it. If you have found the compiler directive (instead of the runtime code), and compile that, it won't do a branch when you execute the word, it'll try to compile something. But compiler directives might be in a different wordlist, and not findable when you aren't compiling, for example. Now, you tell me why it's so important to be able to handle a compiler directive this way? Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-05 01:24 -0800 |
| Message-ID | <719e7997-1c72-4d9d-b08b-69e3e1743ccb@googlegroups.com> |
| In reply to | #43244 |
On Thursday, 5 November 2015 02:17:10 UTC, Rod Pemberton wrote: > On Tue, 03 Nov 2015 14:29:01 -0500, Stephen Pelc <stephen@mpeforth.com> wrote: > > > I have publicly stated before that it is useful to be able to tick > > all words that have a header. > > I happen to like that ability, but I'm not a Forth programmer. > > It would also seem to be a historical trait of interpreted Forths > that all of the words in the dictionary are exposed to the user. > > Is there any reason, other than SMUDGE and NONAME functionality, > why a word shouldn't be ' tick-ed ? E.g., safety, security? > Why shouldn't IF be ' tick-ed? It's XT can be COMPILE, or EXECUTEd > or viewed. What harm does any of that do? So, I currently don't > recognize a reason to _not_ allow the ' tick-ing IF. Sorry, those > question probably should've been asked of Anton ... > > > Rod Pemberton > > > -- > When El Chapo is the most beloved man in Mexico and Trump is the most hated, > it shows that Mexico is truly fouled up. +1 Seems bonkers to me. Seems like certain developers have maneuvered themselves into a corner where IF can't be ticked, due to some design decision or design flaw, and they use the standard to justify it. I can see no reason at all why I shouldn't be able to do: : my-if ' if compile, ; immediate Or, on older systems: : my-if ' if , ; immediate I can see why the latter wouldn't work on native systems. Fair enough. But the former should work. What if I want to do: ' if 100 dump On my Forth 83 system I have no problem whatsoever doing that. Or ' if 100 >file" if.bin" to dump the memory to a file for viewing with a hex editor. Why can a "standard" system not do that?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-05 14:50 +0000 |
| Message-ID | <2015Nov5.155050@mips.complang.tuwien.ac.at> |
| In reply to | #43250 |
Mark Wills <markwills1970@gmail.com> writes:
>Seems bonkers to me. Seems like certain developers have maneuvered
>themselves into a corner where IF can't be ticked, due to some design
>decision or design flaw, and they use the standard to justify it.
Once upon a time there was a system called cmForth. It had a separate
compilation vocabulary that was searched first on compilation. Some
names (such as IF) were present only in the compilation wordlist, so
you could not use them interpretively, and you could not tick them (at
least not in interpret state). The Forth-94 committee wanted to allow
this implementation approach, and therefore introduced the concepts of
interpretation and compilation semantics, explicitly undefined the
interpretation semantics of IF, and specified that ticking words with
undefined interpretation semantics is ambiguous.
>I can see no reason at all why I shouldn't be able to do:
>
>: my-if ' if compile, ; immediate
I guess you mean
: my-if ['] if compile, ; immediate
If that is intended to have the same compilation semantics as IF, it
works on VFX, but not on SwiftForth and most traditional systems:
SwiftForth i386-Linux 3.4.8a 21-Jul-2013
: my-if ['] if compile, ; immediate ok
: bla my-if ." true" else ." false" then ; Control structure mismatch
Gforth 0.7 gives an error when you try to ' if in order to make you
aware that this usage is non-standard. It also tells you how you get
the xt that users of traditional systems expect:
: my-if ['] if compile, ; immediate
:1: Cannot tick compile-only word (try COMP' ... DROP)
: my-if ['] >>>if<<< compile, ; immediate
>What if I want to do:
>
>' if 100 dump
>
>On my Forth 83 system I have no problem whatsoever doing that.
>
>Or
>
>' if 100 >file" if.bin"
>
>to dump the memory to a file for viewing with a hex editor.
>Why can a "standard" system not do that?
A system can allow you to do that and can still be standard, but a
standard program cannot do that. It cannot really do that even for
words that you can tick, because the xt is not necessarily an address,
and if it is, you do not know that it can access the next 100 bytes,
and even if you can, there is no standard interpretation to the dump
you get, because the header structure is not standardized, nor the
code.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-05 12:49 -0800 |
| Message-ID | <78982faf-4b32-4957-8f85-927e5d4d4955@googlegroups.com> |
| In reply to | #43254 |
On Thursday, November 5, 2015 at 9:02:38 AM UTC-7, Anton Ertl wrote: > Mark Wills <markwills1970@gmail.com> writes: > >Seems bonkers to me. Seems like certain developers have maneuvered > >themselves into a corner where IF can't be ticked, due to some design > >decision or design flaw, and they use the standard to justify it. > > Once upon a time there was a system called cmForth. It had a separate > compilation vocabulary that was searched first on compilation. Some > names (such as IF) were present only in the compilation wordlist, so > you could not use them interpretively, and you could not tick them (at > least not in interpret state). The Forth-94 committee wanted to allow > this implementation approach, and therefore introduced the concepts of > interpretation and compilation semantics, explicitly undefined the > interpretation semantics of IF, and specified that ticking words with > undefined interpretation semantics is ambiguous. It wasn't necessary to give words "compilation semantics" and "interpretation semantics" and to make ticking IF illegal (gForth) or to make ticking IF provide a non-executable execution-token (VFX). ANS-Forth already had word-lists defined, so cmForth's use of word-lists was already pretty close to standard --- all you have to do is define colon's behavior to include changing the word-list search-order and you are there --- if you don't want to change colon's definition, then just make cmForth non-standard (cmForth is actually a better design than ANS-Forth though, from what I've read about it, so it would make more sense to learn from the master rather than exclude him). All this talk about how ANS-Forth had to be contorted to allow cmForth to be ANS-Forth compliant is nonsense anyway --- Charles Moore never asked for cmForth to be ANS-Forth compliant and he never supported ANS-Forth at all. > >What if I want to do: > > > >' if 100 dump > > > >On my Forth 83 system I have no problem whatsoever doing that. > > > >Or > > > >' if 100 >file" if.bin" > > > >to dump the memory to a file for viewing with a hex editor. > >Why can a "standard" system not do that? > > A system can allow you to do that and can still be standard, but a > standard program cannot do that. It cannot really do that even for > words that you can tick, because the xt is not necessarily an address, > and if it is, you do not know that it can access the next 100 bytes, > and even if you can, there is no standard interpretation to the dump > you get, because the header structure is not standardized, nor the > code. Anton Ertl is right about this --- we don't want to standardize the implementation, but we only want to standardize the behavior.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-06 08:43 +0100 |
| Subject | CMFORTH |
| Message-ID | <86lhabmv2c.fsf_-_@vps34351.public.cloudvps.com> |
| In reply to | #43256 |
Hugh wrote: > cmForth is actually a better design than ANS-Forth though, from what > I've read about it, so it would make more sense to learn from the > master rather than exclude him. Go ahead and learn from the source! https://github.com/ForthHub/cmFORTH Here is a version with the shadow blocks to the right of the code: https://raw.githubusercontent.com/ForthHub/cmFORTH/combined/cmforth.fth NC4016 architecture: https://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.html
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-11-02 10:46 +0000 |
| Message-ID | <n17eqd$sb3$1@dont-email.me> |
| In reply to | #43087 |
On 02/11/2015 09:03, Mark Wills wrote: > When ticking IF on a variety of systems leads to different behaviour > on all of them, we have a very very serious problem guys. Wake up > and smell the coffee. We CANNOT write (all but the most trivial) > code in ANS Forth and*guarantee* that it will run on another system. > That is a pity. As I've noted elsewhere that's an impossible goal given that most of the language is in optional wordsets, variable cell size etc. But if portability is wanted between Forth systems that implement the whole of the Forth-94/2012 standard then significant applications can and have been written. > The committee should be directing its efforts to > resolving that issue. It will mean that some system owners will need > to change their systems*at some point in the future*. So be it. > Man up. Make the tough decisions. It*will* be for the better if we > can get to a stage where we can write portable code more easily. > I don't disagree with that but note that being on a standards committee is a thankless task and requires a very thick skin. Also am reminded of a quote from a book on standard Pascal: "The sponsor is fed up with people who complain about the wording of the draft, and expect him or someone else to find a solution for them to criticise next time." I might be wrong but as I understand it anyone is able to join the Forth 20XX committee so, if you feel strongly about it why don't you. The drawback is that you have to attend the annual standards meeting which entails a substancial financial commitment that is bound to put most people off. Perhaps more frequent on-line meetings should be the norm. > There has been progress. Some great additions. Words such as COMPILE, > are a brilliant step in the right direction. > > We're actually not that far away - there are just some corner cases, > where, in the main, the wooly language of the standard permits > different behaviours. The contention appears because people don't > want to "break" their systems. I understand. So, set your sights > on a*NEW* Forth 2020 standard, the principle purpose of which shall > be to maximise the potential for portable code across different > systems. As I said above, don't just be a complaining critic but take a constructive part in the process. Hugh complains frequently about the standard but has the courage and drive to develop a new standard. If you don't want join the committee or support Hugh write a few RfDs addressing the problems you've encountered when trying to write portable Forth software but been thwarted by the 'wooly language of the standard'. Incidentally did you read and comment on the draft Forth 2012 standard before it was issued? -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-02 05:52 -0800 |
| Message-ID | <f51e1da0-694e-4946-8690-c69f3c8d11ad@googlegroups.com> |
| In reply to | #43099 |
On Monday, 2 November 2015 10:46:43 UTC, Gerry wrote: > I might be wrong but as I understand it anyone is able to join the Forth > 20XX committee so, if you feel strongly about it why don't you. The > drawback is that you have to attend the annual standards meeting which > entails a substancial financial commitment that is bound to put most > people off. Perhaps more frequent on-line meetings should be the norm. > I did seriously consider it this year. In the end I decided not to on cost grounds. As noted by Bernd, cost of attendance was very high this year, and, for me, being self-employed, it's a double whammy: A week spent at the Forth conference is a week that I cannot invoice to my current client, *in addition* to the costs of attendance and accommodation. It all added up to a very sizeable sum of money.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-02 14:52 +0000 |
| Message-ID | <2015Nov2.155218@mips.complang.tuwien.ac.at> |
| In reply to | #43087 |
Mark Wills <markwills1970@gmail.com> writes:
>Quotations and recognisers are cool, but IMO it is misguided for the
>standards committee to be debating whether or not to add them to the
>langauge. There are *much* more fundamental portability issues to be
>resolved before adding any new features at all. If I were chairman,
>my first effort would be to sit the committee down and try (note: try!)
>to get some consensus on a mission statement for then next, say, five
>years.
We had such sessions in the 2014 meeting; look for "Future Directions"
in the Notes <http://www.forth200x.org/meetings/2014-notes>.
>IMO, the committe should be concentrating on resolving the current
>crop of contentious portability issues before adding more features
>to the language that could potentially add yet more contentious
>portability issues.
Sometimes, it may be useful to add new features that then allow to
remove other features that are the reasons behind the contentious
portability issues.
In particular, once we have recognizers, we may be able to get rid of
things like S" and TO, and then we can get rid of non-default
non-immediate compilation semantics in the standard; if we manage to
get there, the differences between the behaviour of the systems will
be smaller, and it will hopefully be easier to find common ground.
Also, some issues really resolve over time; when I presented the
xchars idea in 2005, there was quite some opposition. If we had sat
down and tried to resolve it there and then, everybody would have dug
his trenches deep and maybe never come out of them. Giving people
some more time to think it over and discuss it with others avoided
that and eventually the idea was turned into a proposal and it was
accepted.
>The chair should lead. The chair should say "Look,
>these are the issues that people are complaining about.
And the commercial vendors will say something along the lines of: "My
customers are not complaining about them, and they are the only ones
that count." (the latter typically formulated as a slight on the
person who is bringing up the issue).
>When ticking IF on a variety of systems leads to different behaviour
>on all of them, we have a very very serious problem guys. Wake up
>and smell the coffee. We CANNOT write (all but the most trivial)
>code in ANS Forth and *guarantee* that it will run on another system.
Well, for this particular issue the solution is simple: Use Gforth.
You will notice right away that ' IF does not do what you intend it to
do.
There are other issues where it is harder to notice that you are not
writing a standard program, e.g., the 1 CHARS = 1 issue. You cannot
find out that you forgot a CHARS by testing your program.
>We're actually not that far away - there are just some corner cases,
>where, in the main, the wooly language of the standard permits
>different behaviours. The contention appears because people don't
>want to "break" their systems.
Sometimes. In the case of ' IF one vendor has changed his system to
avoid the STATE-smart Scylla, but then fell into the Charybdis of an
xt where COMPILE, does not behave like POSTPONE LITERAL POSTPONE
EXECUTE.
>So, set your sights
>on a *NEW* Forth 2020 standard, the principle purpose of which shall
>be to maximise the potential for portable code across different
>systems.
But there is no interest (that I can see) in portable code among the
commercial vendors. Of course, one can go off and work on a standard
without participation of the commercial vendors, but if they do not
participate, their systems will probably not support the standard, so
again we would miss the goal of portable code.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-02 08:06 -0800 |
| Message-ID | <ec7b4e23-5a03-477b-b04d-29e42e0e4d97@googlegroups.com> |
| In reply to | #43119 |
On Monday, 2 November 2015 15:28:30 UTC, Anton Ertl wrote: > > In particular, once we have recognizers, we may be able to get rid of > things like S" and TO, and then we can get rid of non-default > non-immediate compilation semantics in the standard; if we manage to > get there, the differences between the behaviour of the systems will > be smaller, and it will hopefully be easier to find common ground. > That's actually a good point that hadn't really considered. The older words have a lot of emotional baggage associated with them. As you say, some people may resort to entrenched positions that they have held for years, simply because of a particular system they use. Perhaps turning over a new leaf is what is needed rather than trying to fix older issues; then the older issues/words can be put on the eventual path to obsolescence. This'll take a long time though!
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-11-02 08:32 -0800 |
| Message-ID | <e94036fd-be4c-41a6-9144-a9287c820c5a@googlegroups.com> |
| In reply to | #43124 |
luni, 2 noiembrie 2015, 18:06:25 UTC+2, Mark Wills a scris: > On Monday, 2 November 2015 15:28:30 UTC, Anton Ertl wrote: > > > > In particular, once we have recognizers, we may be able to get rid of > > things like S" and TO, and then we can get rid of non-default > > non-immediate compilation semantics in the standard; if we manage to > > get there, the differences between the behaviour of the systems will > > be smaller, and it will hopefully be easier to find common ground. > > Why this obsession about S" and TO? Because they are parsing words? There are plenty of parsing words in Forth! Let's get rid of all of them, including : ' char include cretae variable etc. In fact, a forth system with NO PARSING WORDS is more simple and more readable and understandable. At least it is a true postfix system... infix (parsing words) combined with the postfix (the majority of words) can lead to confusion, at least when the infix words are user defined. In this case you will really have hard time to understand the code because you will not know if a word is "working" on the following text or it is a normal word working on previous things... I have such a forth system. I named it QUO. It has an internal parser that will generate usable strings for the user on the data stack (the strings in a circular buffer, only the string descriptors (adr+len) on the stack). The parser is not accesible at all. Here it is a fragment written in QUO: \ Ethernet packet structure 0 6 "eth.dstmac" field \ destination mac address 6 "eth.srcmac" field \ source mac address 2 "eth.type" field \ ethernet type / length "eth" constant 0x0008 "ETHTYPE_IPv4" constant \ 0x0800 - ipv4 protocol 0x0608 "ETHTYPE_ARP" constant \ 0x0806 - arp protocol [ "ptr" local ptr @ 4 + h@ 0xffff = ptr @ @ 0xffffffff = and if true else false then ] "broadcast_mac?" def [ "ptr" local ptr @ 4 + h@ my_mac_addr 4 + h@ = ptr @ @ my_mac_addr @ = and if true exit then false ] "my_mac?" def [ "rcvmac" local eth_packet eth.dstmac rcvmac ! rcvmac @ broadcast_mac? rcvmac @ my_mac? or if true else false then ] "is_my_mac?" def Got the idea? It is quite pleasent to work in this system, although it looks quite different (at the first sight). It is more "forth" than forth. It is a true postfix system. I'm thinking lately of resuming the work on QUO. This time I will change the name from QUO (this is from "quotations" - because everything in quo is a quotation, even the top level definition) in "PostForth". "PostForth" a post forth era postfix Forth language :D
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-02 20:04 +0000 |
| Message-ID | <5637c1e6$0$23801$e4fe514c@news.xs4all.nl> |
| In reply to | #43126 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>luni, 2 noiembrie 2015, 18:06:25 UTC+2, Mark Wills a scris:
>> On Monday, 2 November 2015 15:28:30 UTC, Anton Ertl wrote:
>> >
>> > In particular, once we have recognizers, we may be able to get rid of
>> > things like S" and TO, and then we can get rid of non-default
>> > non-immediate compilation semantics in the standard; if we manage to
>> > get there, the differences between the behaviour of the systems will
>> > be smaller, and it will hopefully be easier to find common ground.
>> >
>Why this obsession about S" and TO? Because they are parsing words? There
>are plenty of parsing words in Forth! Let's get rid of all of them, including
>: ' char include cretae variable etc.
>In fact, a forth system with NO PARSING WORDS is more simple and more
>readable and understandable. At least it is a true postfix system...
>infix (parsing words) combined with the postfix (the majority of words)
>can lead to confusion, at least when the infix words are user defined.
>In this case you will really have hard time to understand the code because
>you will not know if a word is "working" on the following text or it is
>a normal word working on previous things...
>I have such a forth system. I named it QUO. It has an internal parser that will
>generate usable strings for the user on the data stack (the strings in a
>circular buffer, only the string descriptors (adr+len) on the stack). The
>parser is not accesible at all.
I have the same feeling, however I wanted ciforth to be reasonable
ISO compliant. It turns out that one can restrict the parse ahead
to denotations (a subset of what is nowadays called recognizers)
and defining words, such as CONSTANT : VARIABLE CREATE ...
And a few utility words like INCLUDE FORGET .
The utility words show why you want parse ahead for convenience.
In ciforth you can do `` "aap" INCLUDED "NOOT" FORGOTTEN ''
but you don't want the extra typing.
{ 1 2 DROP } "do-something" def
is cumbersome. Everybody does
INCLUDE something
and before denotations/recognizers for strings were promoted to
near CORE availability,
"something" INCLUDED
was not even an option. ( S" something" INCLUDED ? Really? )
The most important denotation is '. 'TASK ALIAS NOOP
It gives the dea, an address that allows to find *all* the
information about a word.
Alas, this only flies if the Forth system is designed around it,
but then all parsing ahead problems disappears.
(The closest thing is a "name token" )
>Here it is a fragment written in QUO:
>\ Ethernet packet structure
>0 6 "eth.dstmac" field \ destination mac address
> 6 "eth.srcmac" field \ source mac address
> 2 "eth.type" field \ ethernet type / length
>"eth" constant
>0x0008 "ETHTYPE_IPv4" constant \ 0x0800 - ipv4 protocol
>0x0608 "ETHTYPE_ARP" constant \ 0x0806 - arp protocol
>[ "ptr" local
> ptr @ 4 + h@ 0xffff =
> ptr @ @ 0xffffffff = and if true else false then
>] "broadcast_mac?" def
>[ "ptr" local
> ptr @ 4 + h@ my_mac_addr 4 + h@ =
> ptr @ @ my_mac_addr @ = and if true exit then
> false
>] "my_mac?" def
>[ "rcvmac" local
> eth_packet eth.dstmac rcvmac !
> rcvmac @ broadcast_mac?
> rcvmac @ my_mac? or if true else false then
>] "is_my_mac?" def
>Got the idea?
>It is quite pleasent to work in this system, although it looks quite
>different (at the first sight). It is more "forth" than forth. It is
>a true postfix system.
Compare with postfix. However they make a distinction between
real text strings (with "") and names in behalf of the program ( with \).
>I'm thinking lately of resuming the work on QUO. This time I will change
>the name from QUO (this is from "quotations" - because everything in quo
>is a quotation, even the top level definition) in "PostForth".
>"PostForth" a post forth era postfix Forth language :D
(See my postfix remark). There is a slight psychological barrier.
: aap ... ;
: noot .. aap .. ;
`` aap '' is a Forth name. You don't really want it to be "aap"
at the place were it is defined.
For the rest, I like it.
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 | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-11-02 22:31 -0800 |
| Message-ID | <7dc6a362-d7b7-4ca5-9b59-73df2573fc45@googlegroups.com> |
| In reply to | #43137 |
> Compare with postfix. However they make a distinction between
> real text strings (with "") and names in behalf of the program ( with \).
>
You mean PostScript?
For a while I was thinking of something like / in Postcript, but I didn't
come up with a good char. For example, Pablo's Reda has : prefix for definig
new words, but I need a char for any string. ":" is not bad in fact, probably
better than postscript's /
OTOH, my examples are from an older version. The latest version has the name
and xt for "def" swapped:
"foo" [ dup drop ] def
This is not because I wanted the name to be in front of the xt, but to
make the "def" and "build" having the same stack effect:
def \ name xt --
build \ name xt --
"build" is like create does> in forth. It expects a quotation and "builds"
it in a defining word. For example, this is how the CONSTANT looks like:
"constant" [ [ @ ] ibuild , ] def
("ibuild" builds an immediate word)
You are right, it's a psychological thing to use quotes. But it is for
forthers.. Once you understand why are the quotes, everything looks quite
normal...
About less typing... get real, you type quotes only once, when the word is
created, then you don't have to type quotes again when used...
"Typing" is a hot debate in programming. Usually it is the least important
thing though....
I forgot an important aspect of QUO: the data stack size is doubled. It means
that for a 32bit system the data stack is 64bit. This is for easier
access of the strings which have their descriptor fitting on a single
stack item.
The system CELL is 32bit though. The cell is in fact the size of the
address/register of the host, and all the single precision math is 32bit
also. Only the stack and the juggling words are doubled.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-03 18:49 -0800 |
| Message-ID | <63c2b9c1-cb9c-4cf2-a7e2-e090f6f9971e@googlegroups.com> |
| In reply to | #43153 |
On Monday, November 2, 2015 at 11:31:37 PM UTC-7, Raimond Dragomir wrote:
> def \ name xt --
> build \ name xt --
>
> "build" is like create does> in forth. It expects a quotation and "builds"
> it in a defining word. For example, this is how the CONSTANT looks like:
>
> "constant" [ [ @ ] ibuild , ] def
>
> ("ibuild" builds an immediate word)
>
> You are right, it's a psychological thing to use quotes. But it is for
> forthers.. Once you understand why are the quotes, everything looks quite
> normal...
>
> About less typing... get real, you type quotes only once, when the word is
> created, then you don't have to type quotes again when used...
The Stundurd processor now has a TSR: defining word ("terminate and stay resident," meaning that the TSR's local-frame is on the heap rather than on the return-stack and it remains valid after the TSR has exited). Any quotation defined within the TSR (quotations in TSRs are called "generators," which is a term I borrowed from Icon) can execute after the TSR has gone out of scope.
I added TSRs and generators primarily so that I would have something comparable to your BUILD and IBUILD --- I'm just trying to stay at the same level as your system. :-)
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web