Scripted Component

What is the "scripted arithmetic" module about?
It seems, that the input of the script is not possible in WIN10 R815.

What is the "scripted arithmetic" module about?

That's the "universal" component.
Similar to "Function component", but you load a javascript program.
So in theory you could create any component with it.

But I'm concerned about security issues:
Not sure about what can the javascript in this component do in your computer.
Someone could create a circuit with this component containing javascript that will be executed, and share it...

Indeed it should be disabled by now, at least until I have a clear idea of what can it actually do in your computer.
Nice that it does not work ...

arcachofo wrote:

What is the "scripted arithmetic" module about?

Similar to "Function component", but you load a javascript program.
So in theory you could create any component with it.
Nice that it does not work ...

I suggest to use LuaJIT instead. If you can wait a while, I can try to embed it.

I suggest to use LuaJIT instead. If you can wait a while, I can try to embed it.

Why?

Does this mean another dependency?

arcachofo wrote:

I suggest to use LuaJIT instead. If you can wait a while, I can try to embed it.

Why?

Does this mean another dependency?

IMHO it's much smaller, faster and has less dependency problems than JS.

IMHO it's much smaller, faster and has less dependency problems than JS.

About dependency, now it's using Qt Script , not exactly JS.

Qt Script is already deprecated, so it should be converted to QJSEngine.

EDIT:
The good part about this QT Script is that it only has access to the objects you pass to the Script engine, so it's much safer than just embeding code.

But anything that can run external code in an aplication is a potential risk.

Sounds good, but i'm sure it will be slower than Lua anyway.

Yet another advantage, Lua is special language for embedding, it is isolated from host application environment by default.
Qt's script language is special language for interaction with Qt application environment, it's not isolated by definition. By the way, use all Qt opportunities from simulation sounds amazing .

Yet another advantage, Lua is special language for embedding, it is isolated from host application environment by default.

That sounds interesting...

Qt's script language is special language for interaction with Qt application environment, it's not isolated by definition.

"Isolated" can mean many things...
The script is designed to facilitate inteaction with Qt objects, which is an advantage.
But is has no access to Qt application environment by default, only to the objects you give to it.

And the whole point of this component is interacting with the application.
So a completely isolated script is not very useful.

Then the cuestion of dependencies, you need Lua installed in your system, isn't it?

Let me explain a little bit more about how this component works...

The good thing about this component (and Qt Script) is that I can pass the component object to the script.
So it is somehow like "subclassing" it... you can code a new component without having to recompile simulide.
And it is simple to implement, so perfect...

But then the script have access to every member of the component and it's ancestors, including QObject.

A safer aproach would be to give access only to members that are relevant to create a component.
But this must be done one by one, making the implementation much more complex.
And it should be changed if the implementation of the component changes.

So I can't see an option that is easy and safe at ethe same time...

arcachofo wrote:I'm going to fork the scripting talk to it's own thread:
https://simulide.forumotion.com/t422-scripted-component

Thanks

---

arcachofo wrote:But is has no access to Qt application

Ok, i misunderstand this sentence:

arcachofo wrote:EDIT:
The good part about this QT Script is that it only has access to the objects you pass to the Script engine, so it's much safer than just embeding code.

---

arcachofo wrote:And the whole point of this component is interacting with the application.
So a completely isolated script is not very useful.

I mean "by default". So Lua scripts can interact with outer C program only by rules, described in this C program.

---

arcachofo wrote:Then the cuestion of dependencies, you need Lua installed in your system, isn't it?

NO, Lua includes as a library

Code:

#include <lua.h>

and has standalone app primarily for testing. Lua sources size is 350KB. It's a scripting language too and it execute scripts without compilation. LuaJIT, however, doing Just In Time compilation for speed.

NO, Lua includes as a library

And where is that library?
Whatever it is, it must be present in your system.

and has standalone app primarily for testing. Lua sources size is 350KB . It's a scripting language too and it execute scripts without compilation. LuaJIT, however, doing Just In Time compilation for speed.

Ok, I see...
Then LuaJIT must be installed in your system or simuilde should ship it.

One problem I see in this aproach is the dependency.
Shipping a language and a compiler just for this component sounds like an overkill...
QtScript also needs to be shipped, but it's easier.

But there are other things I'm not sure:
- Can the script access the filesystem?
- Can it access the network?
- Can it access the registry in Windows systems?
- Can it do requests to the system?

arcachofo wrote:

NO, Lua includes as a library

And where is that library?
Whatever it is, it must be present in your system.

Follow the link below, there is a 350 KB lua-5.4.3.tar.gz, in that archive there is a lua.h file. Lua isn't distribuable library, it must be included in the sources of the host program, so it doesn't need to be presented in system - system's Lua is for other (not embeddable) purpose.

arachofo wrote:The main problem I see in this aproach is the dependency.
Shipping a language and a compiler just for this component sounds like an overkill...

The same link:

Building
Lua is implemented in pure ANSI C and compiles unmodified in all platforms that have an ANSI C compiler. Lua also compiles cleanly as C++.

