enhance "lispy --run" to run .ls files requiring other .ls files (and not leave .js files) ? about lispyscript HOT 5 CLOSED

More to do with historical reasons, you could probably run it in the same process now.

from lispyscript.

@santoshrajan So did what I wrote above make sense? I could maybe do the above change and also add the -w "directory watch" option (as described in the other isuse) sometime in the next week or two if you agree with the changes.

i.e. I was thinking these two changes are kind of complementary...

I guess the related question is I might ask at some point where the docs reside so I can update those at the same time I make changes like these. Assuming you don't mind of course. i.e. That way I might just do pull requests with both the code changes as well as doc changes.

from lispyscript.

Docs reside on branch gh-pages
https://github.com/santoshrajan/lispyscript/tree/gh-pages

The changes make sense to me. I haven't tried running on the same process
though. So if people are ok with it, it should be fine.

On Wed, Mar 11, 2015 at 9:52 PM, Darren Cruse [email protected]
wrote:

@santoshrajan https://github.com/santoshrajan So did what I wrote above
make sense? I could maybe do the above change and add the -w "directory
watch" option sometime in the next week or two if you agree with the
changes.

I guess the related question is I might ask at some point where the docs
reside so I can update those at the same time I make changes like these.
Assuming you don't mind of course.

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

Santosh Rajan
Linkedin http://in.linkedin.com/in/santoshrajan/
Twitter https://twitter.com/santoshrajan
Website http://santoshrajan.com
Medium https://medium.com/@santoshrajan

from lispyscript.

It's only semi-related but I was thinking yesterday about the "include" command as well.

I was playing more with the breakout game example and the runinbrowser stuff along with this "in browser repl" I've done (I've not done a pull request yet I hope to play a little more with it first but I do hope to do a pull request for it soon).

In that example the use of "include" was breaking because it was literally trying to run the "fs" code to read from the (non-existent!) file system right there in the browser.

It got me thinking about "include" versus "require" and whether it was just historical that lispyscript has both or if that was an intentional design decision. I do like the simplicity of "include" which is similar in spirit to "require" but not wrapping into a namespace. e.g. only semi-related but with my "in browser repl" I made a change so if you omit the "id" attribute on your <script> tag it was simply evaluating the code without wrapping it as a module. i.e. more like people are used to when just simply put javascript in a page in a <script> tag. This made it convenient to inspect e.g. the ball position etc. with this "in browser repl" Where otherwise the module wrapper would have blocked the repl from having any access to those variables.

But I did notice this plugin for browserify:
https://github.com/JohnPostlethwait/stringify
I thought this might provide a way to (optionally?) include .ls source into an app-specific browser-bundle.js to allow a way for "include" to actually work when doing the "runinbrowser" option, or for being compiled browser side with the source visible in browser which is convenient with this "browser repl".

The alternative thought was whether "include" could/should just in-line the included content prior to it ever being delivered to the browser for the "runinbrowser" option. But if so I would think the same change would be made (for consistency) for node.js usage as well (i.e. there the "include" would inline the content content prior to it being compiled).

Sorry writing too much... this stuff starts to get a little complicated - but I guess to clarify broadly where my mind was headed was whether even though "runinbrowser" isn't recommended for production usage, maybe it might wind up "recommended" during development - I think it's interesting for people doing "single page application" type of scenarios e.g. using your template stuff right there in-browser.

I think the more important short-term question I have is: would it make sense and be okay if it turned out that "include" didn't use it's separate "include search path" (as conveyed right now with "lispy -i"/).

But instead found it's files via the same module path as used by node (on the server) or by browserify (in the browser)?

I think that might help to unify things i.e. these different usage scenarios server-side versus browser-side.

(and also might be necessary to be able to use this browserify "stringify" plugin).

from lispyscript.

Done with pull request #55

from lispyscript.