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

Groups > comp.lang.c > #400622 > unrolled thread

Re: Resources to learn common lisp?

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

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: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-31 07:17 +0800
    Re: Resources to learn common lisp? Anton Antimo <anton@safunu.org> - 2026-07-31 12:21 -0300
      Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-01 01:48 +0800
        Re: Resources to learn common lisp? Anton Antimo <anton@safunu.org> - 2026-08-05 13:13 -0300
          Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 21:48 +0000
            Re: Resources to learn common lisp? David Brown <david.brown@hesbynett.no> - 2026-08-06 09:05 +0200
            Manipulating C code at the AST level, in C (was: Re: Resources to learn common lisp?) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-09 05:33 +0800
              Re: Manipulating C code at the AST level, in C Paul Rubin <no.email@nospam.invalid> - 2026-08-10 01:11 -0700
                Re: Manipulating C code at the AST level, in C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-10 13:10 -0700
              Re: Manipulating C code at the AST level, in C Anton Antimo <anton@safunu.org> - 2026-08-10 17:41 -0300
                Re: Manipulating C code at the AST level, in C Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-10 23:53 +0000
                  Re: Manipulating C code at the AST level, in C scott@slp53.sl.home (Scott Lurndal) - 2026-08-11 14:29 +0000
                  kqueues and port_create() (was: Re: Manipulating C code at the AST level, in C) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-12 07:51 +0800
                    Re: kqueues and port_create() Paul Rubin <no.email@nospam.invalid> - 2026-08-11 20:59 -0700
                      Re: kqueues and port_create() Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-12 13:07 +0800
                        Re: kqueues and port_create() Alan Bawden <alan@csail.mit.edu> - 2026-08-12 03:23 -0400
                          Re: kqueues and port_create() Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 07:50 +0000
                            Re: kqueues and port_create() Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-13 11:33 +0800
                          Re: kqueues and port_create() Paul Rubin <no.email@nospam.invalid> - 2026-08-12 02:22 -0700
                            Re: kqueues and port_create() Alan Bawden <alan@csail.mit.edu> - 2026-08-12 20:55 -0400
                          Re: kqueues and port_create() Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-13 11:37 +0800
                      Re: kqueues and port_create() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-12 12:59 -0700
                  Re: Manipulating C code at the AST level, in C Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-14 12:26 +0100
                D.N.S. in Common Lisp (was: Re: Manipulating C code at the AST level, in C) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-12 07:59 +0800
                  Re: D.N.S. in Common Lisp Anton Antimo <anton@safunu.org> - 2026-08-12 09:01 -0300
          Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-12 13:18 +0800
            Re: Resources to learn common lisp? bixbox <noreply@example.invalid> - 2026-08-12 10:16 +0200
              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-13 02:18 +0000
                Re: Resources to learn common lisp? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-13 04:56 +0200
                  Re: Resources to learn common lisp? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-12 21:13 -0700
                  Re: Resources to learn common lisp? Anton Antimo <anton@safunu.org> - 2026-08-13 12:25 -0300
                    Re: Resources to learn common lisp? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-13 19:01 +0200
                      Re: Resources to learn common lisp? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 14:50 -0700
                      Re: Resources to learn common lisp? Anton Antimo <anton@safunu.org> - 2026-08-14 08:27 -0300
                        Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-15 03:18 +0000
                    Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 02:47 +0000
                    Re: Resources to learn common lisp? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-14 12:20 +0000
                      Re: Resources to learn common lisp? Anton Antimo <anton@safunu.org> - 2026-08-16 15:37 -0300
                  Re: Resources to learn common lisp? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-14 12:17 +0000
                    Re: Resources to learn common lisp? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-14 16:31 +0200
                Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-13 11:29 +0800
                Re: Resources to learn common lisp? Michael S <already5chosen@yahoo.com> - 2026-08-14 15:30 +0300
                  Re: Resources to learn common lisp? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-14 16:45 +0200
                    Re: Resources to learn common lisp? David Brown <david.brown@hesbynett.no> - 2026-08-14 17:15 +0200
                      Re: Resources to learn common lisp? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-14 19:51 +0200
                      Re: Resources to learn common lisp? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 12:05 -0700
      Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-31 22:46 +0000
        Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-01 07:38 +0800
          Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-08-04 22:26 -0400
        Re: Resources to learn common lisp? tfb <tfb@work.it.out> - 2026-08-01 09:08 +0000
          Re: Resources to learn common lisp? Paul <nospam@needed.invalid> - 2026-08-01 07:49 -0400
            Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-01 23:37 +0000
              Re: Resources to learn common lisp? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-01 16:54 -0700
            Re: Resources to learn common lisp? tfb <tfb@work.it.out> - 2026-08-02 07:39 +0000
          Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-08-04 22:39 -0400
      Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-07-31 23:59 -0400
        Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-01 16:12 +0800
          Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-08-04 22:50 -0400
            Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 19:02 +0800
              Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-08-06 19:36 -0400
                Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-09 02:11 +0800
                  Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-08-09 18:49 -0400
                  Re: Resources to learn common lisp? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-10 13:08 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#400622 — Re: Resources to learn common lisp?

