Is anyone running Termite in production?
Is it considered production-ready?
Thanks, Joel
Afficher les réponses par date
I would not consider Termite production ready.
The creators of Termite describe it as a prototype. In my opinion, the source is quite a mess, with a bunch of commented out code and little organization (remote ports for example aren't usable without modifications). There's also known bugs with exception propagation which make it less useful.
With that said, Termite works very well, especially if you are willing to slap on a thin layer of code which makes up for some its current deficiencies. There's solid deserializing / serializing there as well as a few other things. It may need compression if it wants to compete with Erlang's remote messaging speed. You could make Termite production ready somewhat quickly, but I think most people are more interested in a portable Termite, and the current code is deeply integrated with Gambit.
On Dec 20, 2007 10:03 AM, Joel Reymont joelr1@gmail.com wrote:
Is anyone running Termite in production?
Is it considered production-ready?
Thanks, Joel
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hi,
I wouldn't consider Termite to be "production ready" either, at least not in the sense that Erlang is. I know some people use Termite in their work every day, so at least its useful for them.
It's true that the source code is a bit of a mess, but I've recently started to work on it again. I'm refactoring the code so that it is packaged as a Gambit library instead of having to be compiled along with Gambit. It will make it easier to work on. I'm in the process of documenting it as well.
As for exception propagation bugs, those have been fixed a while ago (unless there are some that I'm not aware of, which is possible). The "remote ports" feature wasn't enabled by default, as a full integration with Gambit would be quite a bit of work: macros in Gambit generate a lot of different procedures to deal with ports, and I haven't figured out how to fully wrap all those.
About a "portable Termite", I personally don't really care, just like I don't really care about "portable" Scheme code. Gambit does almost everything I want, and there are so many ideas I have about expanding Termite that I'd rather work on those instead.
I get almost no feedback on it, so I'm quite happy to get James comments, especially since I'm starting to care about it again. If other people have feedback of any kind, I'd really like to hear it.
Guillaume
On Dec 20, 2007 11:55 AM, James Long longster@gmail.com wrote:
I would not consider Termite production ready.
The creators of Termite describe it as a prototype. In my opinion, the source is quite a mess, with a bunch of commented out code and little organization (remote ports for example aren't usable without modifications). There's also known bugs with exception propagation which make it less useful.
With that said, Termite works very well, especially if you are willing to slap on a thin layer of code which makes up for some its current deficiencies. There's solid deserializing / serializing there as well as a few other things. It may need compression if it wants to compete with Erlang's remote messaging speed. You could make Termite production ready somewhat quickly, but I think most people are more interested in a portable Termite, and the current code is deeply integrated with Gambit.
On Dec 20, 2007 10:03 AM, Joel Reymont joelr1@gmail.com wrote:
Is anyone running Termite in production?
Is it considered production-ready?
Thanks, Joel
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-- James Long Coptix, Inc. longster@gmail.com _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Guillaume,
On Dec 20, 2007, at 7:27 PM, Guillaume Germain wrote:
The "remote ports" feature wasn't enabled by default, as a full integration with Gambit would be quite a bit of work: macros in Gambit generate a lot of different procedures to deal with ports, and I haven't figured out how to fully wrap all those.
I don't fully understand this. If you don't care about Termite portability (I'm not sure I do either) then wouldn't full integration with Gambit be the goal? Of so then why not finish up the remote ports bit?
Maybe I should dig in and try to understand exactly what the generated procedures for dealing with ports are. Any examples are appreciated!
Thanks, Joel
I don't fully understand this. If you don't care about Termite portability (I'm not sure I do either) then wouldn't full integration with Gambit be the goal? Of so then why not finish up the remote ports bit?
Gambit's internal system uses macros to generate procedures quite a bit. This makes it sometimes tricky to wrap some of Gambit's functionality with another interface.
Personally, I don't want any of Gambit's port procedures overridden. Make a new library of remote port procedures. I guess I don't see Termite as much of a 'language' as an extension to Gambit. It would be annoying, for several different debugging / testing reasons, if I couldn't access the real console or repl port. It seems clearer to have a level of code which works on abstract level and doesn't care whether things are happening remotely or locally (in which case it would always use the remote-* procedures), and also a lower level of code which does care and can rely on Gambit being left as is.
Then you can just define a simple, clean remote-ports interface, and not worry about wrapping every single gambit function. Here's my current remote ports library. I also have a remote repl library which can start a Gambit repl on any Termite node that has the remote ports lib; if anyone wants it I can post it.
Great to hear that your working on it Guillaume! It
;;;; Remote Ports ;;;; ;;;; TODO: Add support for bidirectional ports
(declare (block) (standard-bindings) (extended-bindings))
;; Remote Port Parameters (define current-remote-error-port (make-parameter (spawn-output-port (current-error-port))))
(define current-remote-input-port (make-parameter (spawn-input-port (current-input-port))))
(define current-remote-output-port (make-parameter (spawn-output-port (current-output-port))))
;; Managing Remote Ports (define (make-remote-input-port port) (spawn-input-port port))
(define (make-remote-output-port port) (spawn-output-port port))
(define (remote-output-port? obj) (termite-output-port? obj))
(define (remote-input-port? obj) (termite-input-port? obj))
(define (close-remote-input-port proc) (! (termite-input-port-pid proc) (lambda (p) (close-input-port p) (halt!))))
(define (close-remote-output-port proc) (! (termite-output-port-pid proc) (lambda (p) (close-output-port p) (halt!))))
;; Remote Input (define (remote-read #!optional (proc (current-remote-input-port))) (!? (termite-input-port-pid proc) read))
(define (remote-read-char #!optional (proc (current-remote-input-port))) (!? (termite-input-port-pid proc) read-char))
(define (remote-read-line #!optional (proc (current-remote-input-port))) (!? (termite-input-port-pid proc) read-line))
(define (remote-peek-char #!optional (proc (current-remote-input-port))) (!? (termite-input-port-pid proc) peek-char))
(define (remote-char-ready? #!optional (proc (current-remote-input-port))) (!? (termite-input-port-pid proc) char-ready?))
;; Remote Output (define (remote-write obj #!optional (proc (current-remote-output-port))) (! (termite-output-port-pid proc) (lambda (p) (write obj p))))
(define (remote-display obj #!optional (proc (current-remote-output-port))) (! (termite-output-port-pid proc) (lambda (p) (display obj p))))
(define (remote-write-char obj #!optional (proc (current-remote-output-port))) (! (termite-output-port-pid proc) (lambda (p) (write-char obj p))))
(define (remote-pretty-print obj #!optional (proc (current-remote-output-port))) (! (termite-output-port-pid proc) (lambda (p) (pretty-print obj p))))
(define remote-pp remote-pretty-print)
(define (remote-newline #!optional (proc (current-remote-output-port))) (! (termite-output-port-pid proc) (lambda (p) (newline p))))
(define (remote-force-output #!optional (proc (current-remote-output-port))) (! (termite-output-port-pid proc) (lambda (p) (force-output p))))
(define-macro (%%parse-output-args args) `(if (remote-output-port? (car rest)) (values (car rest) (cdr rest)) (values (current-remote-output-port) rest)))
(define (remote-write-all . rest) (receive (port objs) (%%parse-output-args rest) (for-each (lambda (obj) (remote-write obj port)) objs)))
(define (remote-display-all . rest) (receive (port objs) (%%parse-output-args rest) (for-each (lambda (obj) (remote-display obj port)) objs)))
(define (remote-pretty-print-all . rest) (receive (port objs) (%%parse-output-args rest) (for-each (lambda (obj) (remote-pretty-print obj port)) objs)))
(define remote-pp-all remote-pretty-print-all)