Hacker News Reader

Comment by qwertyuiop924 | Hacker News Reader

In a recent update, they added a debugger called feathers: it's a TCL script included in the default distro, and it's very nice, IMHO, especially for a debugger for compiled code: You can execute arbitrary code inside the current stack frame, and inspect both the source and the compiled code, among other things.

>The only thing missing are lightweight green threads.

...Ummm... Chicken already has that. It implements srfi-18 style pre-emptive coroutines which do qualify as green threads by the standard definition. They all run in a single thread, so you can parallelize without an explicit fork(2) like you can in Erlang and Go, but they are Green threads.

View on HN

Oh shit, I got it backwards: CHICKEN needs native threads! That way, you could implement fibers.

https://wiki.call-cc.org/man/4/faq#does-chicken-support-nati...

I'd reccomed guile or cyclone of you really need native threads: because of Cyclone, the potential is there, but it would be very, very hard.

Chicken does have fork, concurrent native callbacks and mpi, among other stuff, so you can do parallel stuff. It's just more expensive.

Or you can go with Gambit, which does superb job here and produces optimized code. Last releases added backends for Java, PHP, javascript and perl I think.

Gambit has exactly the same problem Chicken does: It has green threads (Gambit's author actually wrote the API for it), but no native threads.

Why did they write a Scheme debugger in TCL?

Good question...was wondering the same thing.

As I wrote above, the brunt of the work is done inside of the program. The debugger proper is largely just the GUI and a client for the network protocol used to communicate with the program being debugged.

That part makes sense if Chicken doesn't have a Tk library like Python (i.e. just go to the source).

Chicken actually does have TK bindings, but they aren't very good. It's got bindings to lots of other toolkits, too, but TK is probably the easiest tookit out there to get working cross platform.

I dunno. Effectively, it's just a frontend for a TCP protocol that's used to communicate with the program being debugged: this allows for remote debugging and all manner of fun. They probably picked TCL because it's really good at GUIs, which is the brunt of the work feathers is doing, as most of the heavy lifting is done program-side, in scheme.

But that's just a guess, if you really want to know, I'd ask Felix: He's the lead developer on Chicken, and he's the one who actually wrote the thing and pushed the commit (see https://code.call-cc.org/cgi-bin/gitweb.cgi?p=chicken-core.g...). He's also pretty approachable.

Hmm...:

https://wiki.call-cc.org/man/4/Unit%20srfi-18

"The disadvantage is that execution of Scheme code on multiple processor cores is not available."

Is there any solid support for message passing or other multi-processing?

Chicken does have support for fork(2), and some of the posix IPC stuff (pipes, sockets, maybe shm?)

There's concurrent-native-callbacks, which allows you to run Chicken callbacks inside other threads http://wiki.call-cc.org/eggref/4/concurrent-native-callbacks.

Chicken also has MPI support, through http://wiki.call-cc.org/eggref/4/mpi, but I don't really know MPI well.

Pthreads allows you to send C code (not scheme code) out to a pthread pool for execution. http://wiki.call-cc.org/eggref/4/pthreads

Mailbox allows for erlang-style threadsafe mailboxes (FIFO queues) http://wiki.call-cc.org/eggref/4/mailbox, and mailbox-threads attaches a mailbox to each thread http://wiki.call-cc.org/eggref/4/mailbox-threads. Finally, remote-mailbox-threads allows for mailbox send/receives across threads through zmq http://wiki.call-cc.org/eggref/4/remote-mailbox-threads.

Not optimal, but it can all work.

Reply on news.ycombinator.com