On 30/07/2026 4:21 AM, steve g wrote:
> tfb <tfb@work.it.out> writes:
> 
>> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>>
>>> Have they come up with any excuses as to why OS kernels don’t use
>>> garbage collection?

I think you are mistaken about OS kernels.  They do garbage collection.
Just not in the way you think about it.  It's for instance how killing
processes in Linux "cleans up" memory.  I disagree with this design
choice, and do not use Linux when I can avoid it.

>>>
>>
>> Here is why: they're written either in C or in languages which must be
>> memory & call compatible with C.  It is essentially impossible to implement
>> a garbage collector in C.  There is a famous counterexample: the Boehm GC.
>> It would probably be possible to use that in an OS kernel written in C but
>> I expect it would be very hard to retrofit it to an existing kernel.  It's
>> also (because C) not a copying collector.
> 
> 
> Introduction to GC:
> 
> The GC package contains the Boehm-Demers-Weiser conservative garbage
> collector, which can be used as a garbage collecting replacement for the
> C malloc function or C++ new operator. It allows you to allocate memory
> basically as you normally would, without explicitly deallocating memory
> that is no longer useful. The collector automatically recycles memory
> when it determines that it can no longer be otherwise accessed. The
> collector is also used by a number of programming language
> implementations that either use C as intermediate code, want to
> facilitate easier interoperation with C libraries, or just prefer the
> simple collector interface. Alternatively, the garbage collector may be
> used as a leak detector for C or C++ programs, though that is not its
> primary goal.
> 
> this is what guile uses and GCC can use.

And I guess you're ignorant of the Ravenbrook /Memory Pool System/, or
you'd have mentioned it already.

   https://github.com/Ravenbrook/mps

I have it on stand by for a future project.  I'll see if it's easier to
use that, than to write my own.  Cross posted to comp.lang.c to irritate
the annoying regulars there.

> 
>> C was a deeply appropriate language to write an OS for the PDP-11.  At
>> every point since then there's been the choice of continuing to use C and
>> either a port of that OS or an implementation of a compatible OS or of
>> implementing a new, incompatible, OS.  For at least 30 years there's really
>> only been one answer to that question.  And so, today, by a series of
>> perfectly reasonable choices, we've ended up with a vast OS implemented in
>> a language which is now deeply inappropriate.
> 
> let me guess assembler is not your programming language of choice.
> henceforth C.

I do a bit of assembly now and then.  Which one is your favorite?

> 
>> Sadly we've also ended up with programmers who think the machines they
>> program for are giant PDP-11s, and as a result machines which spend a huge
>> amount of effort pretending to be giant PDP-11s.
>>
>> It's all a tragedy.

The tragedy is not using Common Lisp for everything.

-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com

[toc] | [next] | [standalone]

#400660

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

[...]

>>> Sadly we've also ended up with programmers who think the machines
>>> they program for are giant PDP-11s, and as a result machines which
>>> spend a huge amount of effort pretending to be giant PDP-11s.
>>>
>>> It's all a tragedy.
>
> The tragedy is not using Common Lisp for everything.

I loved this bit and I have a feeling you're correct.  My little
experience with Common Lisp is that it allows me to write the equivalent
fast code that I'd write in C, where speed matters.  In other words, I
seem to gain nothing (other than more work) by writing typical
applications in C.

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

