Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #4023 > unrolled thread

Re: Postscript in 4tH

Back to article view | Back to comp.lang.postscript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Postscript in 4tH Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-08 02:09 -0300
    Re: Postscript in 4tH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-08 20:34 +0000
      Re: Postscript in 4tH Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-08 22:38 -0300
        Re: Postscript in 4tH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 03:05 +0000
          XML in Pythong (was: Re: Postscript in 4tH) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 15:00 +0800
          Re: Postscript in 4tH Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-10 01:06 -0300
            Re: Postscript in 4tH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 07:38 +0000
            Re: Postscript in 4tH Peter Flass <Peter@Iron-Spring.com> - 2026-09-10 07:39 -0700
        Re: Postscript in 4tH Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 15:15 +0800
          Re: Postscript in 4tH Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-10 01:11 -0300
        Re: Postscript in 4tH anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 07:35 +0000
          Re: Postscript in 4tH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 08:10 +0000
            Re: Postscript in 4tH Hans Bezemer <the.beez.speaks@gmail.com> - 2026-09-10 17:58 +0200
        Re: Postscript in 4tH Paul Rubin <no.email@nospam.invalid> - 2026-09-09 03:01 -0700
      Re: Postscript in 4tH anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 06:42 +0000
        Re: Postscript in 4tH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 08:28 +0000
          Re: Postscript in 4tH anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 10:03 +0000
            Re: Postscript in 4tH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 22:17 +0000
          Re: Postscript in 4tH albert@spenarnc.xs4all.nl - 2026-09-09 14:42 +0200
            Re: Postscript in 4tH antispam@fricas.org (Waldek Hebisch) - 2026-09-09 19:17 +0000
              Re: Postscript in 4tH albert@spenarnc.xs4all.nl - 2026-09-10 12:22 +0200
            Re: Postscript in 4tH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 21:54 +0000
              Re: Postscript in 4tH Paul Rubin <no.email@nospam.invalid> - 2026-09-09 22:14 -0700
              Re: Postscript in 4tH albert@spenarnc.xs4all.nl - 2026-09-10 12:30 +0200
        Re: Postscript in 4tH albert@spenarnc.xs4all.nl - 2026-09-09 14:36 +0200

Page 2 of 2 — ← Prev page 1 [2]

#4044

In article <117sbbg$3qin1$2@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>In comp.lang.forth albert@spenarnc.xs4all.nl wrote:
>> In article <117r5b2$u52n$5@dont-email.me>,
>> Lawrence DÿOliveiro  <ldo@nz.invalid> wrote:
>> <SNIP>
>>>Thatâ??s a limited form of read-only introspection. You couldnâ??t do
>>>transformations on the AST or such, could you? For a start, that would
>>>require dynamic memory allocation, which Forth doesnâ??t have.
>>
>> Infinite memory is as good as dynamic memory. I can expand my Forth
>> to e.g. 128 Gbyte that is for all practical purposes infinite.
>
>Maybe it is enough for use with Forth.  I have a computation that
>runs out of memory in IIRC 100 GB.  I do not think giving it full
>128 GB would make a big difference.  OTOH I am pretty sure that
>this computation is finite, I simply do not know how much it
>needs, maybe 256 GB, maybe terabyte.
>
>More important, if you do not reclaim memory you eventually will
>run out of it.  And modern processors are fast, so it can happen
>faster than you suspect.  Of course, this is matter of programming
>style.  In Lisp program when I monitor memory use I see gigabytes
>allocated in seconds.  Without GC after few minutes all 128 GB
>that I have would be gone.

I plan to use dynamic memory, if and when it becomes a problem
for me. It is Forth filosofy. If the optimiser doesn't get
finished at all, this is a waste of time.

>
>--
>                              Waldek Hebisch
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#4038

On Wed, 09 Sep 2026 14:42:10 +0200, albert wrote:

> On Wed, 9 Sep 2026 08:28:18 -0000 (UTC), Lawrence D’Oliveiro wrote:
>
>> That’s a limited form of read-only introspection. You couldn’t do
>> transformations on the AST or such, could you? For a start, that
>> would require dynamic memory allocation, which Forth doesn’t have.
>
> Infinite memory is as good as dynamic memory. I can expand my Forth
> to e.g. 128 Gbyte that is for all practical purposes infinite. Then
> it is a small change to use ALLOCATE that is not in the kernel of my
> Forth, but it is a loadable extension.

