On Sun, Oct 25, 2020 at 04:41:41PM -0400, 'John Clements' via Racket Users
wrote:
> It depends a lot on what you mean by a “Lisp-y” language. I’m certainly not
> going to disagree with the sentiments expressed in the stack overflow post
> that Dan Prager posted… after all, I wrote the
It depends a lot on what you mean by a “Lisp-y” language. I’m certainly not
going to disagree with the sentiments expressed in the stack overflow post that
Dan Prager posted… after all, I wrote the top-posted one! You’re asking a
question about persuading a co-worker, though. In my opinion, the
> is it possible to run modern Lisp-y languages without a garbage
collector? Is it even smart to try?
This seems to cover it ...
https://stackoverflow.com/questions/16240183/not-using-garbage-collector-in-scheme-lisp-implementation
Dan
--
You received this message because you are subscribed
I'm in a very small programming operation, and I am trying to get my
co-workers to try out Racket, or at least tolerate some of the tools being
written in Racket. One of them has a very simple decision tree that he uses
to evaluate programming languages: "does it have a garbage collector?", if
At Mon, 17 Aug 2015 12:21:41 -0700 (PDT), Jack Firth wrote:
On Monday, August 17, 2015 at 9:07:15 AM UTC-7, Matthew Flatt wrote:
That's an especially basic mistake, and it slipped by because low-level
locks are rarely allocated in the run-time system. Place channels are
probably the
Folks,
I am observing a memory leak with place-channels. I have long-lived (or
very busy server “places”) which I think are exhausting VM memory and
causing spectacular failures -- core dumps, spins and other fun I came
to Racket to avoid. Please could someone more familiar with the code
take a
Sam,
I don’t see the leak with (display (current-memory-use)) -- sorry for
leaving it in the example, it’s misleading since your numbers behave
like mine did when I used that function.
I *do*, however, see the leak on my gnome-system-monitor; which looks
like something that’s invisible to the GC
The problem is in the clean-up of OS-level locks. A lock is allocated
using a combination of malloc() and pthread_mutex_init(), for example.
The clean up was usually missing the free() to go along with
pthread_mutex_destroy().
That's an especially basic mistake, and it slipped by because
I'm looking into this. I can confirm that the GC thinks there's no
leak, but the OS thinks there is.
Thanks for the example and info!
At Mon, 17 Aug 2015 16:09:00 +0100, Tim Brown wrote:
Sam,
I don’t see the leak with (display (current-memory-use)) -- sorry for
leaving it in the example,
Thank you Matthew.
On 17/08/15 17:07, Matthew Flatt wrote:
That's an especially basic mistake, and it slipped by because low-level
locks are rarely allocated in the run-time system. Place channels are
probably the simplest way to trigger new locks, but the test that
checks for leaks with
On Monday, August 17, 2015 at 9:07:15 AM UTC-7, Matthew Flatt wrote:
That's an especially basic mistake, and it slipped by because low-level
locks are rarely allocated in the run-time system. Place channels are
probably the simplest way to trigger new locks, but the test that
checks for leaks
Jack Firth wrote on 08/17/2015 03:21 PM:
From my limited experience with C, I've learned it's pretty much
impossible to expect any sane human to keep track of memory perfectly.
That's a helpful impression. C must be feared and respected, before it
can be tamed.
That said, I think it's
whenever I get the itch to dream about gc, inevitably I end up at a
paper or other by Bacon; seems like Bacon is one of the go-to guys on
GC. random e.g.
http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon04Unified.pdf
--
You received this message because you are subscribed to the
At Sat, 04 Jul 2015 17:55:29 -0400, Neil Van Dyke wrote:
Neil Toronto wrote on 07/04/2015 05:29 PM:
I don't know, but I want most of these things. I assume this is
related to your earlier question about games? :)
Partly. :) I've also been dealing with GC for years in non-game HTTP
)
Date: Sun, 5 Jul 2015 07:38:48 +0200
From: michael.tied...@o2online.de
To: racket-users@googlegroups.com
Subject: Re: [racket-users] garbage collection
It's better to think about the malloc/gc duo as a memory manager. Some
traditional approaches just seem awfully dumb and wrong like
On 07/04/2015 05:26 PM, Neil Van Dyke wrote:
Any plans for new interesting GC/memory features in Racket?
For example, being able to inhibit GC for a time, being able to adjust
the GC trigger parameters dynamically, different ways to minimize GC
pauses or slowdown in the app behavior, real-time
Neil Toronto wrote on 07/04/2015 05:29 PM:
I don't know, but I want most of these things. I assume this is
related to your earlier question about games? :)
Partly. :) I've also been dealing with GC for years in non-game HTTP
servers in which some requests are time-sensitive, and even just
On 07/04/2015 05:26 PM, Neil Van Dyke wrote:
Any plans for new interesting GC/memory features in Racket?
For example, being able to inhibit GC for a time, being able to adjust
the GC trigger parameters dynamically, different ways to minimize GC
pauses or slowdown in the app behavior,
On 05/07/2015 01:00, Neil Van Dyke wrote:
Matthew Flatt wrote on 07/04/2015 06:40 PM:
That is, unlike so many other things in our infrastructure, the GC is
not so tangled with everything else that it would be difficult to
change by itself. Granted,
Good about GC not so tangled.
I don't know
Matthew Flatt wrote on 07/04/2015 06:40 PM:
That is, unlike so many other things in our infrastructure, the GC is
not so tangled with everything else that it would be difficult to
change by itself. Granted,
Good about GC not so tangled.
I don't know the current state of GC research, nor what
I have no plans myself, but I think many applications would benefit
from incremental collection. I also think that implementing an
incremental GC for Racket is within reach --- as much as for any
runtime system.
That is, unlike so many other things in our infrastructure, the GC is
not so tangled
21 matches
Mail list logo
