Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.lisp > #60742 > unrolled thread
| Started by | Mario Rosell <mario@mariorosell.es> |
|---|---|
| First post | 2026-02-20 22:53 +0100 |
| Last post | 2026-06-03 03:16 +0000 |
| Articles | 20 on this page of 158 — 20 participants |
Back to article view | Back to comp.lang.lisp
Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-20 22:53 +0100
Re: Resources to learn common lisp? Ben Bacarisse <ben@bsb.me.uk> - 2026-02-20 22:00 +0000
Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:25 +0100
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-02-21 10:24 -0500
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-21 21:30 +0000
Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-22 01:08 +0100
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-22 04:59 +0000
Re: Resources to learn common lisp? Madhu <enometh@meer.net> - 2026-02-22 10:59 +0530
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-22 21:48 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:43 -0400
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:41 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-08 20:02 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-09 00:23 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:28 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:32 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:27 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:33 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:16 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:53 +0000
Re: Resources to learn common lisp? Axel Reichert <mail@axel-reichert.de> - 2026-06-09 12:07 +0200
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:14 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-17 00:01 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 05:53 +0000
[OT] Disappearing documentation (was: Re: Resources to learn common lisp?) Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-17 09:06 +0100
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:22 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:59 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 01:43 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:45 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:35 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:37 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:33 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-09 00:22 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-09 01:22 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:17 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:50 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:40 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:26 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:10 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 21:37 -0700
Re: Resources to learn common lisp? Joerg Mertens <joerg-mertens@t-online.de> - 2026-06-17 12:04 +0200
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-17 11:17 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 13:57 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:06 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 09:17 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 13:32 +0000
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:27 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:12 -0400
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:24 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:57 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-11 21:07 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 13:06 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:13 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 07:25 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 08:25 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:46 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:52 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:57 +0000
Re: Resources to learn common lisp? Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-15 10:10 +0100
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:56 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:03 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 07:52 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 20:56 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-13 00:55 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 07:43 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:37 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:09 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:02 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 10:12 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:54 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-17 00:07 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 08:33 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 12:42 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 23:32 -0400
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-09 09:36 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:06 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-10 08:43 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:22 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-11 08:57 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:16 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:42 -0400
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 01:15 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 05:42 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 11:19 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:18 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-16 03:27 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 01:25 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 10:13 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 13:57 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:11 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-18 02:30 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 09:32 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 14:15 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 23:53 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 05:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-17 01:43 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:07 +0000
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 06:37 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:30 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:58 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 01:46 -0700
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-15 06:59 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-15 12:25 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:42 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:16 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 12:34 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:11 +0000
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-13 04:06 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:37 -0700
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 21:25 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 15:26 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:37 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 01:34 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 05:43 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 11:23 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:23 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-16 03:29 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 04:59 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 15:10 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 13:34 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:36 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:43 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-14 10:36 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 23:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 18:04 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 12:33 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-15 09:51 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:23 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 03:14 -0700
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 15:29 -0700
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-16 10:23 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 21:34 -0700
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-17 15:02 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 04:14 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 13:14 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 02:30 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 15:34 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:22 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:55 +0000
Re: Resources to learn common lisp? tpeplt <tpeplt@gmail.com> - 2026-02-20 17:44 -0500
Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:30 +0100
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-20 23:50 +0000
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-21 00:24 +0000
Re: Resources to learn common lisp? Andreas Eder <a_eder_muc@web.de> - 2026-02-21 11:36 +0100
Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:44 +0100
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-03-31 17:47 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 23:41 +0000
Re: Resources to learn common lisp? tpeplt <tpeplt@gmail.com> - 2026-04-01 13:23 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:59 -0400
Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 10:52 -0400
Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 10:57 -0400
Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 11:06 -0400
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-01 14:56 -0400
Re: Resources to learn common lisp? "Robert B. Carleton" <rbc@rbcarleton.net> - 2026-06-01 23:02 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-02 21:32 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-03 03:16 +0000
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-16 11:46 +0000 |
| Message-ID | <110rd25$137br$2@dont-email.me> |
| In reply to | #60888 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > Resources”: this makes it clear that concurrent “processes” (i.e. > threads) cannot safely share access to global objects without explicit > locking: > That is nothing, nothing at all, to do with reference counting. It's to do with handling shared resources which is a famously hard problem which, surprise, Interlisp-D did not solve. -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-18 01:03 +0000 |
| Message-ID | <110vg5d$292a0$1@dont-email.me> |
| In reply to | #60922 |
On Tue, 16 Jun 2026 11:46:13 -0000 (UTC), tfb wrote: > Lawrence D´Oliveiro <ldo@nz.invalid> wrote: >> >> Resources”: this makes it clear that concurrent “processes” (i.e. >> threads) cannot safely share access to global objects without >> explicit locking: > > That is nothing, nothing at all, to do with reference counting. It's > to do with handling shared resources which is a famously hard > problem which, surprise, Interlisp-D did not solve. So what was that you said earlier: “so chances are it was quite a lot cleverer”?
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-18 07:52 +0000 |
| Message-ID | <1110844$2epdc$1@dont-email.me> |
| In reply to | #60955 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > So what was that you said earlier: “so chances are it was quite a lot > cleverer”? > You said 'Sothey must have had some kind of global lock to ensure the reference counts stayed correct, like Python’s soon-to-be-extinct GIL?' I said 'I don't know. That stuff was all in microcode I think. And unlike Python it wasn't someone's 'my first big program' so chances are it was quite a lot cleverer.' Can you do topic analysis of text? Can you work out that the topic of those sentences was *a lock needed to deal with reference count consistency* and not something else? -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-16 20:56 -0400 |
| Message-ID | <871pe6rnl8.fsf@gmail.com> |
| In reply to | #60863 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > On Fri, 12 Jun 2026 13:06:44 -0000 (UTC), tfb wrote: > >> ... isn't it the case that early machines often ran either with the >> GC disabled or without one at all because it wasn't working yet? > > I recall hearing that the machines would typically run OK for a day or > two before they ran out of memory. Instead of GC, you just rebooted. Thank you! exit and reset baby :) >> The D-machines used reference counting, and the Medley release had a >> pretty competent (pre-ANSI) CL environment. So that's a CL which >> used (uses, even) reference counting, > > Did it do multithreading? take this with a grain of salt: the lisp machine I have was more about parallel operations. you fill two pipelines; if the first does not overflow the machine halts on the second pipeline terminating bignum arithmetic. IMHO
[toc] | [prev] | [next] | [standalone]
| From | Alan Bawden <alan@csail.mit.edu> |
|---|---|
| Date | 2026-06-13 00:55 -0400 |
| Message-ID | <86v7bnrqe2.fsf@williamsburg.bawden.org> |
| In reply to | #60860 |
tfb <no_email@invalid.invalid> writes: > Alan Bawden <alan@csail.mit.edu> wrote: >> Other than those two entries, I don't see much else. > > I think the other thing would be the DYNAMIC-EXTENT declaration, although > that's more about language semantics than anything to do with storage > management. Yeah, that does admit that a Common Lisp implementation probably has both a stack and a heap, and that heap allocation is the norm. But since implementations are allowed to completely ignore DYNAMIC-EXTENT, an implementation remains free to do something completely different! > I didn't use LispMs until much later than you, but isn't it the case that > early machines often ran either with the GC disabled or without one at all > because it wasn't working yet? That would be an implementation (not yet of > CL of course) which had no storage reclamation. There must have been a time when the CONS machine (only one of which was ever built), had no working GC. I don't recall if that was still the case when I joined the project. When I joined, a lot of stuff still wasn't fully working. It was still common in those days to develop code using a compatability layer that ran in MacLisp! But by the time we built the first CADR machine, the GC was working. >> So I don't see anything preventing a Common Lisp or Java implementation from >> doing reference counting, or a Python implementation from _not_ doing >> reference counting. (what's Jython doing after all?) > > The D-machines used reference counting, and the Medley release had a pretty > competent (pre-ANSI) CL environment. So that's a CL which used (uses, > even) reference counting, You mentioned in another thread that Interlisp-D didn't handle cycles as well a you would have liked. I was suprised to read that, because if so, I would expect that those of us at MIT would have never stopped making fun of Interlisp-D for that! Was there some argument for why that wasn't really a problem that we all accepted at the time? Or have I just forgotten knowing that once... -- Alan Bawden
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 07:43 +0000 |
| Message-ID | <110j1m8$2p63h$1@dont-email.me> |
| In reply to | #60864 |
Alan Bawden <alan@csail.mit.edu> wrote: > You mentioned in another thread that Interlisp-D didn't handle cycles as > well a you would have liked. I was suprised to read that, because if > so, I would expect that those of us at MIT would have never stopped > making fun of Interlisp-D for that! Was there some argument for why > that wasn't really a problem that we all accepted at the time? Or have > I just forgotten knowing that once... > I don't know. I was (am) in the UK which was a lot further from things then so I'm not sure how much of a problem it was. In the case I knew about there was some big parser which built a large (by the standards of then) structure with lots of circularities, which you needed to break before dropping it. I think lexical closures in CL leaked as well. I suspect Interlisp (which I don't know well as I always used the CL environment really) was careful not to build circular structure? If I remember I'll ask the Interlisp revival people. -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-16 21:37 -0400 |
| Message-ID | <87qzm6q75r.fsf@gmail.com> |
| In reply to | #60864 |
Alan Bawden <alan@csail.mit.edu> writes: > Was there some argument for why > that wasn't really a problem that we all accepted at the time? Or have > I just forgotten knowing that once... you did not forget you just misused the GC on your brain :)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-13 13:09 -0700 |
| Message-ID | <87tsr68ao2.fsf@nightsong.com> |
| In reply to | #60857 |
Alan Bawden <alan@csail.mit.edu> writes:
> So I don't see anything preventing a Common Lisp or Java
> implementation from doing reference counting, or a Python
> implementation from _not_ doing reference counting. (what's Jython
> doing after all?)
MicroPython in fact uses GC. I would say that old-style Python de facto
assumed reference counting though. People would write:
def foo():
f = open(filename)
do some stuff
return
and rely on the file getting closed when its handle goes out of scope
and its refcount drops to 0. Python later (version 2.5) added "context
managers" aka the "with" statement, which is a type of RAII for stuff
like that. Basically a block of code wrapped in something like
unwind-protect, that initializes something (like a file handle) at the
beginning, and finalizes it in the cleanup action.
The Scheme standards just say the user program sees the illusion of
infinite memory.
There's a notion in the Python world that reference counting somehow
eliminates GC pauses. Of course that's naive, because of what happens
when a large collection gets released.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 01:02 +0000 |
| Message-ID | <110kujv$3a32m$5@dont-email.me> |
| In reply to | #60873 |
On Sat, 13 Jun 2026 13:09:33 -0700, Paul Rubin wrote: > There's a notion in the Python world that reference counting somehow > eliminates GC pauses. Of course that's naive, because of what > happens when a large collection gets released. That’s equivalent to how C would handle it, anyway, and with similar performance. With the new free-multithreading architecture, you can pay the price for that wait on a separate thread, while the rest of your program continues on its merry way. Without the cache-hostile behaviour of a garbage collector.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-16 10:12 +0000 |
| Message-ID | <110r7hn$11hav$1@dont-email.me> |
| In reply to | #60873 |
Paul Rubin <no.email@nospam.invalid> wrote: > There's a notion in the Python world that reference counting somehow > eliminates GC pauses. Of course that's naive, because of what happens > when a large collection gets released. > Seriously. In Interlisp D you could go and make tea when some large object got dropped. Of course 'large' then meant 'significantly larger than physical memory'. -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-16 22:54 -0400 |
| Message-ID | <87v7bhq3kt.fsf@gmail.com> |
| In reply to | #60857 |
Alan Bawden <alan@csail.mit.edu> writes: > steve g <sgonedes1977@gmail.com> writes: > >> Alan Bawden <alan@csail.mit.edu> writes: >> >>> I don't think any of Common Lisp, Java, Perl or Python promise to employ >>> any particular algorithm for collecting garbage. It's not something you >>> really need to put in your language specification document. this would be it. >>> All you >>> need to say is that storage management is not something the programmer >>> needs to worry about. Nothing prevents you from implementing a Common >>> Lisp that does reference counting. yes, I believe sun micro can host DNS for the entire planet, Just like when oracle crashed the stock market because they did not state that inserting SQL requests into the transaction log makes things faster. > That's hilarious. I worked for the Lisp Machine project at MIT back in > the 70's. Back then, Garbage Collection was a pretty hot topic. I did > not work on the Lisp Machine's GC, but I was in the room while other > people worked on it they actually let you into their lab? Quite an acomplishment (no sarcasm). > I'm not sure what I said in the paragraph you quoted above that made you > think I was a "newbie". it seems like you are a trustworthy person. the lab and the office are two different places. > That paragraph was intended to contain the > non-controversial part of what I wanted to say. Can you point to > something in the language definitions for any of those languages that > explicitly requires any particular form of garbage collector? these days your type of GC is an IQ thing, IMHO. > For > Common Lisp, Java or Python there may be things in some runtime > libraries that let you query and control the GC, but the language > specification itself is generally limited in what it says about storage > management. if you do not understand why people deviate from the standard, you will not understand the market value/power of a word. > The Common Lisp standard, for example, tells you that there is a > condition called STORAGE-CONDITION, that might get signaled sometimes > -- so if I run out of memory the computer will use virtual memory instead? > but the description of STORAGE-CONDITION is vague enough that I don't > think you can draw any conclusions about what the underlying storage > manager is doing. I usually get a core dump. > There is also the ROOM function, which promises to > output something useful about storage -- but exactly what that includes > is unspecified. Other than those two entries, I don't see much else. again you seem to be too trusting. What is a brand? "A brand is a promise". > Actually, I can't find anyplace in the Common Lisp standard that even > says outright that a Common Lisp implementation is expected to do > automatic storage management, although that's clearly implied all over > the place. what brand do you believe in? > In contrast the Java language specification says right up front in the > 3rd paragraph of the introduction: > > [Java] includes automatic storage management, typically using a > garbage collector, [...] yeah yeah yeah we all now that newer programming languages usually do better than the older ones; usually due to better hardware. I paid $500.00 per stick of EDO ram. all 4 megabytes. > And the Python language reference says (in the "Data Model" chapter): > > An implementation is allowed to postpone garbage collection or omit > it altogether — it is a matter of implementation quality how garbage > collection is implemented, as long as no objects are collected that > are still reachable. sounds like a marketing droid wrote that. I do not like to combine maybe or should with computer languages because deviating from the standard is a primary means for people to make money by inconveniencing yourself. What version of Visual Basic do you use? I loved visual basic version v6, but it is no longer useful to them, so we are not allowed to use it anymore, despite the fact that it is an excellent language. > So I don't see anything preventing a Common Lisp or Java implementation from > doing reference counting, or a Python implementation from _not_ doing > reference counting. (what's Jython doing after all?) dump your science brain for a second and think like a marketdroid. I feel like this would be hard for you (most programmers are beyond stubborn; which freud considered a compliment). Please as much as I love psychology please do not let this not turn into a freud disagreement. I grew up in a world where losing profits as a corporate officer would result in jail time (like prison).
[toc] | [prev] | [next] | [standalone]
| From | Alan Bawden <alan@csail.mit.edu> |
|---|---|
| Date | 2026-06-17 00:07 -0400 |
| Message-ID | <86ldcdstcd.fsf@williamsburg.bawden.org> |
| In reply to | #60935 |
steve g <Sgonedes1977@gmail.com> writes: > dump your science brain for a second and think like a marketdroid. I > feel like this would be hard for you (most programmers are beyond > stubborn; which freud considered a compliment). Please as much as I love > psychology please do not let this not turn into a freud disagreement. The definition of plonkable.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-17 08:33 +0000 |
| Message-ID | <110tm5j$1nl6a$1@dont-email.me> |
| In reply to | #60940 |
Alan Bawden <alan@csail.mit.edu> wrote: > steve g <Sgonedes1977@gmail.com> writes: > > > The definition of plonkable. > It's nice someone remembers that. I am worried that the monster that once ate CLL has awoken from its slumber though... -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-12 12:42 +0000 |
| Message-ID | <110gus7$26hn2$1@dont-email.me> |
| In reply to | #60842 |
steve g <sgonedes1977@gmail.com> wrote: > > you must be a newbie. > Oh dear oh dear. -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-16 23:32 -0400 |
| Message-ID | <87qzm5q1t2.fsf@gmail.com> |
| In reply to | #60859 |
tfb <no_email@invalid.invalid> writes: > steve g <sgonedes1977@gmail.com> wrote: > >> >> you must be a newbie. >> > > Oh dear oh dear. Please, I just got into big trouble for shooting a deer in the ass with my 2 meter antenna.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-09 09:36 -0400 |
| Message-ID | <jwv5x3rg80j.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60825 |
> Lisp is purely garbage-collected though, isn’t it? Most languages (Lisp included) don't specify how and when unreachable objects are collected, as others pointed out. Actually, most languages don't even specify what counts as "unreachable" (Scheme being one of the exceptions). > Languages like Perl and Python try for a hybrid > reference-counted/garbage-collected approach, for speed and also more > deterministic memory usage in many common scenarios. Probably not "for speed": it takes a significant amount of work to make a reference-counting system that's competitive (speedwise) with a tracing GC, because there tend to be *many* refcount updates (and it gets worse if you support concurrency, where most of those updates need to be made atomic). === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-10 00:06 +0000 |
| Message-ID | <110a9pp$ckmk$6@dont-email.me> |
| In reply to | #60838 |
On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: > On Tue, 9 Jun 2026 00:33:44 -0000 (UTC), Lawrence D’Oliveiro wrote: >> >> Languages like Perl and Python try for a hybrid >> reference-counted/garbage-collected approach, for speed and also >> more deterministic memory usage in many common scenarios. > > Probably not "for speed": it takes a significant amount of work to > make a reference-counting system that's competitive (speedwise) with > a tracing GC, because there tend to be *many* refcount updates (and > it gets worse if you support concurrency, where most of those > updates need to be made atomic). But those refcount updates are on live objects, which means they are more likely to reside in some level of CPU cache. Whereas a garbage collector, by design, is spending much of its time hitting long-dead objects, which would likely have long since disappeared from the cache. That’s going to add an order of magnitude or two to your execution time -- which is why we have caches in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-10 08:43 -0400 |
| Message-ID | <jwvqzmetvqw.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60839 |
>> Probably not "for speed": it takes a significant amount of work to >> make a reference-counting system that's competitive (speedwise) with >> a tracing GC, because there tend to be *many* refcount updates (and >> it gets worse if you support concurrency, where most of those >> updates need to be made atomic). > > But those refcount updates are on live objects, which means they are > more likely to reside in some level of CPU cache. > > Whereas a garbage collector, by design, is spending much of its time > hitting long-dead objects, which would likely have long since > disappeared from the cache. That’s going to add an order of magnitude > or two to your execution time -- which is why we have caches in the > first place. AFAIK, real-life usually disagrees with your analysis, which is why refcount is rarely used in practice for implementations of languages with automatic memory management. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-11 00:22 +0000 |
| Message-ID | <110cv4b$13kte$7@dont-email.me> |
| In reply to | #60845 |
On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: > On Wed, 10 Jun 2026 00:06:17 -0000 (UTC), Lawrence D’Oliveiro wrote: >> >> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: >> >>> Probably not "for speed": it takes a significant amount of work to >>> make a reference-counting system that's competitive (speedwise) >>> with a tracing GC, because there tend to be *many* refcount >>> updates (and it gets worse if you support concurrency, where most >>> of those updates need to be made atomic). >> >> But those refcount updates are on live objects, which means they >> are more likely to reside in some level of CPU cache. >> >> Whereas a garbage collector, by design, is spending much of its >> time hitting long-dead objects, which would likely have long since >> disappeared from the cache. That’s going to add an order of >> magnitude or two to your execution time -- which is why we have >> caches in the first place. > > AFAIK, real-life usually disagrees with your analysis, which is why > refcount is rarely used in practice for implementations of languages > with automatic memory management. Feel free to show any performance measures that back up your claim -- particularly memory usage. I would say the only reason the Python approach hasn’t been done before now is because it’s hard to do -- pure brute-force GC has always simply been the path of least resistance.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-11 08:57 -0400 |
| Message-ID | <jwvjys5teuy.fsf-monnier+comp.lang.lisp@gnu.org> |
| In reply to | #60846 |
Lawrence D’Oliveiro [2026-06-11 00:22:36] wrote: > On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: >> On Wed, 10 Jun 2026 00:06:17 -0000 (UTC), Lawrence D’Oliveiro wrote: >>> On Tue, 09 Jun 2026 09:36:50 -0400, Stefan Monnier wrote: >>>> Probably not "for speed": it takes a significant amount of work to >>>> make a reference-counting system that's competitive (speedwise) >>>> with a tracing GC, because there tend to be *many* refcount >>>> updates (and it gets worse if you support concurrency, where most >>>> of those updates need to be made atomic). >>> >>> But those refcount updates are on live objects, which means they >>> are more likely to reside in some level of CPU cache. >>> >>> Whereas a garbage collector, by design, is spending much of its >>> time hitting long-dead objects, which would likely have long since >>> disappeared from the cache. That’s going to add an order of >>> magnitude or two to your execution time -- which is why we have >>> caches in the first place. >> >> AFAIK, real-life usually disagrees with your analysis, which is why >> refcount is rarely used in practice for implementations of languages >> with automatic memory management. > > Feel free to show any performance measures that back up your claim -- > particularly memory usage. How could memory usage measures back up my claim, which is about speed? === Stefan
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.lisp
csiph-web