#400663

On 31/07/2026 11:21 PM, Anton Antimo wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
> 
> [...]
> 
>>>> Sadly we've also ended up with programmers who think the machines
>>>> they program for are giant PDP-11s, and as a result machines which
>>>> spend a huge amount of effort pretending to be giant PDP-11s.
>>>>
>>>> It's all a tragedy.
>>
>> The tragedy is not using Common Lisp for everything.
> 
> I loved this bit and I have a feeling you're correct.  My little
> experience with Common Lisp is that it allows me to write the equivalent
> fast code that I'd write in C, where speed matters.  In other words, I
> seem to gain nothing (other than more work) by writing typical
> applications in C.

The fun is in writing atypical applications, and then finding yourself
looking at the disassembly in SBCL.

Personally, I love writing in C, even though it's more verbose.

That said, and to be mildly on-topic in comp.lang.lisp, have

* /The Common Lisp Condition System/, and

* /Programming Algorithms in Lisp/

been mentioned before as resources for learning common lisp?

These two books look lovely in my programming shelf, next to

* /Common Lisp Recipes/, and

* /Practical Common Lisp/,

which must have been mentioned.  They're interspersed with

* /Low Level Programming/,

* /String Algorithms in C/, and

* /The Joys of Hashing/,

which come in handy when you want to implement your own Common
Lisp system.


Enjoy!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com

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

#400865

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

> On 31/07/2026 11:21 PM, Anton Antimo wrote:
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>> [...]
>> 
>>>>> Sadly we've also ended up with programmers who think the machines
>>>>> they program for are giant PDP-11s, and as a result machines which
>>>>> spend a huge amount of effort pretending to be giant PDP-11s.
>>>>>
>>>>> It's all a tragedy.
>>>
>>> The tragedy is not using Common Lisp for everything.
>>
>> I loved this bit and I have a feeling you're correct.  My little
>> experience with Common Lisp is that it allows me to write the equivalent
>> fast code that I'd write in C, where speed matters.  In other words, I
>> seem to gain nothing (other than more work) by writing typical
>> applications in C.
>
> The fun is in writing atypical applications, and then finding yourself
> looking at the disassembly in SBCL.

I actually do that every now and then just to learn a bit more about
assembly, something I find so cool about SBCL (and lacking in other
close-to-the-language tools).  

Speaking of which, I decided to try Common Lisp about 2 years ago,
having struggled to deal with Racket for over ten years, nevertheless
considering Racket the most elegant Lisp around ever since its birth.
And, boy, did I never look back.  

(*) A critique of Racket

To be fair, a big part of my struggle is the thick layer of Racket on
top of POSIX.  For instance, try to locate the equivalent select-call on
it.  It's so hard to recognize exactly how your Racket maps to the lower
level.  I understand that may a strong point of Racket's design, but it
certainly hits my weakness.

How about the macro system?  So perfect, yet so annoying.  One thing I
love about Common Lisp is precisely macro's (lack of) hygiene.  I'm
totally fine with complete guarantee.  Anaphoric macros are so useful.
(No idea how to implement them in Racket---impossible?)

> Personally, I love writing in C, even though it's more verbose.
>
> That said, and to be mildly on-topic in comp.lang.lisp, have
>
> * /The Common Lisp Condition System/, and
>
> * /Programming Algorithms in Lisp/
>
> been mentioned before as resources for learning common lisp?
>
> These two books look lovely in my programming shelf, next to
>
> * /Common Lisp Recipes/, and
>
> * /Practical Common Lisp/,
>
> which must have been mentioned.  They're interspersed with
>
> * /Low Level Programming/,
>
> * /String Algorithms in C/, and
>
> * /The Joys of Hashing/,
>
> which come in handy when you want to implement your own Common
> Lisp system.
>
>
> Enjoy!

Enjoyed a lot!  Thanks so much for sharing very useful references.

