Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.prolog > #12554 > unrolled thread
| Started by | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| First post | 2022-01-28 07:41 -0800 |
| Last post | 2025-08-01 03:01 +0200 |
| Articles | 20 on this page of 200 — 6 participants |
Back to article view | Back to comp.lang.prolog
50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 07:41 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 07:47 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 07:49 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 07:59 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:07 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:10 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:15 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:33 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:35 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:52 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-02 03:46 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-04 03:18 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 06:04 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-02-08 15:06 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 13:23 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 13:35 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 13:42 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 13:48 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 16:17 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 16:34 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-04 01:01 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-04 01:03 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-04 13:10 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-05 15:32 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-16 17:30 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-17 05:10 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-17 13:39 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-17 13:53 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-23 13:57 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-24 05:32 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-24 11:47 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-24 14:49 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-04-29 13:27 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-04-29 13:37 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-30 08:38 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-30 08:45 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-04 11:35 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 00:21 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 00:52 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 00:58 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 01:23 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 03:04 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 03:08 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 03:19 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 03:56 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 04:07 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-01-29 15:56 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-01-29 16:05 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-01-29 16:56 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-31 10:37 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-31 10:45 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-02 12:03 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-03 02:44 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-03 02:49 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-03 03:11 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-10 05:54 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-25 02:39 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-25 02:41 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 00:45 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 01:03 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 01:28 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 01:28 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 01:40 -0700
Re: 50 Years of Prolog Nonsense Markus Triska <triska@logic.at> - 2022-07-12 19:25 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 14:50 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 15:01 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 15:16 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 16:02 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 16:22 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 16:32 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-13 07:08 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-04 17:58 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-04 18:01 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 01:16 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 01:19 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 04:07 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 04:25 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 07:56 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 07:56 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 08:14 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-06 12:45 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-06 12:47 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-07 05:24 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-07 05:26 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-07 05:32 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-07 06:50 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-08 15:07 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-08 15:16 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-09 03:23 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-09 12:27 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-09 12:33 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 04:13 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 04:41 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 05:19 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 07:20 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 07:30 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 07:46 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-18 07:16 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-18 07:17 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-18 15:13 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-28 15:04 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-21 10:42 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-22 06:13 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-22 06:23 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-22 06:41 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-23 07:44 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-25 07:10 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-25 07:11 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-25 08:55 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-25 08:56 -0700
Re: 50 Years of Prolog Nonsense Markus Triska <triska@logic.at> - 2023-08-31 21:32 +0200
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-09-01 12:02 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <janburse@fastmail.fm> - 2024-04-09 00:15 +0200
Re: 50 Years of Prolog Nonsense Mild Shock <janburse@fastmail.fm> - 2024-04-09 00:20 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2023-05-20 14:09 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-20 05:46 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-20 05:48 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-20 06:16 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-05-27 04:51 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-01 14:10 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-01 14:11 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-01 14:17 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-03 05:20 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-03 09:10 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-02 00:44 -0700
PIPs from the Basilisk Chamber (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-09-29 17:22 +0200
Prolog Pearls I: Barklund and Millroth (Was: PIPs from the Basilisk Chamber) Mild Shock <janburse@fastmail.fm> - 2024-11-08 15:07 +0100
Prolog Pearls II: Barklund and Millroth (Was: PIPs from the Basilisk Chamber) Mild Shock <janburse@fastmail.fm> - 2024-11-08 15:29 +0100
change_arg/3 = nb_linkarg/3 ? (Was: PIPs from the Basilisk Chamber) Mild Shock <janburse@fastmail.fm> - 2024-11-08 18:37 +0100
Re: change_arg/3 = nb_linkarg/3 ? (Was: PIPs from the Basilisk Chamber) Mild Shock <janburse@fastmail.fm> - 2024-11-08 18:39 +0100
Re: PIPs from the Basilisk Chamber (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-09 15:47 +0100
Re: PIPs from the Basilisk Chamber (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-09 15:48 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-09-25 21:19 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-09-25 21:21 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-27 10:11 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-09-27 19:13 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 03:33 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 03:34 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 03:37 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 03:56 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 05:01 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 06:44 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-18 16:21 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-18 16:22 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-25 16:00 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-30 21:53 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-30 22:03 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-30 22:29 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-02 10:51 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-03 21:17 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-03 21:36 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-03 21:50 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-07 07:35 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-14 07:53 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-22 08:54 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-22 10:02 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-22 15:37 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-29 07:19 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-29 07:20 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-29 07:32 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-29 07:55 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-30 07:06 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-02-06 00:49 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-02-06 00:53 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-02-20 06:23 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-02-20 06:31 -0800
How working with GitHub feels (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-03-13 14:45 +0100
Re: How working with GitHub feels (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-03-13 15:05 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-12 09:12 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-12 09:14 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-14 17:57 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2023-03-15 02:01 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2023-03-15 02:09 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-28 06:07 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-28 06:30 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-28 10:04 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-28 10:05 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-04-02 15:10 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-25 08:48 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-25 08:53 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-25 09:02 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-07-29 04:57 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-07-29 05:10 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <janburse@fastmail.fm> - 2023-07-29 23:16 +0200
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-07-30 05:06 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-08-01 01:09 -0700
How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-10 12:37 +0100
Re: How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-10 12:40 +0100
Re: How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-10 12:42 +0100
How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-12 16:30 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-12 16:32 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-14 05:14 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-14 05:24 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Julio Di Egidio <julio@diegidio.name> - 2024-11-14 21:21 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-14 21:58 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-14 22:10 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Julio Di Egidio <julio@diegidio.name> - 2024-11-15 15:42 +0100
Mode yfy to the rescue (Was: How Prolog became an education nightmare) Mild Shock <janburse@fastmail.fm> - 2024-11-14 22:30 +0100
Cyclic term predicates suffer from ambiguity (Was: How Prolog became an education nightmare) Mild Shock <janburse@fastmail.fm> - 2025-08-01 02:47 +0200
An ISO term_variables/2 for Cyclic Terms (Was: Cyclic term predicates suffer from ambiguity) Mild Shock <janburse@fastmail.fm> - 2025-08-01 03:01 +0200
Page 1 of 10 [1] 2 3 … 10 Next page →
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 07:41 -0800 |
| Subject | 50 Years of Prolog Nonsense |
| Message-ID | <db903ba2-8ccd-418e-bd18-a9eb381cd222n@googlegroups.com> |
50 Years of Prolog and Beyond 26 Jan 2022 - SWOT analysis https://arxiv.org/abs/2201.10816 No mention of self-hosting systems? Like the AQUARIUS Prolog system. I am not sure whether it was 100% self-hosting, but had many parts written in Prolog itself, interpreter and compiler: Aquarius Prolog 1.0 https://www.info.ucl.ac.be/~pvr/aquarius.html What is self-hosting? See Wikipedia: "In computer programming, self-hosting is the use of a program as part of the toolchain or operating system that produces new versions of that same program—for example, a compiler that can compile its own source code." https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29 Why isn't Prolog listed there?
[toc] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 07:47 -0800 |
| Message-ID | <f556f96e-c529-4fa7-a2aa-9e64914fa587n@googlegroups.com> |
| In reply to | #12554 |
Shit!!!! I am like a blink from self-hosting Dogelog player. I only need open(write) and open(append) ISO predicates, and maybe 2-3 other predicates, and it will be self-hosting. One itchy thing is, I would like to make the cross compiler output pretty printed, like not occupying lines longer than 75 characters, so I need a more intelligent pretty printing first, before I can generate "nice" and VCS friendly and debuger friendly cross compiled output. Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1: > 50 Years of Prolog and Beyond > 26 Jan 2022 - SWOT analysis > https://arxiv.org/abs/2201.10816 > > No mention of self-hosting systems? Like the AQUARIUS > Prolog system. I am not sure whether it was 100% self-hosting, > but had many parts written in Prolog itself, interpreter and compiler: > > Aquarius Prolog 1.0 > https://www.info.ucl.ac.be/~pvr/aquarius.html > > What is self-hosting? See Wikipedia: > > "In computer programming, self-hosting is the use of a > program as part of the toolchain or operating system that > produces new versions of that same program—for example, > a compiler that can compile its own source code." > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29 > > Why isn't Prolog listed there?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 07:49 -0800 |
| Message-ID | <01cd804e-ed22-4bd5-becc-7e40d02355b3n@googlegroups.com> |
| In reply to | #12555 |
Also I had some nice findings about style checks. The cross compiler can also do a couple of them, although he fires and forgets what he cross compiles. But the cross compiler can keep the same meta data predicate property info like the online system, and perform some style checks that go beyond the trivial singleton check, makeing it ultimately show the same warnings like the online system. Which would prevent a lot of programming errors. The cross-compiler would then be a little bit more restrictive what it accepts than the online system, because it needs to interpret certain directives. Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1: > Shit!!!! I am like a blink from self-hosting Dogelog player. > I only need open(write) and open(append) ISO predicates, > and maybe 2-3 other predicates, and it will be self-hosting. > > One itchy thing is, I would like to make the cross compiler > output pretty printed, like not occupying lines longer than > 75 characters, so I need a more intelligent pretty printing first, > > before I can generate "nice" and VCS friendly and debuger > friendly cross compiled output. > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1: > > 50 Years of Prolog and Beyond > > 26 Jan 2022 - SWOT analysis > > https://arxiv.org/abs/2201.10816 > > > > No mention of self-hosting systems? Like the AQUARIUS > > Prolog system. I am not sure whether it was 100% self-hosting, > > but had many parts written in Prolog itself, interpreter and compiler: > > > > Aquarius Prolog 1.0 > > https://www.info.ucl.ac.be/~pvr/aquarius.html > > > > What is self-hosting? See Wikipedia: > > > > "In computer programming, self-hosting is the use of a > > program as part of the toolchain or operating system that > > produces new versions of that same program—for example, > > a compiler that can compile its own source code." > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29 > > > > Why isn't Prolog listed there?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 07:59 -0800 |
| Message-ID | <c657fedb-baea-4e8f-a0ec-31ef0dd40aadn@googlegroups.com> |
| In reply to | #12556 |
Ha Ha, their SWOT Analysis is cringe: Threats (Section 4.4) post-desktop world of JavaScript web-applications Good luck with sticking to C, Java or other nonsense, and not having self-hosting system, where the backend can easily be switched. Or even self-hosting system that target high-level languages with their own garbage collection, such as JavaScript or Python. I cannot predict the future, but I have the impression that if you have an item on your SWOT Analysis as a threat and do not adress it for years, what will be the outcome? Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:49:10 UTC+1: > Also I had some nice findings about style checks. The cross > compiler can also do a couple of them, although he fires and > forgets what he cross compiles. But the cross compiler can > > keep the same meta data predicate property info like the > online system, and perform some style checks that go beyond > the trivial singleton check, makeing it ultimately show the same > > warnings like the online system. Which would prevent a lot > of programming errors. The cross-compiler would then be a > little bit more restrictive what it accepts than the online system, > > because it needs to interpret certain directives. > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1: > > Shit!!!! I am like a blink from self-hosting Dogelog player. > > I only need open(write) and open(append) ISO predicates, > > and maybe 2-3 other predicates, and it will be self-hosting. > > > > One itchy thing is, I would like to make the cross compiler > > output pretty printed, like not occupying lines longer than > > 75 characters, so I need a more intelligent pretty printing first, > > > > before I can generate "nice" and VCS friendly and debuger > > friendly cross compiled output. > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1: > > > 50 Years of Prolog and Beyond > > > 26 Jan 2022 - SWOT analysis > > > https://arxiv.org/abs/2201.10816 > > > > > > No mention of self-hosting systems? Like the AQUARIUS > > > Prolog system. I am not sure whether it was 100% self-hosting, > > > but had many parts written in Prolog itself, interpreter and compiler: > > > > > > Aquarius Prolog 1.0 > > > https://www.info.ucl.ac.be/~pvr/aquarius.html > > > > > > What is self-hosting? See Wikipedia: > > > > > > "In computer programming, self-hosting is the use of a > > > program as part of the toolchain or operating system that > > > produces new versions of that same program—for example, > > > a compiler that can compile its own source code." > > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29 > > > > > > Why isn't Prolog listed there?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 08:07 -0800 |
| Message-ID | <e977c06f-7bc4-48b4-be84-819c9deee22bn@googlegroups.com> |
| In reply to | #12557 |
Also JavaScript and Python in the form of node.js and PyPy make a quite good impression also server side, nothing to do with desktop or client side. Thats also nonsense. But there are dozen of open questions now. How to make it multi-threaded, how to make an auto-tuning garbage collector, that somehow adapts to the performance of the target system. On my old system I was deteriming fixed parameters so that garbage collection does it job 60 times per second. Now on my new system with some AMD Ryzen, these parameters are not correct anymore, and it does more than 60 times per second. I running it on an Apple M1 will be even worse. Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:59:10 UTC+1: > Ha Ha, their SWOT Analysis is cringe: > > Threats (Section 4.4) > post-desktop world of JavaScript web-applications > > Good luck with sticking to C, Java or other nonsense, > and not having self-hosting system, where the backend > can easily be switched. Or even self-hosting system > > that target high-level languages with their own garbage > collection, such as JavaScript or Python. I cannot predict > the future, but I have the impression that if you have > > an item on your SWOT Analysis as a threat and do not > adress it for years, what will be the outcome? > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:49:10 UTC+1: > > Also I had some nice findings about style checks. The cross > > compiler can also do a couple of them, although he fires and > > forgets what he cross compiles. But the cross compiler can > > > > keep the same meta data predicate property info like the > > online system, and perform some style checks that go beyond > > the trivial singleton check, makeing it ultimately show the same > > > > warnings like the online system. Which would prevent a lot > > of programming errors. The cross-compiler would then be a > > little bit more restrictive what it accepts than the online system, > > > > because it needs to interpret certain directives. > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1: > > > Shit!!!! I am like a blink from self-hosting Dogelog player. > > > I only need open(write) and open(append) ISO predicates, > > > and maybe 2-3 other predicates, and it will be self-hosting. > > > > > > One itchy thing is, I would like to make the cross compiler > > > output pretty printed, like not occupying lines longer than > > > 75 characters, so I need a more intelligent pretty printing first, > > > > > > before I can generate "nice" and VCS friendly and debuger > > > friendly cross compiled output. > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1: > > > > 50 Years of Prolog and Beyond > > > > 26 Jan 2022 - SWOT analysis > > > > https://arxiv.org/abs/2201.10816 > > > > > > > > No mention of self-hosting systems? Like the AQUARIUS > > > > Prolog system. I am not sure whether it was 100% self-hosting, > > > > but had many parts written in Prolog itself, interpreter and compiler: > > > > > > > > Aquarius Prolog 1.0 > > > > https://www.info.ucl.ac.be/~pvr/aquarius.html > > > > > > > > What is self-hosting? See Wikipedia: > > > > > > > > "In computer programming, self-hosting is the use of a > > > > program as part of the toolchain or operating system that > > > > produces new versions of that same program—for example, > > > > a compiler that can compile its own source code." > > > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29 > > > > > > > > Why isn't Prolog listed there?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 08:10 -0800 |
| Message-ID | <d6891d67-ac96-4ac2-b0a4-05eabd2c9196n@googlegroups.com> |
| In reply to | #12558 |
But I need a notion that goes beyond wall time now, something like user time and system time. In JavaScript user time would be suspended when for example a wait for setTime() or some fetch is ongoing. But interestingly because the target language has a certain event loop architecture, we can cooperate with this event loop architecture, and for example do our own Prolog garbage collection before we relinquish to the event loop, so that the target system is not in a troubled situation when ever it processes its own tasks. And we can kind of define the two notions user time and system time on our own, so that it seems feasible to create an auto-tuning garbage collector for such target systems. Not yet sure. Will see. Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:07:08 UTC+1: > Also JavaScript and Python in the form of node.js and > PyPy make a quite good impression also server side, nothing > to do with desktop or client side. Thats also nonsense. > > But there are dozen of open questions now. How to make > it multi-threaded, how to make an auto-tuning garbage collector, > that somehow adapts to the performance of the target system. > > On my old system I was deteriming fixed parameters so that garbage > collection does it job 60 times per second. Now on my new > system with some AMD Ryzen, these parameters are not correct > > anymore, and it does more than 60 times per second. I running > it on an Apple M1 will be even worse. > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:59:10 UTC+1: > > Ha Ha, their SWOT Analysis is cringe: > > > > Threats (Section 4.4) > > post-desktop world of JavaScript web-applications > > > > Good luck with sticking to C, Java or other nonsense, > > and not having self-hosting system, where the backend > > can easily be switched. Or even self-hosting system > > > > that target high-level languages with their own garbage > > collection, such as JavaScript or Python. I cannot predict > > the future, but I have the impression that if you have > > > > an item on your SWOT Analysis as a threat and do not > > adress it for years, what will be the outcome? > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:49:10 UTC+1: > > > Also I had some nice findings about style checks. The cross > > > compiler can also do a couple of them, although he fires and > > > forgets what he cross compiles. But the cross compiler can > > > > > > keep the same meta data predicate property info like the > > > online system, and perform some style checks that go beyond > > > the trivial singleton check, makeing it ultimately show the same > > > > > > warnings like the online system. Which would prevent a lot > > > of programming errors. The cross-compiler would then be a > > > little bit more restrictive what it accepts than the online system, > > > > > > because it needs to interpret certain directives. > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1: > > > > Shit!!!! I am like a blink from self-hosting Dogelog player. > > > > I only need open(write) and open(append) ISO predicates, > > > > and maybe 2-3 other predicates, and it will be self-hosting. > > > > > > > > One itchy thing is, I would like to make the cross compiler > > > > output pretty printed, like not occupying lines longer than > > > > 75 characters, so I need a more intelligent pretty printing first, > > > > > > > > before I can generate "nice" and VCS friendly and debuger > > > > friendly cross compiled output. > > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1: > > > > > 50 Years of Prolog and Beyond > > > > > 26 Jan 2022 - SWOT analysis > > > > > https://arxiv.org/abs/2201.10816 > > > > > > > > > > No mention of self-hosting systems? Like the AQUARIUS > > > > > Prolog system. I am not sure whether it was 100% self-hosting, > > > > > but had many parts written in Prolog itself, interpreter and compiler: > > > > > > > > > > Aquarius Prolog 1.0 > > > > > https://www.info.ucl.ac.be/~pvr/aquarius.html > > > > > > > > > > What is self-hosting? See Wikipedia: > > > > > > > > > > "In computer programming, self-hosting is the use of a > > > > > program as part of the toolchain or operating system that > > > > > produces new versions of that same program—for example, > > > > > a compiler that can compile its own source code." > > > > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29 > > > > > > > > > > Why isn't Prolog listed there?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 08:15 -0800 |
| Message-ID | <22deb94e-8ea7-4186-b54c-f62acf6bfc21n@googlegroups.com> |
| In reply to | #12559 |
TauProlog and SWI-Prolog might also be on a path forward here. SWI-Prolog discourse had recently an interesting post: Yielding prolog engines from within a foreign predicate https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5 But this was in the context of Rust. What Scryer Prolog offers here I don't know, the Rust and Crate build system is annyoingly slow, and fails because of some OpenSSL issues on WSL. No time to fix that and follow what Scryer Prolog is doing... Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:10:35 UTC+1: > But I need a notion that goes beyond wall time now, something > like user time and system time. In JavaScript user time would > be suspended when for example a wait for setTime() or some > > fetch is ongoing. But interestingly because the target language > has a certain event loop architecture, we can cooperate with this > event loop architecture, and for example do our own Prolog > > garbage collection before we relinquish to the event loop, > so that the target system is not in a troubled situation when ever > it processes its own tasks. And we can kind of define the > > two notions user time and system time on our own, so that > it seems feasible to create an auto-tuning garbage collector > for such target systems. Not yet sure. Will see. > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:07:08 UTC+1: > > Also JavaScript and Python in the form of node.js and > > PyPy make a quite good impression also server side, nothing > > to do with desktop or client side. Thats also nonsense. > > > > But there are dozen of open questions now. How to make > > it multi-threaded, how to make an auto-tuning garbage collector, > > that somehow adapts to the performance of the target system. > > > > On my old system I was deteriming fixed parameters so that garbage > > collection does it job 60 times per second. Now on my new > > system with some AMD Ryzen, these parameters are not correct > > > > anymore, and it does more than 60 times per second. I running > > it on an Apple M1 will be even worse. > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:59:10 UTC+1: > > > Ha Ha, their SWOT Analysis is cringe: > > > > > > Threats (Section 4.4) > > > post-desktop world of JavaScript web-applications > > > > > > Good luck with sticking to C, Java or other nonsense, > > > and not having self-hosting system, where the backend > > > can easily be switched. Or even self-hosting system > > > > > > that target high-level languages with their own garbage > > > collection, such as JavaScript or Python. I cannot predict > > > the future, but I have the impression that if you have > > > > > > an item on your SWOT Analysis as a threat and do not > > > adress it for years, what will be the outcome? > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:49:10 UTC+1: > > > > Also I had some nice findings about style checks. The cross > > > > compiler can also do a couple of them, although he fires and > > > > forgets what he cross compiles. But the cross compiler can > > > > > > > > keep the same meta data predicate property info like the > > > > online system, and perform some style checks that go beyond > > > > the trivial singleton check, makeing it ultimately show the same > > > > > > > > warnings like the online system. Which would prevent a lot > > > > of programming errors. The cross-compiler would then be a > > > > little bit more restrictive what it accepts than the online system, > > > > > > > > because it needs to interpret certain directives. > > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1: > > > > > Shit!!!! I am like a blink from self-hosting Dogelog player. > > > > > I only need open(write) and open(append) ISO predicates, > > > > > and maybe 2-3 other predicates, and it will be self-hosting. > > > > > > > > > > One itchy thing is, I would like to make the cross compiler > > > > > output pretty printed, like not occupying lines longer than > > > > > 75 characters, so I need a more intelligent pretty printing first, > > > > > > > > > > before I can generate "nice" and VCS friendly and debuger > > > > > friendly cross compiled output. > > > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1: > > > > > > 50 Years of Prolog and Beyond > > > > > > 26 Jan 2022 - SWOT analysis > > > > > > https://arxiv.org/abs/2201.10816 > > > > > > > > > > > > No mention of self-hosting systems? Like the AQUARIUS > > > > > > Prolog system. I am not sure whether it was 100% self-hosting, > > > > > > but had many parts written in Prolog itself, interpreter and compiler: > > > > > > > > > > > > Aquarius Prolog 1.0 > > > > > > https://www.info.ucl.ac.be/~pvr/aquarius.html > > > > > > > > > > > > What is self-hosting? See Wikipedia: > > > > > > > > > > > > "In computer programming, self-hosting is the use of a > > > > > > program as part of the toolchain or operating system that > > > > > > produces new versions of that same program—for example, > > > > > > a compiler that can compile its own source code." > > > > > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29 > > > > > > > > > > > > Why isn't Prolog listed there?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 08:33 -0800 |
| Message-ID | <f65f56e4-ae14-49fd-96e7-6e2180e1251dn@googlegroups.com> |
| In reply to | #12560 |
But you see the problem with non-self-hosting Prolog systems. If SWI-Prolog were self-hosting, there would be already a Rust version of SWI-Prolog now. But SWI-Prolog is the anti-thesis to a Prolog system that is 100% Prolog. Its rather a Prolog system that is 100% C. And you cannot easily switch some back-end from C to Rust, and have a top-level in Rust. Its quite astonishingly how much SWI-Prolog relies on C, even when you would only consider a very small subset. It seems SWI-Prolog never trusted Prolog as an implementation language because of performance issues. I don't know the final judgement here, there is an old post by Richard O'Keefe that says self hosting in principle shouldn't be a problem. "John Griffith writes: I know it will be slower. Richard A. O'Keefe responds: Are you sure? The measurements I did a couple of years ago showed that tokenising was slower in Prolog than in C (typically because Prolog implementors don't put the effort into making get0/1 go as screamingly fast as it could go), but there was very little difference in parsing if you had a good Prolog compiler." 7th November 1996 - Prolog Parser in Prolog https://dtai.cs.kuleuven.be/projects/ALP/newsletter/archive_93_96/net/grammars/parser.html Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1: > TauProlog and SWI-Prolog might also be on a path > forward here. SWI-Prolog discourse had recently > an interesting post: > > Yielding prolog engines from within a foreign predicate > https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5 > > But this was in the context of Rust. What Scryer Prolog offers > here I don't know, the Rust and Crate build system is annyoingly > slow, and fails because of some OpenSSL issues on WSL. > > No time to fix that and follow what Scryer Prolog is doing...
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 08:35 -0800 |
| Message-ID | <729b0fe6-c525-4050-963d-56b18f80f81dn@googlegroups.com> |
| In reply to | #12561 |
Disclaimer: Maybe SWI-Prolog does the parsing already in C, and the C percentage is not that high. I am drawing some extreme pictures here to make a point. Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:33:46 UTC+1: > But you see the problem with non-self-hosting Prolog systems. > If SWI-Prolog were self-hosting, there would be already a Rust > version of SWI-Prolog now. But SWI-Prolog is the anti-thesis > > to a Prolog system that is 100% Prolog. Its rather a Prolog > system that is 100% C. And you cannot easily switch some > back-end from C to Rust, and have a top-level in Rust. > > Its quite astonishingly how much SWI-Prolog relies on C, > even when you would only consider a very small subset. It > seems SWI-Prolog never trusted Prolog as an implementation > > language because of performance issues. I don't know the > final judgement here, there is an old post by Richard O'Keefe > that says self hosting in principle shouldn't be a problem. > > "John Griffith writes: > I know it will be slower. > > Richard A. O'Keefe responds: > Are you sure? The measurements I did a couple of years ago > showed that tokenising was slower in Prolog than in C (typically > because Prolog implementors don't put the effort into making > get0/1 go as screamingly fast as it could go), but there was very > little difference in parsing if you had a good Prolog compiler." > 7th November 1996 - Prolog Parser in Prolog > https://dtai.cs.kuleuven.be/projects/ALP/newsletter/archive_93_96/net/grammars/parser.html > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1: > > TauProlog and SWI-Prolog might also be on a path > > forward here. SWI-Prolog discourse had recently > > an interesting post: > > > > Yielding prolog engines from within a foreign predicate > > https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5 > > > > But this was in the context of Rust. What Scryer Prolog offers > > here I don't know, the Rust and Crate build system is annyoingly > > slow, and fails because of some OpenSSL issues on WSL. > > > > No time to fix that and follow what Scryer Prolog is doing...
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-01-28 08:52 -0800 |
| Message-ID | <067ef607-6694-4179-af60-929ab6421ad3n@googlegroups.com> |
| In reply to | #12562 |
Corr.: Typo Disclaimer: Maybe SWI-Prolog does the parsing already in Prolog, and the C percentage is not that high. I am drawing some extreme pictures here to make a point. Also instead of self-hosting, foreign-hosting, just using a cross compiler, is of course also a solution. But ultimately compiling your own system with your system, is a nice bootstrapping test and decouples you from some other system. Might be necessary to perform a certain evolution through bootstrapping, when you want to abandon the other system. Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:35:42 UTC+1: > Disclaimer: Maybe SWI-Prolog does the parsing already in C, > and the C percentage is not that high. I am drawing some > extreme pictures here to make a point. > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:33:46 UTC+1: > > But you see the problem with non-self-hosting Prolog systems. > > If SWI-Prolog were self-hosting, there would be already a Rust > > version of SWI-Prolog now. But SWI-Prolog is the anti-thesis > > > > to a Prolog system that is 100% Prolog. Its rather a Prolog > > system that is 100% C. And you cannot easily switch some > > back-end from C to Rust, and have a top-level in Rust. > > > > Its quite astonishingly how much SWI-Prolog relies on C, > > even when you would only consider a very small subset. It > > seems SWI-Prolog never trusted Prolog as an implementation > > > > language because of performance issues. I don't know the > > final judgement here, there is an old post by Richard O'Keefe > > that says self hosting in principle shouldn't be a problem. > > > > "John Griffith writes: > > I know it will be slower. > > > > Richard A. O'Keefe responds: > > Are you sure? The measurements I did a couple of years ago > > showed that tokenising was slower in Prolog than in C (typically > > because Prolog implementors don't put the effort into making > > get0/1 go as screamingly fast as it could go), but there was very > > little difference in parsing if you had a good Prolog compiler." > > 7th November 1996 - Prolog Parser in Prolog > > https://dtai.cs.kuleuven.be/projects/ALP/newsletter/archive_93_96/net/grammars/parser.html > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1: > > > TauProlog and SWI-Prolog might also be on a path > > > forward here. SWI-Prolog discourse had recently > > > an interesting post: > > > > > > Yielding prolog engines from within a foreign predicate > > > https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5 > > > > > > But this was in the context of Rust. What Scryer Prolog offers > > > here I don't know, the Rust and Crate build system is annyoingly > > > slow, and fails because of some OpenSSL issues on WSL. > > > > > > No time to fix that and follow what Scryer Prolog is doing...
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-02 03:46 -0800 |
| Message-ID | <8480178f-c543-4991-8852-7fab3ae36513n@googlegroups.com> |
| In reply to | #12560 |
The beauty of 3 valued logic! Or is it linear logic? Like the cut the new construct isn't commutative, but its implemented with extending true/false inside the Prolog trampoline. Was having a look at ECLiPSe Prolog engines. yield(+ToParent, -FromParent) Stop the running engine in the yielded-state, and wait for resume https://eclipseclp.org/docs/7.0/bips/kernel/engines/ I made something simpler for Dogelog player, which can be used to bootstrap a lot of things: '$STOP'(R): Internal only The built-in stops the interpreter loop with return value R. This is a forever and ever stop! Can this be used for anything? Well here is a sleep/1 implementation, it is assumed that the integer return value is interpreted as the delay of a timeout promise: sleep(T) :- '$STOP'(T). sleep(_). Putting everything together and we get: Async/Await Prolog Console for JavaScript/Python https://twitter.com/dogelogch/status/1488831738348515334 Async/Await Prolog Console for JavaScript/Python https://www.facebook.com/groups/dogelog With video recording! Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1: > TauProlog and SWI-Prolog might also be on a path > forward here. SWI-Prolog discourse had recently > an interesting post: > > Yielding prolog engines from within a foreign predicate > https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5 > > But this was in the context of Rust. What Scryer Prolog offers > here I don't know, the Rust and Crate build system is annyoingly > slow, and fails because of some OpenSSL issues on WSL.
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-04 03:18 -0800 |
| Message-ID | <7b455313-f626-4b28-91d3-815c97845f25n@googlegroups.com> |
| In reply to | #12574 |
If I dont stop now, in a few days I will have an Erlang system running. What already works is a yielding engine in the Browser. Non-Blocking Browser for Dogelog Player https://twitter.com/dogelogch/status/1489350992793677827 Non-Blocking Browser for Dogelog Player https://www.facebook.com/groups/dogelog With video recording and funky background sound! Next will be bring this yielding engine node.js and to Python as well. Mostowski Collapse schrieb am Mittwoch, 2. Februar 2022 um 12:46:30 UTC+1: > The beauty of 3 valued logic! Or is it linear logic? Like the > cut the new construct isn't commutative, but its implemented > with extending true/false inside the Prolog trampoline. Was > having a look at ECLiPSe Prolog engines. > > yield(+ToParent, -FromParent) > Stop the running engine in the yielded-state, and wait for resume > https://eclipseclp.org/docs/7.0/bips/kernel/engines/ > > I made something simpler for Dogelog player, which > can be used to bootstrap a lot of things: > > '$STOP'(R): Internal only > The built-in stops the interpreter loop with return value R. > > This is a forever and ever stop! Can this be used for > anything? Well here is a sleep/1 implementation, > it is assumed that the integer return value is interpreted > as the delay of a timeout promise: > > sleep(T) :- '$STOP'(T). > sleep(_). > > Putting everything together and we get: > > Async/Await Prolog Console for JavaScript/Python > https://twitter.com/dogelogch/status/1488831738348515334 > > Async/Await Prolog Console for JavaScript/Python > https://www.facebook.com/groups/dogelog > > With video recording! > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1: > > TauProlog and SWI-Prolog might also be on a path > > forward here. SWI-Prolog discourse had recently > > an interesting post: > > > > Yielding prolog engines from within a foreign predicate > > https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5 > > > > But this was in the context of Rust. What Scryer Prolog offers > > here I don't know, the Rust and Crate build system is annyoingly > > slow, and fails because of some OpenSSL issues on WSL.
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-08 06:04 -0800 |
| Message-ID | <7358eb33-9ac9-4594-97a4-68b9447459cfn@googlegroups.com> |
| In reply to | #12575 |
It will take some time until I have an Erlang system.
The small things use a lot of time. Now I have
an non-async/await Sandbox and a async/await Sandbox
online. The Audio Player example allows playing with
the async/await Sandbox. The Audio Example will
disable the Tryit button and enable it again, when finished.
But its non-blocking, you can interact with the browser,
and it will not show the warning display in Chrome. Unfortunately
there is still an unsolved problem, the LIPS go down.
But this here works fine:
longrunning :-
between(1,300,_),
between(1,300,_),
between(1,300,_),
fail.
longrunning.
?- time(longrunning).
% Wall 37203 ms, gc 25 ms, 2206445 lips
true.
http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example03/package.html
The LIPS go down because setTimeout() is clamped by 4ms in
the browser, and I do ca. 60x per Second setTimeout(). To give the
browser the opportunity to do his own stuff.
Mostowski Collapse schrieb am Freitag, 4. Februar 2022 um 12:18:50 UTC+1:
> If I dont stop now, in a few days I will have an
> Erlang system running. What already works is
> a yielding engine in the Browser.
>
> Non-Blocking Browser for Dogelog Player
> https://twitter.com/dogelogch/status/1489350992793677827
>
> Non-Blocking Browser for Dogelog Player
> https://www.facebook.com/groups/dogelog
>
> With video recording and funky background
> sound! Next will be bring this yielding engine
> node.js and to Python as well.
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <janburse@fastmail.fm> |
|---|---|
| Date | 2022-02-08 15:06 +0100 |
| Message-ID | <stttcm$scdj$1@solani.org> |
| In reply to | #12578 |
Maybe I should show a spinning wheel or something, while the thingy runs? The color change in the button is nearly not seen... Mostowski Collapse schrieb: > It will take some time until I have an Erlang system. > The small things use a lot of time. Now I have > an non-async/await Sandbox and a async/await Sandbox > > online. The Audio Player example allows playing with > the async/await Sandbox. The Audio Example will > disable the Tryit button and enable it again, when finished. > > But its non-blocking, you can interact with the browser, > and it will not show the warning display in Chrome. Unfortunately > there is still an unsolved problem, the LIPS go down. > > But this here works fine: > > longrunning :- > between(1,300,_), > between(1,300,_), > between(1,300,_), > fail. > longrunning. > > ?- time(longrunning). > % Wall 37203 ms, gc 25 ms, 2206445 lips > true. > > http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example03/package.html > > The LIPS go down because setTimeout() is clamped by 4ms in > the browser, and I do ca. 60x per Second setTimeout(). To give the > browser the opportunity to do his own stuff. > > Mostowski Collapse schrieb am Freitag, 4. Februar 2022 um 12:18:50 UTC+1: >> If I dont stop now, in a few days I will have an >> Erlang system running. What already works is >> a yielding engine in the Browser. >> >> Non-Blocking Browser for Dogelog Player >> https://twitter.com/dogelogch/status/1489350992793677827 >> >> Non-Blocking Browser for Dogelog Player >> https://www.facebook.com/groups/dogelog >> >> With video recording and funky background >> sound! Next will be bring this yielding engine >> node.js and to Python as well.
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-08 13:23 -0800 |
| Message-ID | <94f2c74b-f639-43f7-b0a7-3fb19474b8b6n@googlegroups.com> |
| In reply to | #12579 |
Since idiotic Tau Prolog is horsing around: https://github.com/tau-prolog/tau-prolog/issues/291 Here my response: Thats not what Erlang did. In Erlang there was a counter and long running actors were automatically yielded. You can lookup the Erlang documentation if you don't believe me. Your suggestions from using sleep/1 to the other suggestion to pressing enter in the top-level are ridiculous, you seem not to understand what a yielding engine is. Maybe hold back your nonsense suggestion and only respond when you have a solution, or when a solution is dismissed for some reasons. But I don't know why a yielding engine should be imposible? I just had a look at your source code, especially your async protocol with return true and again(). Quite impressive and relatively simple solution. Maybe because catch/3 creates another thread via new Thread() ? I don't know what the technical issue is that after all these years a yielding engine isn't available? Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 15:06:16 UTC+1: > Maybe I should show a spinning wheel or > something, while the thingy runs? The color > change in the button is nearly not seen... > > Mostowski Collapse schrieb: > > It will take some time until I have an Erlang system. > > The small things use a lot of time. Now I have > > an non-async/await Sandbox and a async/await Sandbox > > > > online. The Audio Player example allows playing with > > the async/await Sandbox. The Audio Example will > > disable the Tryit button and enable it again, when finished. > > > > But its non-blocking, you can interact with the browser, > > and it will not show the warning display in Chrome. Unfortunately > > there is still an unsolved problem, the LIPS go down. > > > > But this here works fine: > > > > longrunning :- > > between(1,300,_), > > between(1,300,_), > > between(1,300,_), > > fail. > > longrunning. > > > > ?- time(longrunning). > > % Wall 37203 ms, gc 25 ms, 2206445 lips > > true. > > > > http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example03/package.html > > > > The LIPS go down because setTimeout() is clamped by 4ms in > > the browser, and I do ca. 60x per Second setTimeout(). To give the > > browser the opportunity to do his own stuff. > > > > Mostowski Collapse schrieb am Freitag, 4. Februar 2022 um 12:18:50 UTC+1: > >> If I dont stop now, in a few days I will have an > >> Erlang system running. What already works is > >> a yielding engine in the Browser. > >> > >> Non-Blocking Browser for Dogelog Player > >> https://twitter.com/dogelogch/status/1489350992793677827 > >> > >> Non-Blocking Browser for Dogelog Player > >> https://www.facebook.com/groups/dogelog > >> > >> With video recording and funky background > >> sound! Next will be bring this yielding engine > >> node.js and to Python as well.
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-08 13:35 -0800 |
| Message-ID | <cffd0ca3-ae91-45c3-941d-357fbb16ea5cn@googlegroups.com> |
| In reply to | #12580 |
Again, whats so difficult in providing a yielding engine? One can make it configurable, shouldn't be a problem for somebody with that programming skills. I have it easily switchable on and off: /* Switch yielding engine on */ set_gc_flags(gc_flags | GC_MASK_ASYNC); Maybe its some mental blockage? Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:23:17 UTC+1: > Since idiotic Tau Prolog is horsing around: > https://github.com/tau-prolog/tau-prolog/issues/291 > > Here my response: > > Thats not what Erlang did. In Erlang there was a counter and long > running actors were automatically yielded. You can lookup the > Erlang documentation if you don't believe me. > > Your suggestions from using sleep/1 to the other suggestion to > pressing enter in the top-level are ridiculous, you seem not to > understand what a yielding engine is. > > Maybe hold back your nonsense suggestion and only respond > when you have a solution, or when a solution is dismissed for > some reasons. But I don't know why a yielding engine should > > be imposible? I just had a look at your source code, especially > your async protocol with return true and again(). Quite impressive > and relatively simple solution. Maybe because catch/3 creates > > another thread via new Thread() ? I don't know what the technical > issue is that after all these years a yielding engine isn't available?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-08 13:42 -0800 |
| Message-ID | <93d9c233-ebc8-41f0-bce9-134b89c1c6d1n@googlegroups.com> |
| In reply to | #12581 |
The next step is make it cancellable. So you would have maybe some way in the GUI to cancel an engine. But this would be most effective if it is combined with AbortController stuff from node.js. Not sure what the browser offers. Did not yet work on this. But since in a non-blocking sandbox the GUI remains responsive, you can have a GUI control similar to Ctrl-C that one is used from SWI-Prolog. Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:35:58 UTC+1: > Again, whats so difficult in providing a yielding engine? > > One can make it configurable, shouldn't be a problem for > somebody with that programming skills. > > I have it easily switchable on and off: > > /* Switch yielding engine on */ > set_gc_flags(gc_flags | GC_MASK_ASYNC); > > Maybe its some mental blockage? > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:23:17 UTC+1: > > Since idiotic Tau Prolog is horsing around: > > https://github.com/tau-prolog/tau-prolog/issues/291 > > > > Here my response: > > > > Thats not what Erlang did. In Erlang there was a counter and long > > running actors were automatically yielded. You can lookup the > > Erlang documentation if you don't believe me. > > > > Your suggestions from using sleep/1 to the other suggestion to > > pressing enter in the top-level are ridiculous, you seem not to > > understand what a yielding engine is. > > > > Maybe hold back your nonsense suggestion and only respond > > when you have a solution, or when a solution is dismissed for > > some reasons. But I don't know why a yielding engine should > > > > be imposible? I just had a look at your source code, especially > > your async protocol with return true and again(). Quite impressive > > and relatively simple solution. Maybe because catch/3 creates > > > > another thread via new Thread() ? I don't know what the technical > > issue is that after all these years a yielding engine isn't available?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-08 13:48 -0800 |
| Message-ID | <cb4d0cda-50b3-4ad7-9af3-240a3582a064n@googlegroups.com> |
| In reply to | #12582 |
So maybe lets start all-over and read my question in the ticket again. How do your answers respond to my question: > Is there another sandbox already online? I don't want to change my Prolog code. And I don't want to code a sandbox in JavaScript. I understand that on the other hand it seems a yielding engine is already there, by for example hooking into the limit callback for example. But I don't find it somewhere already wrapped into a sandbox. Or maybe there is some other URL out in the wild? Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:42:03 UTC+1: > The next step is make it cancellable. So you would have > maybe some way in the GUI to cancel an engine. But this > would be most effective if it is combined with AbortController > > stuff from node.js. Not sure what the browser offers. > Did not yet work on this. But since in a non-blocking sandbox > the GUI remains responsive, you can have a GUI control > > similar to Ctrl-C that one is used from SWI-Prolog. > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:35:58 UTC+1: > > Again, whats so difficult in providing a yielding engine? > > > > One can make it configurable, shouldn't be a problem for > > somebody with that programming skills. > > > > I have it easily switchable on and off: > > > > /* Switch yielding engine on */ > > set_gc_flags(gc_flags | GC_MASK_ASYNC); > > > > Maybe its some mental blockage? > > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:23:17 UTC+1: > > > Since idiotic Tau Prolog is horsing around: > > > https://github.com/tau-prolog/tau-prolog/issues/291 > > > > > > Here my response: > > > > > > Thats not what Erlang did. In Erlang there was a counter and long > > > running actors were automatically yielded. You can lookup the > > > Erlang documentation if you don't believe me. > > > > > > Your suggestions from using sleep/1 to the other suggestion to > > > pressing enter in the top-level are ridiculous, you seem not to > > > understand what a yielding engine is. > > > > > > Maybe hold back your nonsense suggestion and only respond > > > when you have a solution, or when a solution is dismissed for > > > some reasons. But I don't know why a yielding engine should > > > > > > be imposible? I just had a look at your source code, especially > > > your async protocol with return true and again(). Quite impressive > > > and relatively simple solution. Maybe because catch/3 creates > > > > > > another thread via new Thread() ? I don't know what the technical > > > issue is that after all these years a yielding engine isn't available?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-08 16:17 -0800 |
| Message-ID | <1d869c34-e4eb-4e93-898e-0b01f3ffb09dn@googlegroups.com> |
| In reply to | #12583 |
Woa! That was quick, there is now a stop option: https://github.com/tau-prolog/sandbox/issues/10 I always admire Steve Jobs, how he introduced the MacIntosh with a mouse that only had one button. Those times there were mouses with 3 buttons. So currently trying to figure out what a good GUI would be. I cannot speak for Tau Prolog. But in my system Limit is a system resource, that the end-user has nothing to do with. It is planned that for non-blocking via some auto-tuning the optimal value is found. Browsers have a certain affinity to 60 frames per second.(*) Not yet sure how this turns out. For the control buttons, I am rather think of something else. Don't know yet what. Was just having a look at SWISH, it shows me an animation and an abort button. Maybe thats where I got the animation idea from. after a while it shows stats. the abort button shows again after redo. (*) I found some docu about that. A browser might also updrade or downgrade the frequency. There is also something related to animation, called requestAnimationFrame(), but this is probably not needed for DOM updates. Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:48:36 UTC+1: > So maybe lets start all-over and read my question in the > ticket again. How do your answers respond to my question: > > Is there another sandbox already online? > > I don't want to change my Prolog code. > And I don't want to code a sandbox in JavaScript. > > I understand that on the other hand it seems a yielding > engine is already there, by for example hooking into > the limit callback for example. But I don't find it > > somewhere already wrapped into a sandbox. Or > maybe there is some other URL out in the wild? > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:42:03 UTC+1: > > The next step is make it cancellable. So you would have > > maybe some way in the GUI to cancel an engine. But this > > would be most effective if it is combined with AbortController > > > > stuff from node.js. Not sure what the browser offers. > > Did not yet work on this. But since in a non-blocking sandbox > > the GUI remains responsive, you can have a GUI control > > > > similar to Ctrl-C that one is used from SWI-Prolog. > > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:35:58 UTC+1: > > > Again, whats so difficult in providing a yielding engine? > > > > > > One can make it configurable, shouldn't be a problem for > > > somebody with that programming skills. > > > > > > I have it easily switchable on and off: > > > > > > /* Switch yielding engine on */ > > > set_gc_flags(gc_flags | GC_MASK_ASYNC); > > > > > > Maybe its some mental blockage? > > > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:23:17 UTC+1: > > > > Since idiotic Tau Prolog is horsing around: > > > > https://github.com/tau-prolog/tau-prolog/issues/291 > > > > > > > > Here my response: > > > > > > > > Thats not what Erlang did. In Erlang there was a counter and long > > > > running actors were automatically yielded. You can lookup the > > > > Erlang documentation if you don't believe me. > > > > > > > > Your suggestions from using sleep/1 to the other suggestion to > > > > pressing enter in the top-level are ridiculous, you seem not to > > > > understand what a yielding engine is. > > > > > > > > Maybe hold back your nonsense suggestion and only respond > > > > when you have a solution, or when a solution is dismissed for > > > > some reasons. But I don't know why a yielding engine should > > > > > > > > be imposible? I just had a look at your source code, especially > > > > your async protocol with return true and again(). Quite impressive > > > > and relatively simple solution. Maybe because catch/3 creates > > > > > > > > another thread via new Thread() ? I don't know what the technical > > > > issue is that after all these years a yielding engine isn't available?
[toc] | [prev] | [next] | [standalone]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2022-02-08 16:34 -0800 |
| Message-ID | <cd6b0691-c25c-4867-917b-7d48340b2798n@googlegroups.com> |
| In reply to | #12584 |
Does your browser stutter? https://www.testufo.com/animation-time-graph Mostowski Collapse schrieb am Mittwoch, 9. Februar 2022 um 01:17:13 UTC+1: > Woa! That was quick, there is now a stop option: > https://github.com/tau-prolog/sandbox/issues/10 > > I always admire Steve Jobs, how he introduced the MacIntosh > with a mouse that only had one button. Those times there were > mouses with 3 buttons. > > So currently trying to figure out what a good GUI would be. > I cannot speak for Tau Prolog. But in my system Limit is a > system resource, that the end-user has nothing > > to do with. It is planned that for non-blocking via some > auto-tuning the optimal value is found. Browsers have > a certain affinity to 60 frames per second.(*) > > Not yet sure how this turns out. For the control buttons, > I am rather think of something else. Don't know yet what. > Was just having a look at SWISH, > > it shows me an animation and an abort button. Maybe > thats where I got the animation idea from. after a while > it shows stats. the abort button shows again after redo. > > (*) > I found some docu about that. A browser might also updrade > or downgrade the frequency. There is also something related > to animation, called requestAnimationFrame(), but this is > > probably not needed for DOM updates.
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.prolog
csiph-web