Groups | Search | Server Info | Login | Register
Groups > comp.lang.misc > #11419
| From | bart <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: Algol 68 / Genie - new release |
| Date | 2025-10-11 11:25 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <10cdb9s$msoj$1@dont-email.me> (permalink) |
| References | (11 earlier) <10c6h3e$18jia$1@paganini.bofh.team> <10c6lom$1sopd$1@dont-email.me> <10ca1ff$1p1d3$1@paganini.bofh.team> <10cb8ae$4hse$1@dont-email.me> <10cc6vc$21tdl$1@paganini.bofh.team> |
On 11/10/2025 01:05, Waldek Hebisch wrote:
> 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.
TBH I found both the C and extended versions hard-going. (The spacing
either side of "*" didn't help!)
I think here you genuinely need better language features, but intuitive
ones that everyone can get their head around.
For this sort of stuff I'd prefer using a higher level language, not a
lower level one with hairy-looking synyax that has higher order
functions bolted on. For example in mine (which is both dynamic and
intepreted) I can sum lists like this:
a := (10,20,30,40)
println reduce(+, a) # shows 100
I think this is typical of scripting languages. In mine however,
'reduce' isn't built-in, I have to implement it in the language itself
like this:
export func reduce(op, a)=
x := head(a)
for y in tail(a) do
x := mapss(op, x, y)
od
x
end
Only 'mapss' is built-in. There is some functional stuff going on here,
but there are no closures in the language.
>> 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.
I haven't implemented closures in a static language. (I got partway in
the dynamic one, but decided it wasn't worth the effort or extra
complexity just to run silly examples like manboy() or twice().)
Anyway, I wouldn't have expected to have to use executable memory.
I *might* have expected to do whatever the emulated version does, which
doesn't need executable memory either!
>> 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.
The interesting thing about the interpreted version, is that my
emulation of closures is so much faster than other interpreted languages
where they are built-in. Because I have to implement them in bytecode,
but those others can use the underlying C or whatever.
Using LuaJIT, a well-regarded and usually well-performing tracing-JIT
product, the 10K x manbody(13) test takes 32 seconds, twice as long as
my own pure interpreter.
(Because the workings are so obscure, I don't know Python/Lua enough to
do emulated versions to see if they are any faster.)
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