Let me try to contribute with

  Let Over Lambda
  Doug Hoyte, 2008
  ISBN 978-1-4357-1275-1  

  --8<-------------------------------------------------------->8---
  Let Over Lambda (ISBN 978-1-4357-1275-1, 376+iv pp.) is one of the
  most hardcore computer programming books out there. Starting with the
  fundamentals, it describes the most advanced features of the most
  advanced language: COMMON LISP. The point of this book is to expose
  you to ideas that you might otherwise never be exposed to.

  This book is about macros, that is programs that write
  programs. Macros are what make lisp the greatest programming language
  in the world. When used properly, macros enable amazing feats of
  abstraction, programmer productivity, and code efficiency and security
  that are unheard of elsewhere. Macros let you do things you simply
  cannot do in other languages.
  --8<-------------------------------------------------------->8---

  Source: 
  Doug Hoyte, https://letoverlambda.com/

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

#400875

On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:

> To be fair, a big part of my struggle is the thick layer of Racket
> on top of POSIX. For instance, try to locate the equivalent
> select-call on it. It's so hard to recognize exactly how your Racket
> maps to the lower level. I understand that may a strong point of
> Racket's design, but it certainly hits my weakness.

Sounds very Java-like. Though perhaps not as irritating as Java.

Compare Python <https://docs.python.org/3/library/select.html> --
that’s less than 10 pages (i.e. number of times I have to hit
Page-Down in the browser) of docs.

>   Let Over Lambda
>   Doug Hoyte, 2008
>   ISBN 978-1-4357-1275-1
>
>   This book is about macros, that is programs that write programs.
>   Macros are what make lisp the greatest programming language in the
>   world. When used properly, macros enable amazing feats of
>   abstraction, programmer productivity, and code efficiency and
>   security that are unheard of elsewhere. Macros let you do things
>   you simply cannot do in other languages.

Given this is posted to comp.lang.c, it’s always worth mentioning
these are not macros in the style of #define, but they work at the AST
level. Which is really the only sensible way to implement a workable
macro system.

And no longer unique to Lisp.

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

#400888

On 05/08/2026 23:48, Lawrence D’Oliveiro wrote:
> On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
> 
> Given this is posted to comp.lang.c, it’s always worth mentioning
> these are not macros in the style of #define, but they work at the AST
> level. Which is really the only sensible way to implement a workable
> macro system.
> 
> And no longer unique to Lisp.

Given that this is entirely about Lisp (or at least it has absoltuely 
nothing to do with C), it should be posted only in comp.lang.list - not 
comp.lang.c.  It would be very nice if the absurd level of pointless 
cross-postings we have seen recently were to stop.  It is fine to have 
occasional cross-postings and "outside influence" in a newsgroup, but a 
few trolls have taken to cross-posting meaningless ramblings to all 
sorts of groups.  I would ask all reasonable participants in Usenet 
threads to check the newsgroup lists on their posts, and trim them where 
it makes sense (or simply not to respond to the worst trolls).

As for macros in programming languages, AST macros are /not/ the only 
"sensible" way to have macros.  They are a very different thing from 
text-based macros as supported by the C pre-processor.  The two types of 
macro have their advantages and disadvantages, and can be used for 
different purposes.  The mistake is not in having one or the other, but 
in calling them both "macros".  It is reasonable to note, however, that 
AST macros must be part of the language while text-based macros can be 
provided by a generic external tool (like m4).

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

#400933 — Manipulating C code at the AST level, in C (was: Re: Resources to learn common lisp?)

On 06/08/2026 5:48 AM, Lawrence D’Oliveiro wrote:
> On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
> 
>> To be fair, a big part of my struggle is the thick layer of Racket
>> on top of POSIX. For instance, try to locate the equivalent
>> select-call on it. It's so hard to recognize exactly how your Racket
>> maps to the lower level. I understand that may a strong point of
>> Racket's design, but it certainly hits my weakness.
> 
> Sounds very Java-like. Though perhaps not as irritating as Java.
> 
> Compare Python <https://docs.python.org/3/library/select.html> --
> that’s less than 10 pages (i.e. number of times I have to hit
> Page-Down in the browser) of docs.


I admit I'm not sure why the select system call seems to be missing from
this selection of networking functions, so I'm impelled to ask, what is
is that you use select for, in Python?

   https://www.sbcl.org/manual/#networking

