LPMuds.net

Dworkin, It is nice to know someone has finally decided to bite the bullet and do implementation work using the LLVM system for creating a JIT for LPC.

I might do something similar for fluffos in the future though i think my design differs somewhat from yours(but thanks for the heads up).

My particular repository is more of a slow burn project since I feel and a lot of the current i3 members have reflected that the community is no longer what it was and thus there isn't really too much interest people doing development of this sort at present. I am in fact not sure if any of the current muds which still have some players will actually use what I do.

Wodan was kind enough to release a new version of the FluffOS 2 series, 2.28. I have placed this code including some modifications in the repo-

https://github.com/cartercheng/fluffos-2.x

The modifications are mainly some simple fixes to get it to compile under Ubuntu due to some changes in the header files and migration to the gcc C++ compiler mode in the Makefile. I will be gradually doing some cleaning up to get some unit testing into the driver. I made some changes last week which indicate the direction in which this is going.

I think obviously you have function call checking already probably not too hard to add that if you want. I am currently working on hacking garbage collection (something that js has built in) into fluffos. Quite a bit of spadework involved. Mostly involving tracking down where candidates for the root set are. I am almost done though. I will see if I can get the whole thing finished by the end of the week. After that I will probably try to assess how much work it is to use LLVM as a JIT for fluffos. Probably try to just do some sort of call threading for now and make it very minimal.

I am not a C++ expert but looking at the tripwire code it seems to do something relatively simple in concept which is to kill threads on a sort of timeout. I guess I would have to understand node.js a bit better to understand how it truly works is v8 multithreaded?

Well nowadays given how large memory is and the bandwidth available with networks I don't see it being much of a problem increasing the 8k size to something a bit higher if one happens to need it.

I am no expert on the driver but it seems that LARGEST_PRINTABLE_STRING is one of the internal defines which can be increased in size. I am not sure why fallentree separated it out in this manner. It seems that it just governs the size of 3 char arrays (two in simulate.cc and one in outbuf.cc).

Maybe you could first try increasing the size of this? Seems a bit easier than the other two options.   

I noticed there is some code in your repo for two transpilers. I do have a question and perhaps a suggestion of sorts but I am not sure I know javascript well enough to understand exactly what I am reading.

1). Is there a distinct mud library/driver code distinction in the code or is it more like a diku? If so, does the transpiler for the mudlib portion support security instrumentation?

2) If the CPU is a resource does the instrumentation check for too long executions in case of infinite loops and too deep recursions? Or is there some other means of handling this with node.js?

3) There seems to be some preliminary LPC support added perhaps a week ago or so as well. I was thinking about doing something similar but I was a bit uncertain about how to best do this in ecmascript 6. I suspect writing this is some work.

I will have to make a more detailed study of what the capabilities of the node.js platform are in order to do this probably. The basics are relatively straightforward if a bit tedious (converting in a kind of algebraically compositional manner all the primitive constructs into their ecmascript equivalents and then making sure they compose properly inductively to form the correct programs). Main problem are the security issues and getting certain "efun type calls" to behave correctly (like returning the correct portion of the call stack translated into lpc for the stacked based security).