@Noel/Dingbat Blump:
However, please note that comparing this with BlitzMax is unfair, because as GW hinted BriskVM *already* lets you compile a whole repository recursively, just use the BriskVM control panel. So typically you would just have to run this "repository recompiling" before recompiling your application. And because this operation is also available through the command line front end, you can even integrate this as a thrid party tool in most editors.
As for the BriskVM script Editor, I'm going to add a menu entry for this operation (I just added this to my TODO list)
@Nack:
There is no proper support for multithreading yet. This is mostly because I'm still wondering what is the best in terms of API for this, rather than hard technical problems.
Indeed, BriskVM already supports the bases for multithreading: you can schedule the timed execution of a function (I call this "tickers", you may know this better as "timers").
In addition, you can also execute scripts with a timeout, so with short timeouts you can simulate multithreading.
However this is not very user firendly, hence why I certainly don't consider it a true feature I can bragg about.
So, in the current state of BriskVM, the best thing to do is probably to do just like in BlitzMax of BlitzBasic, as I said.
However, since I'm very interested in adding some form of concurrency, I'd really like to discuss with you (and others) about what would be the best API for this.
----------------------------------------------------
(...going into the details...)
As I hinted in my public TODO-list, I'm thinking about a dual solution:
- concurrency at the level of a whole execution context, that is the host could say something like "these three contexts", I'd like you to run them concurrently. This part is technically pretty easy for me as I already have everything to handle the timeouts. If I can settle on the best API quickly, this can really be added very soon (no kidding). An additional related question is: should I provide some kind of mutex? I tend to think it's less of an issue in our case, as scripts will never run in parallel with the host (even if they run in parallel with one another), so a mutex is less of a need tha for say a C++ application.
- a more fine grained concurrency, probably synchronous (most people would not call this "true" concurrency, but this is still really usefull). I'm still very unsure about this one, and it will probably take quite some tries and discussions with BriskVM users before I come up with something I'm pleased with (or before I toss it entirely).
I'll stop here with this, as I'm going to frighten potential users who may be made to believe that BriskVM is awfuly complex (when I'm merely digressing).
If you want to discuss about the issue (and possibly have an influence on the final API for concurrency), you can come on the forum and give me your view on this.
One question I have for you is in regards to handling multiple script files (because, obviously, packing everything into one gigantic script is stupid). Can the compiler be set up such that if a script includes a BSL file, it searches for an existing BVM. If the BVM's timestamp is older than the BSL's timestamp (or the BVM doesn't exist), the BSL is recompiled on the spot and the new BVM is included.
Actually I was already thinking about doing this. See my Public TODO listHowever, please note that comparing this with BlitzMax is unfair, because as GW hinted BriskVM *already* lets you compile a whole repository recursively, just use the BriskVM control panel. So typically you would just have to run this "repository recompiling" before recompiling your application. And because this operation is also available through the command line front end, you can even integrate this as a thrid party tool in most editors.
As for the BriskVM script Editor, I'm going to add a menu entry for this operation (I just added this to my TODO list)
I'm saying there should be an option so that I don't have to do this. If it's going to look like BASIC, you may as well include that simplicity in its use as well.
I actually agree, entirely. This is why it's in my TODO-list.@Nack:
There is no proper support for multithreading yet. This is mostly because I'm still wondering what is the best in terms of API for this, rather than hard technical problems.
Indeed, BriskVM already supports the bases for multithreading: you can schedule the timed execution of a function (I call this "tickers", you may know this better as "timers").
In addition, you can also execute scripts with a timeout, so with short timeouts you can simulate multithreading.
However this is not very user firendly, hence why I certainly don't consider it a true feature I can bragg about.
So, in the current state of BriskVM, the best thing to do is probably to do just like in BlitzMax of BlitzBasic, as I said.
However, since I'm very interested in adding some form of concurrency, I'd really like to discuss with you (and others) about what would be the best API for this.
----------------------------------------------------
(...going into the details...)
As I hinted in my public TODO-list, I'm thinking about a dual solution:
- concurrency at the level of a whole execution context, that is the host could say something like "these three contexts", I'd like you to run them concurrently. This part is technically pretty easy for me as I already have everything to handle the timeouts. If I can settle on the best API quickly, this can really be added very soon (no kidding). An additional related question is: should I provide some kind of mutex? I tend to think it's less of an issue in our case, as scripts will never run in parallel with the host (even if they run in parallel with one another), so a mutex is less of a need tha for say a C++ application.
- a more fine grained concurrency, probably synchronous (most people would not call this "true" concurrency, but this is still really usefull). I'm still very unsure about this one, and it will probably take quite some tries and discussions with BriskVM users before I come up with something I'm pleased with (or before I toss it entirely).
I'll stop here with this, as I'm going to frighten potential users who may be made to believe that BriskVM is awfuly complex (when I'm merely digressing).
If you want to discuss about the issue (and possibly have an influence on the final API for concurrency), you can come on the forum and give me your view on this.