> 
>>    Let Over Lambda
>>    Doug Hoyte, 2008
>>    ISBN 978-1-4357-1275-1
>>
>>    This book is about macros, that is programs that write programs.
>>    Macros are what make lisp the greatest programming language in the
>>    world. When used properly, macros enable amazing feats of
>>    abstraction, programmer productivity, and code efficiency and
>>    security that are unheard of elsewhere. Macros let you do things
>>    you simply cannot do in other languages.
> 
> Given this is posted to comp.lang.c, it’s always worth mentioning
> these are not macros in the style of #define, but they work at the AST
> level. Which is really the only sensible way to implement a workable
> macro system.
> 
> And no longer unique to Lisp.

Indeed.  If you want to manipulate C code at the AST level, in C, all
you need to do is to hook your code with libclang.  It's annoying to
use, because it's a private API for the fruit vendor, and mostly un-
documented.  That's why I basically gave up on using it in my own pro-
jects.


Good luck with libclang!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#400945 — Re: Manipulating C code at the AST level, in C

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
> I admit I'm not sure why the select system call seems to be missing from
> this selection of networking functions, so I'm impelled to ask, what is
> is that you use select for, in Python?

Select is used to listening to a bunch of file descriptors
simultaneously and unblocking as soon as data becomes available on one
or more of the fd's.  These days it's somewhat superseded by epoll or
io_uring or a few other alternatives.

I actually don't see any of these in the sbcl manual, though maybe I
didn't look hard enough.  I'd expect to see it in the streams or
concurrency modules.  You could use threads and mailboxes instead, but
that's often overkill, especially with posix threads.

I see a mention of:

   *Recursive Event Loop*: SBCL provides a recursive event loop
   (serve-event) for doing non-blocking IO on multiple streams without
   using threads.

But I don't see anything more about that in the manual.  There's a
reddit thread saying it's poorly supported:

https://old.reddit.com/r/Common_Lisp/comments/kdk6mq/how_to_use_serveevent_from_sbcl/

Anyway that is basically what select is for.

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

#400949 — Re: Manipulating C code at the AST level, in C

On 8/10/2026 1:11 AM, Paul Rubin wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>> I admit I'm not sure why the select system call seems to be missing from
>> this selection of networking functions, so I'm impelled to ask, what is
>> is that you use select for, in Python?
> 
> Select is used to listening to a bunch of file descriptors
> simultaneously and unblocking as soon as data becomes available on one
> or more of the fd's.  These days it's somewhat superseded by epoll or
> io_uring or a few other alternatives.
> 
> I actually don't see any of these in the sbcl manual, though maybe I
> didn't look hard enough.  I'd expect to see it in the streams or
> concurrency modules.  You could use threads and mailboxes instead, but
> that's often overkill, especially with posix threads.
> 
> I see a mention of:
> 
>     *Recursive Event Loop*: SBCL provides a recursive event loop
>     (serve-event) for doing non-blocking IO on multiple streams without
>     using threads.
> 
> But I don't see anything more about that in the manual.  There's a
> reddit thread saying it's poorly supported:
> 
> https://old.reddit.com/r/Common_Lisp/comments/kdk6mq/how_to_use_serveevent_from_sbcl/
> 
> Anyway that is basically what select is for.

select works fine, but put it under pressure... Well, no so much... ;^o

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

#400951 — Re: Manipulating C code at the AST level, in C

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

> On 06/08/2026 5:48 AM, Lawrence D’Oliveiro wrote:
>> On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
>> 
>>> To be fair, a big part of my struggle is the thick layer of Racket
>>> on top of POSIX. For instance, try to locate the equivalent
>>> select-call on it. It's so hard to recognize exactly how your Racket
>>> maps to the lower level. I understand that may a strong point of
>>> Racket's design, but it certainly hits my weakness.
>> Sounds very Java-like. Though perhaps not as irritating as Java.
>> Compare Python <https://docs.python.org/3/library/select.html> --
>> that’s less than 10 pages (i.e. number of times I have to hit
>> Page-Down in the browser) of docs.
>
>
> I admit I'm not sure why the select system call seems to be missing from
> this selection of networking functions, [...]

