Debug REPL Help

[charJe]

When I connect to the running application using telnet. The repl appears in the shell where I ran make install like so

==> attempting to install linux application DemoRedSquare to local desktop..
==> Starting application..
----
LambdaNative REPL
DemoRedSquare 1.0
Built 2020-07-30 18:13:00 (00h 00m 29s ago)
------------- REPL is now in #<thread #2 unnamed_thread> -------------
> 

In the shell where I run telent -4 localhost 7000 I get only the regular telnet output, no repl. I know the are connected though because the repl doesn't appear until I run telent and when I terminate make install, telnet also shuts down. It is as if it is not piping the repl correctly through the internet port. Inputs into telnet never make it to the repl and nothing makes it back.

[mgorges]

No idea - this seems related? https://mailman.iro.umontreal.ca/pipermail/gambit-list/2013-September/006975.html

[mgorges]

@fungiblecog or @clpetersen were the ones who contributed to modules/ln_repl, so maybe one of them can help?

[charJe]

I'm not sure if it is related to that, but the repl I do get is also very slow. Separately from the DemoRedSquare, the web-repl works properly for me on it's own.

[charJe]

I hacked something together. It is not as fast as I hoped, but it is far better then running make; make install; every time I want to refresh my gui. https://gist.github.com/charJe/2ca7dfd56cfda0ec5c8eced9db1d19bc

Advantages to make; make install:

• faster compilation
• more interactive
• better error messages

Disadvantages the usual gambit REPL:

• none of the debugging , commands work. It just spits out the error and moves on.
• a little slow but still faster than what I got to work with ln_repl.

[mgorges]

There is also apps/tcprepl, but it seems to be a console app, so I can't speak to its utility for your purposes.

[charJe]

It looks like my tcprepl module is nearly identical to the tcprepl app. I was just missing the close connection. It would be nice to have the full gambit debugger though.

[charJe]

I have revised my gist to allow devices other than localhost and to fix an issue where the client would terminate leaving the thread to overpower and cause the server a lot of latency.

[Kyuvi]

I was having the same issue and I traced it back to this commit 9f2403be16a75430d8839064fb137b6d978267e0 for "modules/ln_core/log.scm" where make-safe-thread was used to overwrite make-thread.

Gambit's make-thread function takes 3 arguments and this version of make-safe-thread uses only two, so when given a third by the repl-server function in modules/ln_repl, it just ignores the name and group and makes a thread named "unnamed_thread". I am not quite sure why this results in a repl in the wrong terminal, but setup-ide-repl-channel sets up a channel connected to the group name and maybe this channel is not then used.

Removing the overwrite of make-thread with make-safe-thread corrects the issue as does a more accommodating make-safe-thread function.

The one I am using at the moment is

(define make-safe-thread
  (let ((make-thread make-thread))
    (lambda (p #!optional (name 'unnamed_thread) tgroup)
      (let ((p2 (lambda () (current-exception-handler log:exception-handler) (p))))
        (if tgroup
            (make-thread p2 name tgroup)
            (make-thread p2 name))))))

and I am happy to make a pull request for that but maybe a more accurate one using the macro-absent-obj from the file "~~lib/_gambit#.scm" as used in the original make-thread function might be better.

On a side note, is there a reason that LambdaNative seems to prefer (args . rest) over (args #!optional opts)? Of course it could be compensated for in make-safe-thread but I just used #!optional like in the original make-thread

The OS I am using is Debian 11.

[mgorges]

Thanks @Kyuvi - upon quick inspection, this works and doesn't break anything else, so I added it. I don't understand macro-absent-obj sufficiently to make the other modification you suggested.

Regarding the use of (args . rest) over (args #!optional opts), this is a question for @clpetersen, who started the framework. I can't speak to the design decision. Still, you are correct that #!optional is barely used and found almost exclusively in code contributed by developers other than the team at BC Children's.