Apologies - I missed the top post here for some reason :)
On 2017-12-05 19:18, Richard Gaskin via use-livecode wrote:
I have some tools I developed for server apps, which allow me to
develop and test both client and server within the same local LC IDE
instance. As you can imagine, this has improved development efficiency
by orders of magnitude.
Okay so you want to be able to emulate server systems *inside* the IDE -
seems reasonable, and useful.
Would it be reasonable/affordable to add some means of enhancing
desktop LC so that it can at least parse and attempt to execute LC
scripts embedded in HTML? I can emulate environment variables and the
like, but the incompatibility between LC and .lc has been a real
development bottleneck.
That is slightly tricky.
LC Server is essentially a much more traditional 'language interpreter'
- indeed it can be seen as providing a REPL at top-level.
The commands and declarations in the LC server scripts are basically
executed line by line (although a whole script is parsed first - whether
it be the initial script, or included script).
Any declarations are added to 'global scope', and commands are executed
in that 'global scope'. As soon as you call a handler in a stack, it is
the same as non-server engines though.
More specifically, global scope is actually implemented as a (root)
stack script - that stack sits between all other stacks and all
external/library/backscript type things in the message path. (In
particular variables created at that scope are not global unless you
mark them as such - they are script local to the root stack.
Internally when it passes an lc server script, the bits outside of code
markup (<? ... ?>) get turned into 'echo' commands (basically put) with
the output string being the block of text,
The placement of the root stack in LC server poses a difficulty for
emulating in the IDE - as you'd want it to sit behind all stacks which
make up the server environment you are emulating, but above other things
in the IDE. This isn't currently possible (you can kind of view stacks
which are loaded on server as being substacks of that root stack - but
substacks are only one-level deep, so its only an analog and not a true
reflection).
Also, the server-specific syntax isn't present in the IDE engine which
also poses a difficulty.
It might be possible to emulate the server environment by parsing the LC
server scripts in LCS in the IDE and fettling with them appropriately to
make up for the differences, but that isn't going to be the easiest
thing to do.
For a long time the notion of 'project' has been floating around - i.e.
a separate scope inside the engine in which applications run. The IDE
would be a project, with the applications being edited in their own
projects. This is actually largely equivalent to having the IDE run in
one process, and spinning up standalones for each application being
edited which it mutates via IPC. Indeed, the latter is actually a better
design for robustness - if one application crashes, it wouldn't bring
down the IDE (something which becomes much more important when you start
playing with FFI - C and Obj-C are not safe-friendly languages). That
model would also work for running server apps live like server apps run
- you'd spin up a server engine instead of a standalone engine.
In any case, I think I see what you would like to do - however, I'm not
sure I can offer much in the way of suggestions as to how to do it right
now :(
Warmest Regards,
Mark.
P.S. If you restrict what can be done in the LC server scripts in your
emulated environment then it becomes easier - but whether that is useful
or not depends on what the tooling you have does, and how you would like
it to be able to interoperate with server.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
