I'm getting a "Couldn't find node.js" error when trying to connect to a node app. node is at /usr/local/bin/node
Light Table 0.4 released
151–160 of 193 posts
Re: Light Table 0.4 released
#152I'm getting a "Couldn't find node.js" error when trying to connect to a node app. node is at /usr/local/bin/node
Yep, me too - it's a known issue. https://github.com/Kodowa/Light-Table-Playground/issues/448
Re: Light Table 0.4 released
#153Earlier quoted context omitted.
The plugin architecture is something we have to be deliberate about given that it allows you to do literally anything we can do. I talk a little bit about the plan moving forward at the bottom of the post, but gist is that there's going to be one more public release, and then the private beta (for KS folks) is going to focus on really hammering out how we expose LT to plugins.
Is there a way to preorder in order to get into the private beta as well? I wasn't with the Kickstarter crowd. If plugins are as powerful as you say they are, I'm very interested.
The Double Fine Adventure guys are doing that, for an example of how it could work. They call the second round supporters 'slacker backers' [0].
I would also pre-order now if I could.
Re: Light Table 0.4 released
#154When trying to download using chrome, I'm getting a warning, saying "LightTableWin.zip is not commonly downloaded and could be dangerous." Guess it is a false positive.
So as long as a piece of malware is commonly downloaded, you have nothing to worry about.
The really popular malware WILL have fixes in an antivirus/malware database ;)
Re: Light Table 0.4 released
#155Earlier quoted context omitted.
Yeah, virtualenvs support is an absolute must have for it to be considered seriously for Python development.
If you run LT from the command line after you've activated your venv it will use it. $ workon foo $ /PATH_TO_LT/LightTable.app/Contents/MacOS/node-webkit
That worked. Thanks!
Re: Light Table 0.4 released
#156Maybe I'm doing things wrong and I haven't seen anybody mention this, but ...
... all of my code is on remote machines. Either in a VM or on a server, far, far away.
Is there a way to use SFTP to open files for editing?
Re: Light Table 0.4 released
#157Earlier quoted context omitted.
Well, since you threw that out there... ...I can't believe that people use Clojure-the-language over CL-the-language. It seems to have no reason to exist except as a "I hate parens" Lisp-1. The interesting parts of Clojure (i.e., the sequence abstraction design) are replicatable in CL as a library. Extant issues (e.g., cl's map not mapping over vectors)* can be abstracted over with other tools. While the JVM interop…
You're dangerously close to trolling, but I'll comment anyway. > a "I hate parens" Lisp-1 Clojure's minimal syntax is, in my opinion, a gigantic improvement over Common Lisp. And I say this as a person who quite likes parens. I feel similarly about Lisp-1s, but that is well trotted territory: Lisp-1s have won. Parens are overloaded in traditional Lisps for both invocation and grouping. The introduction of vectors wit…
"Parens are overloaded in traditional Lisps for both invocation and grouping."
And boy do I wish they were overloaded the same way in Clojure. I hate the fact that I have to say
(cond
(some-long-predicate involving multipler-parameters)
(what-to-do has to go-on-the-next-line because-of wrapping)
(here-is-the-next predicate)
[(func1 arg1) ...])
I don't really understand the rationale, tbh (in fact I don't even know what it's supposed to be to try to understand it); somewhere I saw the observation that there's no need for you as a macro writer to make the client of the macro use parens for grouping when you can just call (partition 2 ...) on the arguments, which is true enough (at least, as long as the unpaired args in a larger group (e.g. binding vector) or are the tail of the arguments to the macro, captured as a rest param), but ... I kind of doubt that CL and Scheme went with the form of let, cond, etc. that they did out of convenience for implementation of the relevant macros. And even if that were the original motivation, those forms have other benefits.
Re: Light Table 0.4 released
#158Earlier quoted context omitted.
Well, since you threw that out there... ...I can't believe that people use Clojure-the-language over CL-the-language. It seems to have no reason to exist except as a "I hate parens" Lisp-1. The interesting parts of Clojure (i.e., the sequence abstraction design) are replicatable in CL as a library. Extant issues (e.g., cl's map not mapping over vectors)* can be abstracted over with other tools. While the JVM interop…
You're dangerously close to trolling, but I'll comment anyway. > a "I hate parens" Lisp-1 Clojure's minimal syntax is, in my opinion, a gigantic improvement over Common Lisp. And I say this as a person who quite likes parens. I feel similarly about Lisp-1s, but that is well trotted territory: Lisp-1s have won. Parens are overloaded in traditional Lisps for both invocation and grouping. The introduction of vectors wit…
Actually, I'd appreciate expansion on the respect in which Clojure is designed for interop with an arbitrary host. One (relatively uninteresting) respect in which that might be the case is that Clojure-the-language might not say anything about, say, what numeric types there are. Actually it does, though: Clojure supports ... all Java numeric types. And then there are two more Clojure-specific types. Or perhaps that is the sense in which it's designed for interoperation: it just says "we'll use the number types the host has".
Isn't it the case that Clojure and ClojureScript have different libraries with "different ideas" (whatever that means) about interop with their hosts? And ClojurePy yet other ideas about interoperation with Python? The hosts are very different in each case; how could the interoperation not be? (I suppose you could supply the host with a runtime that emulates aspects of the interoperation on the original host---but that's not very interesting!)
(Also, he mentions dotLisp in the post you reference as footnote [1].)
Re: Light Table 0.4 released
#159Earlier quoted context omitted.
Sublime Text will never be a plausible replacement for Emacs as its design does not encompass all of possibilities a lisp machine provides. Sublime Text is a plausible replacement for any tool which only targets text editing though. It has many converts or new users whose use case is only a text editor though, so to that extent Sublime Text has been successful.
I don't understand what you mean. ST3 is scripted in Python. If Python was as pervasive in ST3 as elisp is in Emacs, and provided similar concepts (buffers, regions, markers, modes, hooks, advices...), why couldn't it "replace"[1] Emacs? [1] replace here means "being as powerful as", not actually converting Emacs users, most which are happy with Emacs..
In answering this I will ignore details specific to the two tools (such as how the implementations are modified), the merits of either, how they are used, and only compare their design goals.
It is true that both tools are mutable and that hypothetically their potential use cases will overlap entirely.
The reason this will not occur though is a consequence of one tool aiming to provide a general environment by design and the other tool aiming to provide a general environment for a specific use.
Less abstractly, consider the difference between having a factory which produces a specific item and having a factory which can produce any factory.
Possibly the specific item the factory produces is sufficient for the recipients of the specific item, and further that specific item may even make other items the recipient possessed moot.
However, the factory which can produce any factory can still (and possibly already has done so) produce the specific item.
Emacs' design (and Light Table's) is much more similar in breadth to the factory which produces other factories.
Sublime Text is more similar in scope to a factory which produces a single item.
The difference in design choice leads to Sublime Text and other text editors being comparable in features and it is also why Sublime Text can replace Emacs' text editing functions.
At the same time the design choice also leads to Emacs being a RSS client but Sublime Text not also having that functionality (or being reasonable to expect), despite the potential for the functionality to exist in both tools.
The difference between the two goals is why Light Table is much more intriguing to me than Sublime Text is despite the utility Sublime Text provides and how well executed Sublime Text is.
Re: Light Table 0.4 released
#160Maybe I'm doing things wrong and I haven't seen anybody mention this, but ... ... all of my code is on remote machines. Either in a VM or on a server, far, far away. Is there a way to use SFTP to open files for editing?
you probably have to mount those.