Groups | Search | Server Info | Login | Register
Groups > comp.lang.misc > #11414
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: Algol 68 / Genie - new release |
| Date | 2025-10-11 00:05 +0000 |
| Organization | To protect and to server |
| Message-ID | <10cc6vc$21tdl$1@paganini.bofh.team> (permalink) |
| References | (10 earlier) <10btkhq$3ao5s$1@dont-email.me> <10c6h3e$18jia$1@paganini.bofh.team> <10c6lom$1sopd$1@dont-email.me> <10ca1ff$1p1d3$1@paganini.bofh.team> <10cb8ae$4hse$1@dont-email.me> |
bart <bc@freeuk.com> wrote:
> On 10/10/2025 05:18, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
<snip>
>>>
>>> Last week I posted a link to a 'man or boy' test; this a version in C:
>>>
>>> https://rosettacode.org/wiki/Man_or_boy_test#C
>>>
>>> This test requires local functions with full closures to implement
>>> natively. The first C version emulates what is needed.
>>>
>>> I tweaked that version so that is used N=13 instead of N=10, and
>>> evaluates the function 10,000 times. The second version uses C
>>> extensions to provide the higher level functionality.
>>>
>>> These are timings I got for the two versions:
>>>
>>> First C version (gcc -O2: 0.8 seconds
>>> (Tiny C): 1.8 seconds
>>> Second C version (gcc -O2): 590 seconds (extrapolated from 1K loops)
>>> (gcc -O0): 940 seconds
>>>
>>> So avoiding those complex functional features makes even TCC's poor code
>>> 300 times that optimised C. And nearly 800:1 better comparing -O2 with -O2.
>>
>> It is not clear to me what you measure. I used:
>>
>> #include <stdio.h>
>> #define INT(body) ({ int lambda(){ body; }; lambda; })
>> int
>> main(){
>> int a(int k, int xl(), int x2(), int x3(), int x4(), int x5()){
>> int b(){
>> return a(--k, b, xl, x2, x3, x4);
>> }
>> return k<=0 ? x4() + x5() : b();
>> }
>> int res = 0;
>> int i;
>> for(i = 0; i < 10000; i++) {
>> res += a(13, INT(return 1), INT(return -1), INT(return -1), INT(return
>> 1), INT(return 0));
>> }
>> printf("res = %d\n", res);
>> }
>>
>> Compiling this using:
>>
>> gcc -O -Wall man1.c -o man1
>>
>> I get 0.895s. Using -O2 I get 0.693s. Version without loop, but using
>> 13 as an argument (as above) takes 0.002s. This is on a fast machine,
>> on really slow mini-PC I get 10.117s at -O2. I suspect that your time is
>> due to operationg system, the results above are for Linux on x86_64.
>> On Linux on 1GHz Risc-V at -O2 I get:
>>
>> real 0m28.910s
>> user 0m14.512s
>> sys 0m14.381s
>>
>> which means that about half of execution time is in system calls.
>> Looking at assembly shows that the machine code is calling
>> '__riscv_flush_icache', that is it flushing cache to make sure
>> that processor will execute freshly generated instructions
>> (not needed on PC-s). System calls are expensive, and flushing
>> cache also adds slowdown, so this adds substantial cost. Still,
>> the Risc-V machine is quite slow, and can do this much faster
>> than your estimate of execution time.
>>
>> For me on fast machine first (emulated) version takes 0.331s when
>> compiled by gcc at -O2 and 0.767s when compiled by tcc. On Risc-V
>> emulated version (compiled by gcc -O2) needs 3.553s.
>>
>> So emulated version is clearly faster, especially if version
>> using nested functions need support from operating system.
>>
>> But the point of using nested functions/closures is that code
>> is simpler.
>
> Well, the code is smaller; that doesn't mean it is simpler! It can be
> harder to know what's going on with a cryptic bit of code like this.
>
> (I believe it was Knuth who failed to correctly predict the result of
> N=10 (?), at some point in history when computing it was not practical.)
As I wrote below, this test is doing nonsense operation. Most real
uses of higher order functions are simpler (some higher order may
even disregard them as too simple). For example, you want to
perform some operation on all elements of an aggregate. For a list
one can have mostly standard C code like:
typedef struct gen_lst gen_lst;
struct gen_lst {gen_lst * next;};
void
gen_map(void (*f)(gen_lst * lst, void * extra), gen_lst * lst, void * extra) {
for(; lst; lst = lst->next) {
f(lst, extra);
}
}
typedef struct my_lst my_lst;
struct my_lst {gen_lst * next; int val;};
void
adder1(gen_lst * lst, void * extra) {
int * aux = extra;
struct my_lst * ml = (struct my_lst *)lst;
aux += ml->val;
}
int
my_sum(my_lst * lst) {
int aux = 0;
gen_map(adder1, (gen_lst *) lst, (void *)&aux);
return aux;
}
or you can use gcc extention like:
void
gen_map2(void (*f)(gen_lst * lst), gen_lst * lst) {
for(; lst; lst = lst->next) {
f(lst);
}
}
int
my_sum2(my_lst * lst) {
int aux = 0;
void
adder(gen_lst * lst) {
struct my_lst * ml = (struct my_lst *)lst;
aux += ml->val;
}
gen_map2(adder, (gen_lst *) lst);
return aux;
}
Note that argument 'extra' is now gone.
Of course, you my ask why I do computations in this way? If all what
needs to be done is computing sum of elements on a list, than a single
function would do. However, if there are more operations, then
using several looping functions spead knowledge how 'gen_lst' is
build and how to traverse it. Which may be not that bad if you
are sure that it will always be a list and all you need is summing.
But you may need more complex aggregate or multiple kinds of aggregates.
Typically there are several operations one wants to do for each
kind of aggregate. And general part may be much larger than type
specific part. With approach as above you only need to write
type specific operations for each kind of aggregate, general parts
may be reused. And depending on details it may be possible to
share operations for different kinds of aggregates.
I do not know if you believe that this kind of coding is useful,
but I hope that it is clear that variant using nested functions
will always be simpler than variant which passes extra arguments.
>> The test is doing nonsense operation, so one
>> can miss simplicty, but clearly emulated version is longer.
>> More important, in bigger program all involved calls must be
>> dane in nonstandard way, which adds work (potentially quite a lot).
>> In version with nested functions only efort is in definition
>> of nested functions, calls are standard calls and rest of program
>> can be written as if there were no use of nested functions.
>>
>> As you can see, when properly supported extra cost of nested
>> functions is moderate.
>>
>> BTW: Some language implementation use approach which is
>> equivalent to emulated version. For heavy use of nested
>> functions this may lead to faster code (like in this example).
>> But when "emulation" is part of language implementation
>> all calls would need to do extra work, slowing down normall
>> calls. In language like C this is deemed unacceptable,
>> nested function are rarely use so they must pay extra,
>> while normal call work at maximal speed.
>>
>
> I'm testing the version show below (I added the += to make it match
> yours). Results on Windows are:
>
> c:\c>gc d opt
> Invoking: gcc -s -O2 d.c -o d.exe -lm -ldl -fno-strict-aliasing
> Compiled d.c to d.exe
>
> c:\c>tm d
> -64200
>
> TM: 6.01
>
> So 6 seconds to do 100 iterations. If I try it in WSL, using 10000
> iterations, then I get:
>
> c:\c>wsl
> root@DESKTOP-11:/mnt/c/c# gcc -O2 d.c -od
> root@DESKTOP-11:/mnt/c/c# time ./d
> -6420000
>
> real 0m1.184s
> user 0m1.180s
> sys 0m0.001s
>
> So under WSL it's 500 times faster. I've no idea why.
I see. It is up to you to decide if you want to investigate deeper.
Linux version generates small pieces of executable code on the
stack. Currently security folks hate such code and want to ban
it. In Linux gcc specially marks executable needing executable
stack and if executable is marked kernel allow executing code
from the stack. Otherwise attempts to execute code from the
stack lead to exception and kernel signals error in such case.
There was some talk to use different method, and code generated
on Windows may be different. One possible implementation would
be to attempt execution on the stack, but also install signal
handler. Signal handler can then effectively interpret was in
on the stack. Clearly this would lead to much worse performance.
> However, I work under Windows! So do lots of people. And there, the fact
> that these exotic features might make programs significantly slower has
> to be taken into consideration.
>
> I tried a Python version too. There, 200 iterations took 5.4 seconds on
> both OSes. PyPy on Windows was twice as fast.
Once you have interpreted language you get slowdown from the
interpreter, but no extra trouble due executable stack: CPU treats
bytecode as data, so in this way one can bypass security restrictions.
IIUC PyPy may generate machine code, but probably can defer anything
it can not handle to interpreter.
Similarly, if language have garbage collection, then one can
create functions in special part of the heap. During function
creation needed part of heap is marked as writable and non-executable,
once the function is created corresponding part of the heap is marked
as non-writeable and executable satisfaing security demands at
cost of 2 system calls per function created. When no longer
needed function is garbage collected in usual way. Note that
stack normally must be writable all the time, so with code on
the stack there is risk of executing malicious data.
--
Waldek Hebisch
Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar
Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-23 06:49 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-23 15:22 +0100
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-23 17:49 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-24 00:58 +0100
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-25 01:49 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-26 23:53 +0100
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-23 19:28 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-24 00:27 +0100
Re: Algol 68 - formatting with fixed point format Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-24 02:49 +0000
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-25 01:57 +0200
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-25 02:14 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-27 00:58 +0100
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-27 08:23 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-27 23:23 +0100
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-28 07:35 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-29 00:43 +0100
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-30 05:40 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-30 20:38 +0100
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 10:10 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-09-01 17:20 +0100
Algol 68 / Genie - new release (was Re: Algol 68 - formatting with fixed point format) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-02 00:56 +0200
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-02 01:15 +0200
Re: Algol 68 / Genie - new release (was Re: Algol 68 - formatting with fixed point format) Andy Walker <anw@cuboid.co.uk> - 2025-09-02 17:02 +0100
Re: Algol 68 / Genie - new release (was Re: Algol 68 - formatting with fixed point format) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-02 22:17 +0200
Re: Algol 68 / Genie - new release (was Re: Algol 68 - formatting with fixed point format) Andy Walker <anw@cuboid.co.uk> - 2025-09-04 17:01 +0100
Re: Algol 68 / Genie - new release (was Re: Algol 68 - formatting with fixed point format) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-05 04:32 +0200
Re: Algol 68 / Genie - new release (was Re: Algol 68 - formatting with fixed point format) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-02 23:04 +0000
Re: Algol 68 / Genie - new release (was Re: Algol 68 - formatting with fixed point format) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-03 01:46 +0200
Re: Algol 68 / Genie - new release (was Re: Algol 68 - formatting with fixed point format) Andy Walker <anw@cuboid.co.uk> - 2025-09-04 00:30 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-10 17:15 +0200
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-09-10 23:57 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-11 07:27 +0200
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-11 09:42 +0200
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-09-11 17:16 +0100
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-09-27 00:41 +0100
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-09-27 14:38 +0100
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-09-29 01:15 +0100
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-09-29 16:05 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-29 18:57 +0200
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-09-30 15:58 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-30 17:48 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-09-29 19:08 +0100
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-09-30 23:23 +0100
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-01 23:00 +0100
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-10-02 16:55 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-02 21:51 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-04 12:38 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-04 14:04 +0200
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-10-04 13:47 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-04 15:03 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-04 15:07 +0100
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-10-04 18:40 +0100
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-04 19:46 +0100
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-10-07 16:37 +0100
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-07 17:16 +0100
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-10-07 23:58 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 01:20 +0200
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-10-08 16:10 +0100
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-08 17:41 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 00:53 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-09 01:02 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 01:09 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-07 22:27 +0100
Re: Algol 68 / Genie - new release richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-08 00:20 +0000
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-04 22:00 +0000
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-05 00:31 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-05 01:52 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-05 03:15 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-05 11:05 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-05 20:20 +0000
Re: Algol 68 / Genie - new release David Brown <david.brown@hesbynett.no> - 2025-10-06 09:44 +0200
Higher order functions (was Re: Algol 68 / Genie - new release) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-06 10:01 +0200
Re: Higher order functions (was Re: Algol 68 / Genie - new release) David Brown <david.brown@hesbynett.no> - 2025-10-06 10:56 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-06 11:03 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-06 22:01 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-06 23:46 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-06 23:05 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-07 10:32 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-08 04:57 +0000
Re: Algol 68 / Genie - new release David Brown <david.brown@hesbynett.no> - 2025-10-05 13:24 +0200
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-08 20:21 +0000
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-08 21:30 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-08 22:40 +0100
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-10 04:18 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-10 16:21 +0100
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-11 00:05 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-11 11:25 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-11 13:08 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-11 15:25 +0100
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-11 12:39 +0000
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 00:34 +0200
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-09 03:15 +0000
Re: Algol 68 / Genie - new release ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-09 08:59 +0000
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-09 14:31 +0000
Re: Algol 68 / Genie - new release ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-09 14:53 +0000
Re: Algol 68 / Genie - new release ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-09 10:35 +0000
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 21:37 +0000
Re: Algol 68 / Genie - new release David Brown <david.brown@hesbynett.no> - 2025-10-10 17:40 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-10 20:04 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-10 21:45 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-11 00:29 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-11 00:16 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-11 01:59 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-11 01:42 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-11 10:42 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-31 06:51 +0000
Re: Algol 68 / Genie - new release David Brown <david.brown@hesbynett.no> - 2025-10-13 20:58 +0200
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-13 23:13 +0100
Re: Algol 68 / Genie - new release David Brown <david.brown@hesbynett.no> - 2025-10-14 00:39 +0200
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-12 03:56 +0000
Re: Algol 68 / Genie - new release David Brown <david.brown@hesbynett.no> - 2025-10-13 22:38 +0200
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-24 04:33 +0000
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-03 22:24 +0000
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-04 03:39 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-04 12:19 +0100
Re: Algol 68 / Genie - new release Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-04 14:16 +0200
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-04 21:05 +0000
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-05 01:40 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-05 03:13 +0000
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-05 01:29 +0000
Re: Algol 68 / Genie - new release Andy Walker <anw@cuboid.co.uk> - 2025-10-07 15:25 +0100
Re: Algol 68 / Genie - new release bart <bc@freeuk.com> - 2025-10-07 17:03 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-07 22:09 +0000
Re: Algol 68 / Genie - new release Adam Sampson <ats@offog.org> - 2025-10-08 18:22 +0100
Re: Algol 68 / Genie - new release Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-08 21:48 +0000
Re: Algol 68 / Genie - new release antispam@fricas.org (Waldek Hebisch) - 2025-10-08 23:45 +0000
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-30 06:54 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-08-31 00:44 +0100
Re: Algol 68 - formatting with fixed point format Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 08:12 +0000
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 10:42 +0200
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-09-01 00:10 +0100
Re: Algol 68 - formatting with fixed point format Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-01 07:30 +0000
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-09-01 16:13 +0100
Re: Algol 68 - formatting with fixed point format Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-01 22:41 +0000
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-09-02 14:23 +0100
Re: Algol 68 - formatting with fixed point format Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-02 23:08 +0000
Re: Algol 68 - formatting with fixed point format Andy Walker <anw@cuboid.co.uk> - 2025-09-04 00:54 +0100
Re: Algol 68 - formatting with fixed point format Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 10:29 +0200
Re: Algol 68 - formatting with fixed point format Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-24 02:47 +0000
csiph-web