BMax Virtual Machine?

Is there a version of Blitz Virtual Machine for Max?

I think the author was working on it.

Do a search in the forums for it.

Koriolis is working on a bmax version. Lots of cool things added as well. Its not in public beta however. If your a registered owner of BVM v1 then you might try emailing him about getting on the beta test.

Heh, I'm writing my own module called BmxScript. Its working pretty well and fast I'll post it in the next few weeks.

I now plan to do a semi-public beta (open to registered BVM 1 users) of BVM 2 soon (say a month or so). BVM 2 will initially target BlitzMax (more languages should come later), for Linux, MacOs and Windows (it's already running on these 3 platforms).

EDIT: thanks for the early bug report :)

Thanks for the update, Koriolis; I look forward to testing the BVM 2 beta.

Did you tried Lua mod?

Some work can be done via that, actually I'm using it...

Wow sounds exciting K, amazing to hear how far it has progressed since I last touched it. Well done an looking forward to it =]

what is it?

A VM thing that you can do some work via "script", in contrast to compile as machine code, you can do things on the fly with script change.

If you know lua, try to use the lua module

FYI the BVM is here.
http://koriolis.free.fr/bvm/

Whats the point of this when we have lua for free then?

If you don't think you need it then you don't need it. Stop trolling this thread please. Thanks, ta.

How does the new BVM differ from the old one?

Koriolis: I have changed my email address since buying BVM years back. I will email you my new info.

BVM compiles to bytecode.

We don't have to port existing code over to Lua, we can just make small mods to our existing code.

Also, AFAIK, the Lua module is no longer official and was yanked from the official modules due to it being made by a user and not staff. The whole "no competing product" thing. User made MODs/DLLs are still a major no-no.

So can Lua if you prefer... look through the document.
Where I mean "script" can be either text or bytecode...

BVM is also a user made thing(of course, not BRL), users who choose Lua may have previous knowledge to it, or have some point to utilize it.

However they are used in different fileds, those who choosed Lua, mostly targeted to user-driven mods.

I don't think user made mods is a no-no, but I hope they're opensourced, or source available for purchase.

Except for a few exceptions, the features in BVM 1 are found identical in BVM 2.

The differences lie in a series of additions:

* a script debugger featuring the usual step in, step over (etc), runtime breakpoints, a call stack view, a variables view and a debug log.
* a more straight forward way to import other scripts.
* a better repository handling (the handling of the way scripts, modules and command sets are located on the hard drive)
* a more straight forward way of calling a script's function. In BVM 1, while calling host app functions from the scripts required no special effort on your part (you just had to declare the function in your command set), doing the reverse required a bit more grunt work. That wasn'such a big issue as the host app usually has to call a very limited amount of script functions, but I felt unhappy with it. So now the host app can call a script function in just a single normal function call. No manual poppings or pushings.
* a documentation system ala JavaDoc. In case you're brave enough to document your scripts (depending on the amount of code you write in scripts, that can very soon be vital), you can generate a documentation form your scripts and read it in your favorite web browser.
* constants in command sets, ability to include sub-command sets.
* optional "dynamic" contexts: allow to map contexts using different command sets, and in particular allows a script to import another module that uses a different command set.
* Most important, extensions to the BlitzBasic language (which still forms the core of the script language).
- reflection: look up at runtime which types are loaded, instanciate them and/or edit object fields. Primary use: write an integrated editor that can manage just any type your scripts declare.
- function pointers
- OOP: brings up inheritance and overriding.
- an option to slightly change the syntax to better suit most programmers expactations: most notably, '\' becomes '.'
- serialization: read/write your objects to disk easily.
- annotations: attach meta-data to modules, types and fields. This data can be read via reflection.
This can be very handy by example to pass pass information to your integrated editor (telling him to edit an integer field with a color picket by example).
- properties: use getters and setters as if you were manipulating a simple field:
obj.SetColor(obj.getColor() / 2) becomes obj.color = obj.color / 2
Simple, and makes code cleaner.
- Public/Protected/Friendly/Private keywords, to limit access to type members.

I also added arrays in types, though you might prefer to just use the provided TList type (provided by a

"core.bbm" module that you're likely to want to import in just any script).

For EachIn is also there.

I'm certainly forgetting a thing or 2.

Now that you're excited (at least I hope so :) ) I'll just temper a bit by saying that there is still work to do and important issues to solve. But at least it has laready become very useable.

OEJ: From my understanding, BVM is an `interpreter` for actual BlitzMax code. Instead of having to learn Lua which is a different language, you actually write your scripts in blitz code and it interprets/runs them at runtime.

We are talking about BVM, not LUA ;c)

So is the LUA module for BMax which is why it was yanked.

This is one of the most useful thnigs about BVM. It is great to be able to easily provide your EU with a solution for making mods.

Try telling that to BRL staff, lol.

Bytecode thing isn't something new, so don't need to menttion about that, many script languages did this for years.

Do practical things than theory, if you want your user to use Lua, then bind Lua, if you want your user to learn Blitz, bind BVM, so simple.

A side comment, AXE was collect and maintained by skid, no one force you to use Lua/PortAudio...etc. As you see I din't say a bit bad about BVM, however many user still sync AXE and keep using Lua, if you can't agree just don't use it.

Or you can shwo me your great stuff, then I might agree with you, seeing is believing right?

Sounds awesome, Koriolis. Looking forward to it.

Please quit trying to hijack the thread to promote LUA. BVM has been around for years and has many of us dedicated users. If you want to promote LUA, start your own thread.

Don't be rediculous. LUA mod was yanked because it was no longer compatible with a Max update and since it isn't their code it isn't up to them to keep it compatible.

I have to agree with Toby here. It was not removed because it was a competing product, it was removed due to a decision on BRL's part to include only 'home brewed' (or maintainable) code in the Pub and BRL namespaces. As far as I'm concerned, this will help in the long run to remove bugs that stem from the importing of a specific library (e.g., one that runs from a DLL which is initialized at execution time).

That said, I'm looking forward to seeing how the next version of BVM pans out since I would prefer to code in one language (or rather languages that are very close to one another) instead of going between Lua and BMax. While Lua is similar in some respects to other BASIC variants, it's still not the same.

Keep in mind that I'm not saying Lua is bad -- after all, I wouldn't have tried to make sure the Lua module is bug free and written an OO interface to it if I didn't like it.

Kind of interesting.

So what speed is there from using bvm compared to lua?

Little update, and some bad news:
The incredible incompetence of my net provider led to the loss of my resiliation form, thus preventing the creation of my *new* account. No need to go into the details, but I'm not going to get the net back as soon as expected. And that's if I'm lucky (sort of).
Net result:
- the rate of violent death among my net provider's employees is likely to climb very soon.
- the semi-open beta of BVM 2 is not going to happen as soon as planned, as it's totally not viable to manage that when I can access the net so rarely, and from other people's computers.

Sorry for that. I'm going to try to cure my frustration now. Bye.

Thanks for this additional update and good luck with your troubles.