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

Groups > comp.lang.lisp > #60742 > unrolled thread

Resources to learn common lisp?

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

Contents

  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? 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? 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? 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? 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? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 13:14 -0700
                            Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

#60879

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>   CPython 3.15 is about 60 percent faster than CPython 3.10. 

That change list is quite interesting though some of it is cringy.  I
havem't really been following Python changes and even my newest
installations (Debian Trixie) are still on 3.13.

I wish we had a way for a running Python image to snapshot itself, like
traditional Lisps did, maybe using something based on CRIU.  Emacs Lisp
initially did this with a Unix hack that it called unexec(), that
eventually became too hard to maintain and was replaced with something
more ad hoc.  But it seems deficient of OS's to not support anything
like that.

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

#60886

On Sat, 13 Jun 2026 15:26:39 -0700, Paul Rubin wrote:

> I wish we had a way for a running Python image to snapshot itself,
> like traditional Lisps did ...

They didn’t care much for version control in those days though, did
they?

How do you compare two snapshots to see what’s different?

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

#60900

Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 13 Jun 2026 15:26:39 -0700, Paul Rubin wrote:
> 
>> I wish we had a way for a running Python image to snapshot itself,
>> like traditional Lisps did ...
> 
> They didn’t care much for version control in those days though, did
> they?
> 
> How do you compare two snapshots to see what’s different?

The the same problem as comparing binaries.  And simplest solution
is to record source version used to produce snapshot (or binary).

-- 
                              Waldek Hebisch

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

#60902

On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>
>> How do you compare two snapshots to see what’s different?
>
> The the same problem as comparing binaries. And simplest solution is
> to record source version used to produce snapshot (or binary).

So, given a binary, how do you know which source version was used to
produce that?

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

#60908

Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote:
> 
>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> How do you compare two snapshots to see what’s different?
>>
>> The the same problem as comparing binaries. And simplest solution is
>> to record source version used to produce snapshot (or binary).
> 
> So, given a binary, how do you know which source version was used to
> produce that?

As I wrote record source version.  Typically done by embedding
git hash of the source tree in the binary.  Look at embedded  
hash and you know.

-- 
                              Waldek Hebisch

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

#60914

On Mon, 15 Jun 2026 11:23:22 -0000 (UTC), Waldek Hebisch wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>
>> On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote:
>>
>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>> How do you compare two snapshots to see what’s different?
>>>
>>> The the same problem as comparing binaries. And simplest solution
>>> is to record source version used to produce snapshot (or binary).
>>
>> So, given a binary, how do you know which source version was used
>> to produce that?
>
> As I wrote record source version. Typically done by embedding git
> hash of the source tree in the binary. Look at embedded hash and you
> know.

How do you verify that hash?

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

#60916

Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 15 Jun 2026 11:23:22 -0000 (UTC), Waldek Hebisch wrote:
> 
>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote:
>>>
>>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>>>
>>>>> How do you compare two snapshots to see what’s different?
>>>>
>>>> The the same problem as comparing binaries. And simplest solution
>>>> is to record source version used to produce snapshot (or binary).
>>>
>>> So, given a binary, how do you know which source version was used
>>> to produce that?
>>
>> As I wrote record source version. Typically done by embedding git
>> hash of the source tree in the binary. Look at embedded hash and you
>> know.
> 
> How do you verify that hash?

What you mean by verify?  Are you concerned with malicious actors
changing binaries?

-- 
                              Waldek Hebisch

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

#60917

On Tue, 16 Jun 2026 03:29:54 -0000 (UTC), Waldek Hebisch wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>
>> On Mon, 15 Jun 2026 11:23:22 -0000 (UTC), Waldek Hebisch wrote:
>>
>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>> On Mon, 15 Jun 2026 01:34:52 -0000 (UTC), Waldek Hebisch wrote:
>>>>
>>>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>>>>
>>>>>> How do you compare two snapshots to see what’s different?
>>>>>
>>>>> The the same problem as comparing binaries. And simplest
>>>>> solution is to record source version used to produce snapshot
>>>>> (or binary).
>>>>
>>>> So, given a binary, how do you know which source version was used
>>>> to produce that?
>>>
>>> As I wrote record source version. Typically done by embedding git
>>> hash of the source tree in the binary. Look at embedded hash and
>>> you know.
>>
>> How do you verify that hash?
>
> What you mean by verify?