It would be like writing C in Lisp notation.  For select (called
unix-fast-select in SBCL), see sb-unix.

(defun wait-for-stdin-select ()
  (sb-alien:with-alien ((read-fds (sb-alien:struct sb-unix:fd-set)))
    (sb-unix:fd-zero read-fds)
    (sb-unix:fd-set 0 read-fds)
    (format t "Waiting up to 5 seconds for input on stdin... Type something!~%")
    (force-output)
    (multiple-value-bind (count err)
        (sb-unix:unix-fast-select 1 (sb-alien:addr read-fds) nil nil 5 0)
      (cond
        ((null count)
         (format t "Select failed with errno: ~A~%" err))
        ((zerop count)
         (format t "Timeout! No input received.~%"))
        ((sb-unix:fd-isset 0 read-fds)
         (format t "Data is ready to be read from stdin!~%"))
        (t
         (format t "Something else woke up select!~%"))))))

;; run it
(wait-for-stdin-select)

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

#400956 — Re: Manipulating C code at the AST level, in C

On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:

> For select (called unix-fast-select in SBCL), see sb-unix.

select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll()
<https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
<https://manpages.debian.org/epoll(7)> (Linux-specific).

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

#400985 — Re: Manipulating C code at the AST level, in C

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
>On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
>
>> For select (called unix-fast-select in SBCL), see sb-unix.
>
>select(2) is considered an archaic way of doing things these days,
>because of its ABI limitations. The modern way is poll()
><https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
><https://manpages.debian.org/epoll(7)> (Linux-specific).

Both poll(2) and select(2) are fully supported POSIX interfaces.

select derives from BSD, poll derives from System V.

There are issues with select (due to the defintion of fd_set)
that make it unsuitable for certain applications (such as those
that use file descriptors greater than FD_SETSIZE).

https://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html

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

#401043 — kqueues and port_create() (was: Re: Manipulating C code at the AST level, in C)

On 11/08/2026 7:53 AM, Lawrence D’Oliveiro wrote:
> On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
> 
>> For select (called unix-fast-select in SBCL), see sb-unix.
> 
> select(2) is considered an archaic way of doing things these days,
> because of its ABI limitations. The modern way is poll()
> <https://manpages.debian.org/poll(2)> (POSIX) or even epoll()
> <https://manpages.debian.org/epoll(7)> (Linux-specific).

Dear Lawrence,

You really don't keep up with the times.  The /modern/ way to do this
is to install FreeBSD over whatever other Unix you may have installed,
and I suspect it's still S.C.O. UnixWare for you, and then use kqueues.

   https://man.freebsd.org/cgi/man.cgi?kqueue

On the other hand, if you insist on using the illuminated operating sys-
stem without cross porting the kqueue mechanism, there's always the port
API.

   https://www.illumos.org/man/3C/port_create


Happy queuing!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401046 — Re: kqueues and port_create()

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>   https://man.freebsd.org/cgi/man.cgi?kqueue

Is this something like io_uring?  Is it just for i/o on open fd's or can
you also use it for stuff like opening files?

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

#401052 — Re: kqueues and port_create()

On 12/08/2026 11:59 AM, Paul Rubin wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>    https://man.freebsd.org/cgi/man.cgi?kqueue
> 
> Is this something like io_uring?  Is it just for i/o on open fd's or can
> you also use it for stuff like opening files?

I admit ignorance of how io_uring works.  I haven't done low level code
like this in Linux for a very long time, and I believe back then io_ur-
ing didn't exist.

The kqueue() is for open file descriptors, created as sockets or open
files, or anything else the FreeBSD kernel decides is a file.  I'm not
aware of any interface to create one and open a file with the same func-
tion call.


Hope that helps!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401058 — Re: kqueues and port_create()

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

> On 12/08/2026 11:59 AM, Paul Rubin wrote:
>> Is this something like io_uring?  Is it just for i/o on open fd's or can
>> you also use it for stuff like opening files?
> The kqueue() is for open file descriptors, created as sockets or open
> files, or anything else the FreeBSD kernel decides is a file.  I'm not
> aware of any interface to create one and open a file with the same func-
> tion call.

