Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - silenus

Pages: 1 2 3 [4] 5 6 ... 14
Drivers / Re: new driver development.
« on: August 30, 2017, 09:51:26 AM »
I think that FallenTree's stuff has a lot going for it and probably it is being used in situations where there is more active development (chinese muds). I think perhaps the english speaking community has grown too small for him to feel that it's worth the effort to support even though it isn't that much work really IMHO. It just requires setting up some integration testing system where one at least can boot the existing mudlibs with various different compile options.

I talked to him via email and it seems he is not willing to do it so I am not sure if I will help out in his efforts to further improve the system.

Writing a driver is a much easier task than it use to be given that we now have many vm based languages supporting features such as dynamic loading. One can basically write a LPC->lang of choice transform with instrumentation for dynamic checks need for security etc. and have all the code run directly on the vm without having to write your own.

It would be nice to have some help once I have the basics taken care of (language transformer and lightweight runtime). Since there are certain portions of the conversion process which requires a lot of grunt work and might take sometime unless there are a sets of hands doing it at the same time such as reimplementing the various efun packages and perhaps the language parser for dead-souls which i don't really understand that well.

Drivers / Re: new driver development.
« on: August 29, 2017, 09:11:05 AM »
I think is also room for new ideas in how a programmable system like an lpmud driver should run nowadays. I have recently become interested in probably somewhat old stuff to most people- cloud computing via AWS and NoSQL style databases like Cassandra. So I have been wondering if a mud could be backed by some of these kinds of systems and be distributed over multiple machines for robustness.

Drivers / new driver development.
« on: August 29, 2017, 08:55:49 AM »

Given that FallenTree is reluctant to add support for the old mudlibs with the 3.0 release I was wondering if anyone might be interested in working on a new driver. This is kind of a project I have been thinking about on and off for sometime. My current idea is to write it in either Java or Node.js. My main reason for selecting Node.js is because I would like to learn the language (or typescript) but Java has a concurrency model that could potentially support more features in future (such as the STM like stuff they have in Hydra). The idea is to be fully compatible with the FluffOS 2.xx line.

I have some reasonably detailed plans that I have outline over the years and now have perhaps a few months to work on it. I suspect given that I can combine and clone the actual grammar with the ANTLR grammar in the code vault it might be possible to get lillib to compile and run. If anyone is interested in helping out a little bit let me know. I think it would be fun.



Open Chat / Re: Elder Scrolls Online
« on: August 29, 2017, 08:43:41 AM »
I was playing a little bit on PC but haven't tried the PS4 version or the latest Morrowind expansion. Is it any good?

Drivers / fluffos 2.xx line
« on: June 24, 2017, 01:28:05 PM »
I actually have already forked the fluffos 2.xx line from quix's 2.27.2 and made some minor modifications to make it compatible with freebsd and os x. This basically involved adding back some removed code when posix timers is undefed in the driver. I will try to make some more changes to this fork tomorrow by migrating the basic build script to cmake (not the edit source though). I am curious if anyone has any other suggestions for changes to the driver if I find time to implement them on weekends. Some things I have considered include rewriting the array and mapping code to use stl and possibly the string handling to rely on std::string. I think a garbage collector would also be a nice addition (this sort of exists already in ldmud). Ideally if I get everything cleaned up and sorted out Wodan might give me permission to release a 2.28 that unlike the fluffos 3 line retains compatibility with existing muds.

Intermud / i3 client code sample
« on: June 24, 2017, 01:19:38 PM »
I am thinking of writing an i3 client as an exercise to teach myself a bit about networking and C++. I was looking over the documents on wotf is this a good place to start? I assume that basically on top of a client written in lpc like the ones in gurbalib or ds I would need a mudmode parser. Otherwise I am good to go?

General / Re: MUD documents and webpages
« on: June 17, 2017, 06:07:32 AM »
I have a repository that has a slightly modified fluffos 2.27.2 that restores some old code to make it possible to run fluffos on os x and freebsd. See the commit log for more details of changes.

Drivers / Re: new year resolution
« on: January 09, 2016, 03:52:12 PM »
I was initially thinking about writing a JIT for either fluffos or dgd but came across this problem as a potential issue. I think dworkin indicates he has already started laying the groundwork for a JIT for dgd so I am wondering if it would be good idea to have one for fluffos or just modify dgd so it can run the same code as fluffos does (or something that is semantically close enough that it is easy to convert). Currently that project has a less restrictive license.