Confirm that it was in fact the commit used to create that snapshot.

> Are you concerned with malicious actors changing binaries?

You might say that. I couldn’t possibly comment ...

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

#60925

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>> Are you concerned with malicious actors changing binaries?
> You might say that. I couldn’t possibly comment ...

There's such a thing as signed binaries though they're usually
associated with vendors trying to thwart legitimate users.  Anyway
nothing stops you from doing that.  The snapshots we're discussing
though involves creating a binary the usual way from source code, then
running that binary for a while (e.g. to load modules), and then dumping
the memory region to save a reloadable image.  Obviously those images
could also be version controlled and/or signed.  I don't think it's
commonplace to do that in practice.

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

#60924

Waldek Hebisch <antispam@fricas.org> wrote:

> The the same problem as comparing binaries.  And simplest solution
> is to record source version used to produce snapshot (or binary).
> 

And version control is not what saved images are for, at least today:
they're for delivering programs, and for the same things people use VM
snapshots for now: recovery from disasters and shipping images to different
hardware, for instance.

Instead we all end up using a language which doesn't do that and wrapping
delivered programs in vast layers of what are essentially images, in the
firm of Docker and VMs.


-- 
tfeb.org/computer/

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

#60869

Lawrence D´Oliveiro <ldo@nz.invalid> wrote:

> That’s even worse. That means the live objects have to be moved from
> their existing locations, which might be in the cache, into new
> locations which most likely are not.

How do you think the copying happens?  How does the data you've just
written to its new location manage not to end up in a cache?

