Compiling a new section to a running app..

Started by Hardcoal, October 22, 2017, 21:01:07

Previous topic - Next topic

Hardcoal

Hi.. May be a silly question but worth asking for me.

Is it possible to attach a new compiled code to an already running code somehow?

What I mean is.. In my Editor while it runs and I want to add a new Type..
but i dont want to compile the whole Editor  and restart it..
I want to be able to add a New Type while it runs..
Somehow..

My Editor And The Engine are both one part..
Maybe I need to seperate them..

Any Idea on how to do that will be welcomed..

Thanks
Code

Derron

Do it in LUA ... and reload the scripts. Before doing so, inform the script about the reload and retrieve a serialized save-state from it. Then you could send that data after reload so the script can return to its state.


So if you have some kind of custom script, then you might think of doing a similar thing


bye
Ron

GW


Darren's 100% correct.
It's possible, but there is really no advantage over using lua.
I've written some projects with NG where I run/reload lua scripts thousands of times a second accross all the cpu's cores and it's smooth as butter.  I've never done it in a way where I increase the namespace. but lua is still best option. 

Derron

There is another thing you could do with lua...

When let BlitzMax interact with Lua there are special hooks you could use. So you could expose a special type/class to Lua ("TFunctions"). When Lua now tries to run a function of that class/type ("MyFunctions.funcXYZ()") then BlitzMax is asked to run a certain function ... and return the desired result type.

This is the moment you could hook in, so that a dynamically assigned function is run - or your internal script system is called and evaluated.

Means: basic idea is to execute individual stuff when the external lua is requesting a function call / access.

bye
Ron

Hardcoal

thanks derron .. :) ill check those options..
Code

Derron

Maybe this helps a bit:
https://github.com/GWRon/Dig/blob/master/base.util.luaengine.bmx

Check for "method index:int()" as this is there to make functions known to LUA. "indexNew" is used when trying to assign field-values of BMax types.

That way you could expose things which are not really existing in your code - and are only there in a custom script/definition done in your editor.

You can even create the needed Lua "in memory", so you do not need to ship LUA files with your app. LUA is then just used as "helper". And of course there are surely better approaches to achieve a similar effect but for them I am too less experienced and missing a lot of knowledge (talking about C ;-)).


bye
Ron

Hardcoal

honestly i dont know what LUA is to start with..
Is it another programming language that i need to learn?
Ive checked some videos on Youtube about it though..

Im too busy on other stuff in my programming to deal with this ATM
But This info may help me in the future..

So Tnx Derron for all your effort
Code

Rooster

Yes it is another language, and has some quirks. I don't know much more than that.

col

#8
Hiya,

I had this idea working a while ago...
I used BlitzMax itself as the scripting language. I mean why should we learn *another* language to write scripts. One valid argument there is that just because the main application is in a specific language then why should the scripts be too - this only really benefits the main developer(s). For modders I think they are well versed in Lua nowadays so I'd lean towards working with that.

The way I got to use BlitzMax as a scripting language was very complicated but it did work. I wrote some code to compile a bmx source file into a dll. You can dynamically load it and unload as you see fit. There are many caveats to this approach that plague all languages - the main one is cross boundary objects.

This isn't so bad with BlitzMax as it has its own memory management ( garbage collector ) but you have to be aware that objects can't cross the boundary from app to dll, and you need to do bookeeping from either side so that the garbage collector(s) don't sweep away your objects.

The method that I used was to write an Extern abstract Type and use that as an interface that's shared between the app and dll - this requires you knowing in advance the fields and methods of the Types.

Or better still would be to create your own intro-spection ( reflection ) code to discover fields, types, methods and instantiate across the dll boundary - using interfaces to do so.
It's not impossible to do but it's a lot of work to get right - to be honest if you pull it off I'd buy it  :)

To summarise all of that -  - keep all dll instances within the dll and all app instances within the app, and use an 'interface' to communicate.
Either way this method may sound attractive but it's not quite as straight forward as you'd think. Certainly nowhere near as easy as using Lua.
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

Hardcoal

interesting Col.. you sound like a pretty advanced programmer
I can pull off almost anything i set my mind too :)  at least that what has occurred up till now.

Its still not time to mess with this.. its the last thing on my list.

And I admit. I barely understood what you are talking about :p

Im not sure I really need this approach of adding code to a running app..
but it does ignites some unrelated ideas..
Code