I _think_ what Paul was asking was is it possible to get notified when a
specific file in the file system is opened.  If that's what he's asking,
then the answer is: yes kqueue/kevent can do that.  You open the file in
question using O_PATH, and then create a kevent using that descriptor
with filter EVFILT_VNODE and event NOTE_OPEN.

-- 
Alan Bawden

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

#401060 — Re: kqueues and port_create()

On Wed, 12 Aug 2026 03:23:45 -0400, Alan Bawden wrote:

> I _think_ what Paul was asking was is it possible to get notified
> when a specific file in the file system is opened. If that's what
> he's asking, then the answer is: yes kqueue/kevent can do that. You
> open the file in question using O_PATH, and then create a kevent
> using that descriptor with filter EVFILT_VNODE and event NOTE_OPEN.

There is no POSIX API for this. Linux has inotify(7) for watching
particular files, and certain kinds of directory operations, and
fanotify(7) for more general watching of entire
directories/filesystems.

<https://manpages.debian.org/inotify(7)>
<https://manpages.debian.org/fanotify(7)>

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

#401096 — Re: kqueues and port_create()

On 12/08/2026 3:50 PM, Lawrence D’Oliveiro wrote:
> On Wed, 12 Aug 2026 03:23:45 -0400, Alan Bawden wrote:
> 
>> I _think_ what Paul was asking was is it possible to get notified
>> when a specific file in the file system is opened. If that's what
>> he's asking, then the answer is: yes kqueue/kevent can do that. You
>> open the file in question using O_PATH, and then create a kevent
>> using that descriptor with filter EVFILT_VNODE and event NOTE_OPEN.
> 
> There is no POSIX API for this. Linux has inotify(7) for watching
> particular files, and certain kinds of directory operations, and
> fanotify(7) for more general watching of entire
> directories/filesystems.
> 
> <https://manpages.debian.org/inotify(7)>
> <https://manpages.debian.org/fanotify(7)>

Lawrence, we don't care about Posix here in comp.lang.lisp, nor do we
care about what the Linux kernel people think is a good idea.  They al-
most never have good ideas anyway.

So stop trying to force Posix discussion into kqueues and Illumos ports,
unless you're also working for the Open Group, and trying to get some
things standardized.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401064 — Re: kqueues and port_create()

Alan Bawden <alan@csail.mit.edu> writes:
> I _think_ what Paul was asking was is it possible to get notified when a
> specific file in the file system is opened.

No in linux that's called inotify.  io_uring is basically an alternative
system call interface that's relatively new, and maybe not complete.
You send off a request to do the system call, and get back a queued
response when the call is completed, unlike traditional syscalls that
appear to be synchronous.

One of the calls you can do that way is opening a file.  Historically in
Unix and Linux, there was no way to do that asynchronously.  If you used
open() and the operation was slow (for example NFS, or even anything on
a hard disk), your program would be blocked until the call returned.  If
you don't want to block, you have to do the open() in a separate thread.
GHC and Erlang BEAM have lightweight threads/processes, but they also
had a pool of OS threads to handle operations like opening files.

io_uring lets you open files asynchronously, so you can in principle
simulate an OS in a single user-level process.  More typically though,
io_uring is used as an alternative to something like epoll, for
listening on lots of sockets at the same time.  There are a lot of
benchmarks around that I think say io_uring is a little faster.
io_uring also can replace AIO, which never worked very well.  AIO was
for asynchronous disk i/o operations after the file was already open.

I haven't had occasion to use io_uring yet but I saw its importance when
it first appeared.

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

#401090 — Re: kqueues and port_create()

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

> Alan Bawden <alan@csail.mit.edu> writes:
>> I _think_ what Paul was asking was is it possible to get notified when a
>> specific file in the file system is opened.
>
> No in linux that's called inotify.  io_uring is basically an alternative
> system call interface that's relatively new, and maybe not complete.
> You send off a request to do the system call, and get back a queued
> response when the call is completed, unlike traditional syscalls that
> appear to be synchronous.

Ah!  I didn't understand your original question because I didn't have
the context of knowing what io_uring was.  Thanks for introducing me to
something new.

-- 
Alan Bawden

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web