I really think you need to read, *and understand* some material on computer
architecture.  I don't know if Hennessy and Patterson is still as good as
it was,  but it's likely a good place to start.  Then implement a simple
two-space copying GC (real examples tend to be so full of low-level
cleverness that it's better to implement a naïve one).  A good way to do
this is to start by writing a program which will defragment objects in
memory: turn a linked list into another one whose links nodes are all
adjacent, say.  When you do that, you'll find you've basically written a
copying GC.

-- 
www.tfeb.org/computer/

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

#60884

On Sat, 13 Jun 2026 08:36:36 -0000 (UTC), tfb wrote:

> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>
>> That’s even worse. That means the live objects have to be moved
>> from their existing locations, which might be in the cache, into
>> new locations which most likely are not.
>
> How do you think the copying happens? How does the data you've just
> written to its new location manage not to end up in a cache?

You need to remember what the cache is for. Having a cache in the
copying path doesn’t somehow magically speed up copying.

And remember, *everything* that is live is being pushed into the cache
by the copying -- including objects that the program wasn’t actually
needing at the moment.

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

#60893

> And remember, *everything* that is live is being pushed into the cache
> by the copying -- including objects that the program wasn’t actually
> needing at the moment.

Yeah, GCs are very costly.  Which makes it all the more amazing that
reference counting is typically even worse.


=== Stefan

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

#60896

On Sun, 14 Jun 2026 10:36:48 -0400, Stefan Monnier wrote:

> Yeah, GCs are very costly. Which makes it all the more amazing that
> reference counting is typically even worse.

Do you have a reference for that? One which shows that heap-intensive
operations are more efficient (size, speed) when doing with a garbage
collector than reference-counting?

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

#60898

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Do you have a reference for that? One which shows that heap-intensive
> operations are more efficient (size, speed) when doing with a garbage
> collector than reference-counting?

Chapter 5 of "The Garbage Collection Handbook" (Jones, Hosking, & Moss
2012) is about reference counting.  Most of what it says about naive
reference counting (like Python's, or C++'s std::shared_ptr) is bad.
The relevant text is a page or so, more than I want to type.  The rest
of the chapter is about ways to get around the deficiencies.

I also looked up Zorn's PhD thesis (about GC performance) from 1988:

https://www2.eecs.berkeley.edu/Pubs/TechRpts/1989/Archive/CSD-89-544.pdf

It says similar things to the GC handbook above:

    Unfortunately, reference counting has fundamental disadvantages.
    First and foremost, reference counting algorithms do not reclaim
    storage allocated in circular structures.  Modifications to the
    traditional algorithm have been suggested to overcome this problem,
    but the performance of the modified algorithm is unacceptably slow.
    As a result, reference counting algorithms are augmented with
    traditional garbage collection algorithms.  A second disadvantage of
    reference counting is that space is required to maintain the count.
    A simple implementation associates a 32-bit count with each object
    and increases the size of each cons object (the most common object
    type) by 50%.  More complex implementations reduce this overhead but
    do not entirely eliminate it.  A third disadvantage of reference
    counting is that it fails to reorganize or compact objects in memory
    and is thus unable to improve the locality of references to those
    objects.  By using generations, garbage collection can signicantly
    improve reference locality, as this thesis shows.  Finally, the most
    signicant advantage of reference counting, that of incrementally
    collecting storage, has also been achieved with garbage collection
    algorithms using incremental and generation techniques.

    Because of these disadvantages, reference counting is not often used
    in modern Lisp and Smalltalk implementations.  Recently, however,
    research with distributed memory computers has sparked renewed
    interest in reference counting algorithms because they allow storage
    deallocation based on local information, instead of the global
    information required by garbage collection.  This dissertation
    focuses entirely on techniques for garbage collection and does not
    consider reference counting any further.

Jones' online GC bibliography has a bunch of entries that mention
reference counting.  Only a few look even slightly relevant, but you
could check them if you want.

https://www.cs.kent.ac.uk/people/staff/rej/cgi-bin/searchbib?pattern=reference+counting

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

#60923

Paul Rubin <no.email@nospam.invalid> wrote:

> 
> Chapter 5 of "The Garbage Collection Handbook" (Jones, Hosking, & Moss
> 2012) is about reference counting.  Most of what it says about naive
> reference counting (like Python's, or C++'s std::shared_ptr) is bad.
> The relevant text is a page or so, more than I want to type.  The rest
> of the chapter is about ways to get around the deficiencies.
> 

You can also just measure stuff.  In the thing I just posted the GC was
called 4,065 times on generation 0.  Each time it found no more than 1,000
live conses each of which is 16 bytes (2 words).  So it copied something
like 65MB.  A better way is probably to say it considered at about 4
million conses.  The program allocated a billion conses, so the GC saw
about 1/250th of them (not coincidentally the GC runtime was about 1/250th
of the total runtime).

A reference counted system would have looked at, *and written the reference
counts of* all billion conses: about 250 times as many as the GC.

I don't have a reference-counted modern Lisp, but it seems deeply
implausible that it would be faster.  If it was faster, it could only
reduce run-time by under 0.5%, because that's what the GC overhead was.

This was for a program which did essentially nothing but allocate memory. 
So it is empirically not the case that GCs are slow for programs which
allocate heavily.  Obviously if you allocate in a way which is
intentionally hostile to the GC *and* you don't tune the GC to deal with
that then they can take longer. LW has extensive support for this: for huge
long-lived allocations you allocate into a generation which the GC does not
look at, and then when you're done you tell it to look at it, once.  I
assume other serious GC'd implementations of Lisp or other languages have
similar tuning options.

-- 
tfeb.org/computer/

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

#60910

Lawrence D’Oliveiro [2026-06-14 23:55:06] wrote:
> On Sun, 14 Jun 2026 10:36:48 -0400, Stefan Monnier wrote:
>> Yeah, GCs are very costly. Which makes it all the more amazing that
>> reference counting is typically even worse.
> Do you have a reference for that? One which shows that heap-intensive
> operations are more efficient (size, speed) when doing with a garbage
> collector than reference-counting?

[ For the Nth time: I'm not talking about memory size, only about
  speed.  And not specifically for "heap intensive" operations, but for
  just normal execution of "typical" programs.  ]

I don't have a reference, no.  But I'm pretty sure there are plenty.

I guess the most obvious argument is just the very small number of
language implementations that use reference counting and are "high
performance" (which presumably implies that the implementors have spent
some effort to try and use an efficient memory management technique).

