Write and run code in standalone

[mrcoollion]

Hi LC specialists,

I have an idea for an application where i need to be able to have a user run my standalone and be able to write code in LC script in a pane (e.g. field), have it syntax checked and run it .
Is this possible and if yes how?

Regards,

Paul

[dunbarx]

Hi.

Simple, no?

If I make a stack with a button and a field, and put this in the button script:

Code: Select all

on mouseUp
   do fld 1
end mouseUp

And in the text of fld 1:

Code: Select all

answer random(999)

If you click on the button, you get a random number. Simple, no? If the user then types this in line 2:

Code: Select all

answer any item of "a,b,c"

You get two answers. Simple, no?

Now I make a standalone. The "answer dialog" inclusion is in.

Two problems.

One, I cannot imagine how the standalone can validate what the user types into that field.

Two, the standalone I make with that simple stack does not work. Not sure why, since I make much bigger standalone than this one all the time.

I am depressed.

Craig Newman

[jmburnod]

Hi Craig,
It works in standalone as expected here (LC indy 9.0.1) even with two lines in fld 1

btn script:

Code: Select all

on mouseup
  do fld 1
end mouseup

fld content:

put 1000 + 99 into tNum
answer random(tNum)

best
Jean-Marc

[bogs]

My first idea was a depressing one, and that is that your idea sounds an awful lot like creating a development environment, something precluded by the licensing terms (at least as I understand it).

The syntax checking part would be relatively easy, even using a more manual approach than the script editor does. You could for instance, setup custom properties for the propertyNames, the commandNames, etc. (Dictionary) down the line. You'd have to fill in anything that isn't easily grabbed yourself, I forget the total count.

Then you would check text typed in just like you would for anything comparing text.

Not sure about the running code part, like I said above, it borders close to creating your own competing IDE.

[mrcoollion]

Thanks for the answers
I will try some of the suggestions and see where i get beached.

If I have got something working I will post it here . No promises though

Regards,

Paul

[dunbarx]

Hmmm.

Remaking, without change, a new version of a standalone seems to have fixed the problem. There should not have been a problem in the first place, but, well, you know.

But is that really what you had in mind? To have a "feature" of your application that allows one to execute their own lines of code? Doesn't this imply the app is intended for experienced LC authors? Who else is going to be able to tailor their needs that way? In other words, please give me an example of what someone might type into that field, that is then executed to yield some result not built into the thing in the first place.

I have never heard of such a thing.

@Bogs

The syntax checking part would be relatively easy,

How? How can you write your own parser? If the user types into the field:

Code: Select all

put random(999
put randon(999)
put "XYZ" into lost field
add 3 to field 5

What will you do? Determine that "randon" is not in the dictionary? That a function has to have a closing ")". That a lost field is a lost cause? That "cat" is in field 5, and this presents a problem?

Possible, sure. A long and tedious process? Surely.

Craig

[bogs]

What will you do? Determine that "randon" is not in the dictionary? That a function has to have a closing ")". That a lost field is a lost cause? That "cat" is in field 5, and this presents a problem?

I'm sorry, I thought that I was pretty clear about what I meant by syntax when I described it, but maybe I was off, or used the wrong word

In the case of my post, I was referring strictly to the keywords, commands, functions, etc written into the field. Certainly 'random' is not spelled 'randon', so yes that would be easily caught. Same with lost vs. last, etc, simply by checking whether it exists in the custom properties I mentioned. The much harder to catch things would be variables, but really if the rest of the structure is there, the variable wouldn't trigger an issue either (you'd have to allow for it based on context).

The script editor has a pretty nice example of it, Mc's was pretty basic and easily gone through, Lc 6 and up is still fairly well documented though and easy to navigate.

As to whether a parenthesis or other matched pair characters have been closed or not, I think handling that for the user is probably the simplest way, i.e. as the editor does by default now by inserting matched pairs, but you could certainly make sure if one exists, it is matched before or after. If nothing else, you could test for any possible character as an item delimiter.

As to how long and tedious a task it would be, I suspect that would depend on what exactly Paul is trying to accomplish and how thorough a check is needed, at it's simplest levels though, probably not too bad.

[richmond62]

I have a feeling that what you are suggesting breaks the EULA of LiveCode,

[FourthWorld]

My first idea was a depressing one, and that is that your idea sounds an awful lot like creating a development environment, something precluded by the licensing terms (at least as I understand it).

