
Let's add a statistical profiler to Chicken Scheme - kryptiskt
http://www.more-magic.net/posts/statistical-profiling.html
======
pflanze
There's been a statistical profiler for Gambit Scheme since 2005 by Guillaume
Germain
([https://duckduckgo.com/html/?q=guillaume+germain+statprof](https://duckduckgo.com/html/?q=guillaume+germain+statprof)).
It's written in Scheme unlike this one, including the signal handler, which
accesses the current continuation of the running program and from that
extracts the information it needs. The continuations represent the "real"
backtrace as opposed to the tracing, and they are always there of course
(there's no disabling them as that would defeat the running of the programs).
The profiler could thus extract the proper dynamic context (I don't remember
if it does, but it could be extended to do so) and thus avoids the risk for
surprise mentioned in the article.

I'd expect most Scheme implementations to have a statistical profiler by now?

Gambit gets several things right (continuation representation, debugger,
perhaps multithreading (although other Schemes got that too)), although at the
same time its internals are undocumented, difficult to work with (I found the
abstractions used a bit lacking, and it's mostly a big amount of code without
visible dependency structure which in its current state basically can't be
run/changed/analyzed in pieces), and after an unlucky stint at a PhD under its
author (1) I stopped plans to work on it. I'm still looking for a Scheme
implementation that's got those things down similarly well but is more
amendable (perhaps Scheme-48 although it doesn't have any real community).

(1) he's a demanding person to work with, but to be fair mostly the reason for
the failure was that I was ill-prepared.

~~~
KMag
By multithreading, do you mean concurrency, or does Gambit expose raw threads
to user programs? I'm rather convinced that a pthreads-like or Java-like
interface to threads is too low-level and error-prone for most programming
outside of kernel or standard library programming. We have less error-prone
concurrency interfaces in Erlang-like CSP or Scala Actors.

~~~
pflanze
I was referring to its built-in raw threads including mutexes, condition
variables, and what it calls mailboxes (communication channels between
threads) as well as object ports. You can build an Erlang style system easily
on top of those (this is Scheme, after all, so you've got macros to help build
abstractions, although the system doesn't offer the means to enforce
separation (your programs can access symbols that allow to circumvent any
separation attempts)), as the Termite project(1) in fact did (also about a
decade ago).

(1)
[https://duckduckgo.com/html/?q=gambit+termite](https://duckduckgo.com/html/?q=gambit+termite)

I was mentioning threads since Marc Feeley, its author, was a forerunner in
implementing threads on Scheme systems (he authored the threading SRFI (2)).
It's a green threading system (support for millions of threads, it doesn't
come with support for libev though, so YMMV).

(2) [http://srfi.schemers.org/srfi-18/](http://srfi.schemers.org/srfi-18/)

Thing is, the thread system, like the rest of the system (e.g. he devised an
I/O layer that tries to be OS agnostic), tries to come as shiny closed system
for the user (with comprehensive user docs), whereas I'd much prefer for the
parts to be openly accessible/exchangable. For example I'm often barely using
the built-in OS-agnostic I/O layer and instead wrote interfaces to POSIX via
the FFI. And I don't use the threading system often. My biggest use case for
multi-threading is SMP support which I need to do by running separate Gambit
instances (or by way of fork), accessing a common storage layer implemented
via POSIX (currently in the works, and I'm writing it in a way that should
make it easy for me to move to other Scheme systems).

In essence, from my point of view it's a system from academia with a quite
explicit attempt to be practical for industrial use but falling short on the
latter front pretty much exactly because it tries to do the latter itself.