I know there exists a GC for the JVM that uses reference counting, but
it's only one out of many others.  It is competitive speed-wise, but it
took a lot of effort to get there (it's very far from a simple reference
counting system like CPython's).

There's also Lean which uses reference counting, but I haven't seen any
indication that it's particularly fast.  AFAIK, the main purpose is to
allow "functional in place update" (by checking if the refcount is equal
to 1), IOW circumvent the language constraint on everything being
immutable yet without resorting to monads.

Given the amount of effort poured into the GC of many language
implementations, if reference counting was competitive speed-wise, it'd
be used a lot more, since it's a lot easier to implement (and debug).


=== Stefan

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

#60913

On Mon, 15 Jun 2026 09:51:57 -0400, Stefan Monnier wrote:

> I guess the most obvious argument is just the very small number of
> language implementations that use reference counting and are "high
> performance" (which presumably implies that the implementors have
> spent some effort to try and use an efficient memory management
> technique).

Perl was probably the pioneer here. Implementations use garbage
collection simply because it’s so much easier to do, nothing more.

As I mentioned elsewhere Java gets “high performance” by minimizing
heap allocation, at the cost of writing more circumlocutory code.

Lisp would be the same. What’s his name, Lisp guru Paul Graham, has a
blog online where he talks about working on an early dotcom startup
where the development language was Lisp. That gave them a lot of
productivity boosts. But the core part of the in-memory database was
implemented in C++, precisely where the garbage collector could not
get its sticky fingers on it.

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

#60920

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Lisp would be the same. What’s his name, Lisp guru Paul Graham, has a
> blog online where he talks about working on an early dotcom startup
> where the development language was Lisp. That gave them a lot of
> productivity boosts. But the core part of the in-memory database was
> implemented in C++, precisely where the garbage collector could not
> get its sticky fingers on it.

Do you mean https://www.paulgraham.com/avg.html ?

The mention of C++ was after he sold the company to Yahoo:

   In January 2003, Yahoo released a new version of the editor written
   in C++ and Perl. It's hard to say whether the program is no longer
   written in Lisp, though, because to translate this program into C++
   they literally had to write a Lisp interpreter: the source files of
   all the page-generating templates are still, as far as I know, Lisp
   code. (See Greenspun's Tenth Rule.)

He mentions that the ordering system of his site was written in C but
doesn't say why.

It's not that great an essay imho.  And the stuff he says about Python
now seems quaint.

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

#60926

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Perl was probably the pioneer here. Implementations use garbage
> collection simply because it’s so much easier to do, nothing more.

Have you actually implemented both?  I feel like a bunch of stuff you're
saying come from inexperience.  

In my case I've implemented an Awk with reference counting and later a
Lisp with GC.  I used RC in the Awk because at that time, I didn't know
how to write a GC.  The GC in the Lisp that I wrote was quite simple but
I still wouldn't say that it was easier than RC.  Of course "serious"
GC's are very intricate and not remotely comparable to the naive
reference counting in something like Python.  It's ridiculous to say
it's easier.

Here's Simon Marlow et al's 2008 paper on the GHC garbage collector:

https://simonmar.github.io/bib/papers/parallel-gc.pdf

I have a vague recollection that the GHC GC was later redone to be even
more sophisticated.  And it's nowhere near as fancy as the GC's used in
Java which have gotten a lot more development energy.

If of any interest, the current "big" Python implementation is CPython
and it uses reference counting.  MicroPython, a smaller Python version
for microcontrollers, uses GC.  Lua, considered a smaller-footprint and
more embeddable language than Python, also uses GC.  MicroPython ran on
MCU's with as little as 16KB of ram (BBC Micro:bit v1) though that was
very cramped.  It's reasonably usable with 32KB.  I don't think CPython
could run at all on those machines.

I'd be interested to know why CPython uses RC.  If I ever meet Guido
I'll try to remember to ask him.  I do have the impression that
immediate reclamation for stuff like file descriptors was claimed as a
big advantage, before Python itself got RAII in the "with" statement.

Slightly related, do you even use Lisp?  I think your picture of how
Lisp programs use memory is also unrealistic.  

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

Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

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

csiph-web