Interestingly enough, some Lisp machines behaved in a similar way.
They lacked garbage collection. After memory became full, you took a
snapshot of all the live objects in your machine state, and rebooted.
Reloading the snapshot left all the garbage behind, so you were able
to resume work from there, until memory filled up again.

Apparently you could typically go for longer than a day before filling
all of memory. Not sure if this was a sign of how large memories had
become by then, or how slow Lisp machines were ...

Still, you get the point that that’s a crude way of managing memory.
It is not good for handling long-running tasks.

Also on modern multitasking systems, you might need to be running
other things simultaneously, besides your Forth or Lisp program. So
having the one process hog all available resources is ... not very
sociable.

[toc] | [prev] | [next] | [standalone]

#4042

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Apparently you could typically go for longer than a day before filling
> all of memory. Not sure if this was a sign of how large memories had
> become by then, or how slow Lisp machines were ...

Lisp code in those days was written to avoid unnecessary allocation.
You'd use imperative-style RPLACA/RPLACD (aka setcar/setcdr) a lot,
nreverse, nconc, that sort of thing.  All not really in the Lisp spirit,
I would say, but it reflected Lisp programming practices from even
earlier and more limited machines.

[toc] | [prev] | [next] | [standalone]

#4045

In article <117ski9$1gjra$2@dont-email.me>,
Lawrence D˙Oliveiro  <ldo@nz.invalid> wrote:
>On Wed, 09 Sep 2026 14:42:10 +0200, albert wrote:
>
>> On Wed, 9 Sep 2026 08:28:18 -0000 (UTC), Lawrence Dā€™Oliveiro wrote:
>>
>>> Thatā€™s a limited form of read-only introspection. You couldnā€™t do
>>> transformations on the AST or such, could you? For a start, that
>>> would require dynamic memory allocation, which Forth doesnā€™t have.
>>
>> Infinite memory is as good as dynamic memory. I can expand my Forth
>> to e.g. 128 Gbyte that is for all practical purposes infinite. Then
>> it is a small change to use ALLOCATE that is not in the kernel of my
>> Forth, but it is a loadable extension.
>
>Interestingly enough, some Lisp machines behaved in a similar way.
>They lacked garbage collection. After memory became full, you took a
>snapshot of all the live objects in your machine state, and rebooted.
>Reloading the snapshot left all the garbage behind, so you were able
>to resume work from there, until memory filled up again.
>
>Apparently you could typically go for longer than a day before filling
>all of memory. Not sure if this was a sign of how large memories had
>become by then, or how slow Lisp machines were ...
>
>Still, you get the point that thatā€™s a crude way of managing memory.
>It is not good for handling long-running tasks.
>
>Also on modern multitasking systems, you might need to be running
>other things simultaneously, besides your Forth or Lisp program. So
>having the one process hog all available resources is ... not very
>sociable.

My context is an optimiser. At one point the result is an optimised
program, that is run, and all resources used by the optimiser can be
released. The optimiser is not run for an undefinite time.

Although garbage collection is convenient, ALLOCATE plus
explicit release will be feasible for an optimiser, as far as I can tell.

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#4035

In article <2026Sep9.084205@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
<SNIP>
>>Also, Forth never heard of homoiconicity ...
>
>The traditional indirect-threaded-code implememtations can be
>considered homoiconic, and I wrote a word in the 1980s that made use
>of this property to show a call graph of Forth words.  Also,
>decompilers made use of this property.

ciforth (computer intelligence Forth) was originally intended
to be a substrate for an intelligence. One of the first design
goals is to understand itself.
I didn't known the term homo-iconic, but is is similar.
For example the ci would write a function and then analyse and speed
up the function. So replacing functions as in actual brain.
(A ci thinks for herself and formulates goals to understand the world
better. The idea is to live in the real world, so giving her internet
access.)
I'm working on an optimiser that leans on this, starting from
assigning properties to individual words that make it possible
All AI aspirations are abandoned, but a reasonable optimiser is
within reach.

See also
https://home.hccnet.nl/a.w.m.van.der.horst/forthlecture6.html

>
>- anton
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.postscript

csiph-web