So, this 350KB is all Lua.
Lua is a interpreter, only LuaJIT is like compiler, if it means anything.
Lua doesn't use any system libraries, even stdio.h. We give it strings and integers and take a result by C functions of the host program.

arachofo wrote:But there are other things I'm not sure:
- Can the script access the filesystem?
- Can it access the network?
- Can it access the registry in Windows systems?
- Can it do requests to the system?

No, no, no, no, if you don't add to the host program additional Lua functions (or libs) that does it.

Follow the link below, there is a 350 KB lua-5.4.3.tar.gz, in that archive there is a lua.h file. Lua isn't distribuable library, it must be included in the sources of the host program, so it doesn't need to be presented in system - system's Lua is for other (not embeddable) purpose.

Ok, but that header must be in you system in order to include it.
That's what I mean by:

arcachofo wrote:Whatever it is, it must be present in your system.

Lua is a interpreter, only LuaJIT is like compiler, if it means anything.

Yes I got the idea.
And as I understand, there is a LuaJIT executable: in order to compile the script you need the compiler executable.
That's what I mean by:

arcachofo wrote:Then LuaJIT must be installed in your system or simuilde should ship it.

So as I understand, we should compile LuaJIT and ship with simulide: LuaJIT binaries and headers, and lua.h
This adds some complexity to the project, but not undoable.

This aproach of compiling the script at runtime is nice.
The next thing to check is how can it be integrated in the simulation.
For example:
- Making functions accesible to the script.
- Dealing with Qt data types.

LuaJIT executable: in order to compile the script you need the compiler executable

I suggest to use Lua (not JIT) firstly - they aren't very different in speed.
However, LuaLIT is also can be a static/dynamic library.

Making functions accesible to the script.

By The Application Program Interface.

Dealing with Qt data types.

I suggest to look at QtLua sources for a reference.

I will have a deeper look as soon as I can to have a better idea.

I suggest to look at QtLua sources for a reference.

Thanks. That looks interesting

I propose to think and discuss: is it possible to put a Verilog, VHDL processor of digital hardware description languages in this component. I think this opportunity will increase interest in the program.

Fizik_S wrote:I propose to think and discuss: is it possible to put a Verilog, VHDL processor of digital hardware description languages in this component. I think this opportunity will increase interest in the program.

I think so too, but... it's a big task for Arcachofo

I suggested similar idea https://simulide.forumotion.com/t95-spld-simulation too

Fizik_S wrote:I propose to think and discuss: is it possible to put a Verilog, VHDL processor of digital hardware description languages in this component. I think this opportunity will increase interest in the program.

That would be nice, but very complex.
I don't know even how to start.

dvarkin wrote:I suggested similar idea https://simulide.forumotion.com/t95-spld-simulation too

The idea of the scripted component came from that suggestion.
If you remember, I asked you if you can write a javascript program to do something (i don't remember what).

With Function component you can create combinational logic, but it has not memory.
Scripted component is basically the same but you can add memory and create sequential logic... and much more.

When I finish to solve the last problems in 1.0.0 I will get into this again

If you remember, I asked you if you can write a javascript program to do something (i don't remember what).

JS for a low level thing that works with 40 ns input to output delays at hardware, nah.

With Function component you can create combinational logic, but it has not memory.
Scripted component is basically the same but you can add memory and create sequential logic... and much more.

Today I think that make a triggered outputs option for a function component will be enough for SPLD-like behaviour. Tri-state SPLD outputs are used rarely and mostly for microprocessors' buses, I think.

JS for a low level thing that works with 40 ns input to output delays at hardware, nah.

It might sound counterintuitive, but input to output delays don't matter too much in the simulation.
What really matters is frequency.

Executing the code in each component is not the most cpu consumer in most cases.
Recalculating the circuit is ussually the most heavy task.

In adition the script is compiled at start, so it's relatively fast.

25 MHz

Which of JS did you mean?

PS: not 25MHz, but 25ns and 40MHz for ATF16V8B, if it matters. Cool thing, $⅓ on china market.

dvarkin wrote:Which of JS did you mean?

Qt Script, not exactly JS, but it is almost the same for this purpose.

If 25 ns or 1 ps does not matter for the simulation.
What matters is the number of operations per second.
Specially the number of changes in output pins because this is what triggers circuit recalculation.

For example, in simulide you could run an AVR at 40 MHz in real time if it does just a few changes to pins, for example a blinking led.
But running an AVR at 1MHz that toggles a led 100K times per second will not run at real time.

Changes in the circuit voltages take much more cpu than running some code in each component.

I understand about simulation.

So, what about make a "triggered" option for a function block? It will be sequencial logic at one block.

So, what about make a "triggered" option for a function block? It will be sequencial logic at one block.

I don't understand exactly what you mean, can you elaborate a bit more? perhaps with some simple example case.

Problem in function component is that is has no memory.
Indeed is has some memory because it can access the last output states (if I remember well), so it's posible to do some simple sequential stuff.