41–50 of 193 posts
It would be great to get a common lisp supported in Light Table...
People still use common lisp? ducks In all seriousness, the plugin architecture will certainly allow for exactly that to happen. If you're interested in trying your hand at adding CL, I know a guy who could probably sneak you into the beta when it turns private ;)
Earlier quoted context omitted.
People still use common lisp? ducks In all seriousness, the plugin architecture will certainly allow for exactly that to happen. If you're interested in trying your hand at adding CL, I know a guy who could probably sneak you into the beta when it turns private ;)
I stopped serious use of common lisp about 5 years ago - but jokes about lisp not seeing serious use still hurt. :)
I await my lynching. :D
It would be great to get a common lisp supported in Light Table...
People still use common lisp? ducks In all seriousness, the plugin architecture will certainly allow for exactly that to happen. If you're interested in trying your hand at adding CL, I know a guy who could probably sneak you into the beta when it turns private ;)
Earlier quoted context omitted.
The big difference is that you lose state every time you do that, the main goal with the eval in LT is to prevent that :)
If there is a way to consistently inject the input to the program (to lead to the same state), I would be OK with editing a Go program to cause (behind the scenes): 1. moving a break point 2. recompile 3. run 4. stopping at new break point I think that happening behind the scenes could be made to appear like live editing in other languages. Go is fast enough compiling and fast enough executing that I think it could b…
It is an interactive process. You are build pieces of the application bit by bit.
There is no complete application state where to set breakpoints.
Earlier quoted context omitted.
You know, I looked into this briefly and based on the way go works, it's not clear to me how useful it would be. Go doesn't really have a good REPL, which is an indication. If there was a decent way to handle dynamic evaluation though, it could certainly be added, and without too much issue I would imagine :)
Go compiles so fast you can just pretend there is dynamic eval. People sometimes use the "go run" command to compile and run Go source in one operation, that is not really too different from just invoking an interpreter. Go provides a lot of tools to parse Go source, I imagine between that, Go's fast compiler and GDB support it wouldn't be as hard as many compiled langs to support. Also if I am figuring out something…
Yes, the Go people keep mentioning that. You might as well eat soy and pretend it's a delicious steak.
For people that have used good REPLs, from Lisp machines to iPython, it's not the same thing at all.
You lose your state, you loose context, you loose good introspection, etc etc. And if you try loading stuff that's big (several packages as dependencies etc), the compile time starts adding up too.
Nice work.
I am very excited to play with Python eval on Light Table. I am on Windows. Python PATH is not set. So I had set it in Command-line. cmd was able to execute Python, but light-table is not able to detect Python PATH. How can I set Python PATH in Light Table on Windows?
Pleaseeeeeee