Drivers / Re: new year resolution
« on: January 09, 2016, 11:18:44 AM »
Maybe changing object pointers to object handles to make it so that you dont have to do datastructure and stack scans after destructing an object?

Drivers / JIT compiler revisited for Fluffos/dgd
« on: November 05, 2015, 01:38:00 PM »
I noticed some old posts mentioning the inclusion of a jit compiler for fluffos might be in the works. Is this now no longer the case? I think that the upcoming 3.8 release of llvm with patchpoint and stackmaps might be suitable for this sort of thing. The work involved however is quite significant since fluffos unlike dgd has a lot of efuns and packages that directly manipulate the stack which would all have to be reimplemented to work with the new virtual machine. I am also curious also about the old c code generation that mudos IIRC use to have... Is this code still available somewhere? I am sort of curious how this problem was addressed given the plethora of efuns.

I am actually tempted to take a few months to work on this and give it a go. Converting the icode.c to generate llvm code directly and rewriting some of the apply and call hooks to call llvm::Functions pointed to by new program tables would be the main challenge.

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 07:09:55 PM »
I was actually beginning to wonder about that after I posted that but I suspect there might be a way to have function pointer forms persist through save/restore_variable like reflection functions. The idea would be to have a function_info return a call_other representation of the function pointer including the arguments and leave it up to the user as to how to best to serialize the information. As for code I suspect that functionals don't have an object context (I don't think anonymous functions do either) so they could more or less be floating blocks of code.

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 09:46:10 AM »
Thanks Dworkin. I was at one point interested in trying to implement some sort of anon funcs into dgd hence the question. The issues I suspect are somewhat similar- since to save an anon func means also that the save file has a lifespan perhaps exceeding that of the program from which it is generated. For function pointers the problem might be resolvable by down stepping the method index reference back into a function name as a string and re-resolving it when the pointer is loaded from storage. The more general solution would be to keep a string representation of the code handy and recompile it on load. That might be quite a lot of work since one would have to hack into the compiler as well. I havent explored yet as to how difficult it would be to get the existing code base to do this- I am still tracing out the execution paths between the interpreter and the f_function_constructor and the functions module as well as looking at what the AST generation and code generation does.

Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 07:23:52 AM »
I might be wrong about this but I suspect that function pointers in dgd work be okay if you assume a sort of late binding i.e. make the function point just hold the object or program on which the pointer is called plus a string and arguments. I.e. a sort of on demand delayed call_other with no guarantees that it points to anything of if it ever did. I am not sure however with object upgrades how lambda closures (anon-funcs) could be made to work since in principle you either carry the code with the variable or compile the code into an object which is nameless and point to it. Could you not have an nameless object hold the code and have the function pointer point to the code in a nameless object that gets compiled on the fly? Depending on the copy semantics one could perhaps even use an lwo.

As for upgrades- I know dgd currently automatically restores the data, but I wonder if another approach might be to pass the old version of the object to the new object in the upgrade() function and use some form of reflection variables(), set_variable(), fetch_variable() to get at the old data and xlate it across. This would allow for the new recompiled versions of the object to construct new lambda objects using new code making it possible to upgrade the code pointed to by the anon funcs given the old functions with perhaps the right reflection routines. If the closures hold data i.e. are collectors this might be a bit complicated though.

Drivers / function pointers and anon funcs
« on: October 31, 2015, 01:46:19 PM »
I am wondering if it would make sense to try to make function pointers persist and save like other types of data in lpc. I am not entirely sure how to go about this after looking at the code- but it would seem to be possible in almost all if not all cases. The main issue is that the object file might become out of sync with the program file and make no sense when calling the lfun index or offset or in the case of efuns or simul efuns if the driver or simul efun object is updated. There are currently 5 types of function pointers defined in lpc excluding the bindable flags. This also seems like a lot in modern times since I dont think the efficiency gains in terms of having bare function pointers to lfuns and efuns/simuls offer much in terms of performance savings. Would it make sense to more or less merge all these into a single case?

Drivers / Re: Contributions to the driver
« on: October 29, 2015, 10:42:09 AM »
I think I get what you mean by bridging now but I think you are still at the mercy of certain things by doing this that developing on an lpmud server prevents.

1) malicious code execution that modifies or deletes data.
2) denial of service type code execution that deliberately starves resources via infinite loops etc.

I don't see a good way around this other than rebuilding a layer on top of whatever as I mentioned. I think also by doing this one is no longer really operating in lpc. In general this isn't necessarily a bad thing but it makes it difficult to program the system when it's running along side other users because of the two issues above.

Pages: 1 2 3 [4] 5 6 ... 14