The proprietary editions of LC (Indy and Business) do, last I recall, have a prohibition on using LC to produce apps that allow the end-user to do scripting, to minimize risk of someone using LC to create a product that competes with LC.

The GPL-governed Community Edition has no such limitations. The GPL explicitly allows using and modifying the software for any purpose.

As for the technical side of this, "do", "value", and "call" are provided for edge cases not covered by inline execution. Handy when you need 'em, but it's rare that they're truly needed; there's usually a with-the-grain solution.

mrcoollion could solve this as I did in devolution's custom scripts, the way every LC-based IDE solves this: put the script into an object and send the object a message to execute it.

This will give you everything the engine has for delivering robust and efficient execution, with built-in error-checking, and even options to script out debugging if you're ambitious.

When you set the script of an object to some text, the engine attempts to tokenize it, analysing it for conformance to what the engine expects for execution. If an error is found it'll put that error info into "the result", allowing you to know which line is causing the issue, and the nature of the problem.

This is how LC-based IDEs do it. It's how the engine is designed.

My t-shirt:
Know the engine.
Trust the engine.
Use the engine.



Let the engine do the work where it can.

[bogs]

The proprietary editions of LC (Indy and Business) do, last I recall, have a prohibition on using LC to produce apps that allow the end-user to do scripting, to minimize risk of someone using LC to create a product that competes with LC.

The GPL-governed Community Edition has no such limitations. The GPL explicitly allows using and modifying the software for any purpose.

Thanks for the clarification, I found it totally confusing from reading the licenses

[mrcoollion]

So here is a first simple and working attempt.

UserCodeRunTestV01.zip

(29.79 KiB) Downloaded 220 times

It also works as a standalone (for me that is Windows) but you have to build it yourself.
To be clear... it is not my goal to build another language for developing applications. My goal is to give users the 'programming' tools to enable them and have the freedom in doing complex arithmetic and logic's based upon variables I provide.

This could be useful e.g. for little kids to learn then the simple basics of LC programming piece by piece.
Or in my case to see if I can build a trade-robot in which the users are able to build their own trade-rules.
I have set-up a reliable and fast working connection with LC to a broker so I though why not experiment. And as most of you know one leads to another ...

Any ideas an suggestions are welcome.

Regards,

Paul

[jacque]

Besides the EULA, it opens up your app to malicious intent. It wouldn't be hard to delete files, rename critical infrastructures, insert malicious files, etc. While children learning LC probably wouldn't do this, someone else might. So if you build this, you'll have to be scrupulous in sanitizing any input before executing the input commands.

That said, all script errors can be caught with an errorDialog handler. But I really do advise caution.

[dunbarx]

Bogs.

No apologies between us, ever, please.

I was not attacking anything you said. Perhaps I do not understand what the intent of the OP is.

Reading further past those posts, I see something of that intent, that a test line or lines of code can be evaluated simply to see if it breaks internally. As a teaching aid, well, OK, in that the student does not need to work in the script editor at all. But this leaves much on the table, as the script editor is fairly good at pointing out the deficiencies and location in the line of errors

It is another discussion entirely, the merits of this sort of teaching method, that a new user is held back from testing in the SE.

@ mrcoolion.
So is it only a teaching aid, to allow a student to test code in a field right in front?

Craig

[mrcoollion]

@ Craig,

There is already a simple errorDialog handler in stack I posted.

I have no plans in developing an application (yet). But it could be nice to have someone build an application in which kids (e.g. between 6 and 8 ) learn about put, answer, ask, if then else , While, Arrays ect without them having to use the editor. And at a later phase they can start to use the LC editor to build actual applications.

I also have some other ideas I can use this technique for. None of them should be a problem for the LC EULA .

Regards

[bogs]

Bogs.
No apologies between us, ever, please.
I was not attacking anything you said. Perhaps I do not understand what the intent of the OP is.

No problems, I just figured I wasn't clear enough (I'm so often foggy anyway ) the first time

Besides, my ideas tend to leave my mouth before I think them through. Creating a parser certainly would be a cat of a different stripe and shouldn't be approached lightly, least not if you want it to work correctly heh.

This will give you everything the engine has for delivering robust and efficient execution, with built-in error-checking, and even options to script out debugging if you're ambitious.

My thinking for error handling ran along these lines that Richard posted, wait till it flubs basically, then find out why from the engine.