On 2017-12-09 13:40, Alex Tweedly via use-livecode wrote:
Would it not be easier to transform the text blocks in to a (series
of) "put" statement(s) ?
Being "put"ted is exactly what is going to happen to the text in the
non-code blocks, so why not just do that.
Are you sure they would be put'd? ;)
The use-case I was inferring was one of 'emulation of LC server inside
the IDE'. Richard wasn't all that specific about the tooling he has for
LiveCode CGIs, but I have assumed that the tooling *does* abstract
output - after all, 'non-targeted put' in the IDE puts things in the
message box - which is great for looking at, but not so great if it is
going to be fed into something like a browser for display.
Since we are talking about emulation (in this case basically 'compiling'
a LC server script to a LiveCode Script to be able to run it outside of
LC Server), the actual intermediate script which runs the same as the
original doesn't have to be readable by humans. After all - when
debugging you don't look at the machine code generated by a compiler but
at the original source instead. The error positions and such can be
easily mapped by using a sideline array which maps line/row indexes in
the intermediate script back to the original - i.e. the intermediate
script is just an implementation detail.
Of course, the thing here is that mechanism which allows an emulation
also allows a conversion (i.e. forever leaving the LC Server style
behind) - the difference is just how the inline text / and
server-specific commands (e.g. put output, put unicode, put header etc.)
are translated. In that case, I agree that pre-processing the text
blocks and churning them out as a sequence of 'envPut <string>' would
make much more sense (envPut here because, as discussed above, 'put' is
not *necessarily* suitable).
Another option would be to turn 'put' into a 'put ... after ...' and
then return the string (this would then be very much 'merge'-like).
Again, the variability here is just how *that* specific command is
converted - which could easily be made an option of the compiler script
which does the conversion.
Anyway, would what I suggested (in terms of a LCServer->LCScript
compiler written in LCS) be a useful thing?
For those concerned about performance (although performance in an
emulator is perhaps less of a concern than production), then there is no
real need to be. The compiling process can be done ahead of time, and
the cost is only once-per-server-script file - the compiled version is
an LiveCode Script so would have the same performance characteristics as
the original. Even if you wanted to use such a thing in a dynamic case
(e.g. merge like), then chances are each template file would be being
used more than once, so you actually gain performance after the initial
compile.
In this case, a C++ solution would offer no real advantage - in fact a
huge disadvantage in terms of development time, maintenance and
adaptability.
Warmest Regards,
Mark.
--
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
