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 ... 13
1
Drivers / Re: new driver development.
« on: April 12, 2018, 10:44:58 AM »
I have been doing some other things for a little while but I would like to get back to learning some programming. Is anyone here familiar with Rust? My understanding is that it's a systems programming language like C/C++ but perhaps a bit easier to learn and with a cleaner syntax. I am wondering how much work it would be to write a parser in it for a version of lpc by essentially translating some of the fluffos code in the compiler in vm into it.

2
Drivers / Re: new driver development.
« on: January 30, 2018, 09:34:20 PM »
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.

3
Drivers / Re: new driver development.
« on: January 28, 2018, 06:07:27 PM »
Well I am not saying that a noninstrumentation approach does not work but I think instrumentation is quite general and can cope with a multitude of problems if used correctly. The perhaps canonical method for doing this is to find all loop backedges and do some sort of check on each one (perhaps have a counter) and do the same for every function entry. What is __bfc() and __efc()?

4
Drivers / Re: new driver development.
« on: January 15, 2018, 06:41:47 PM »
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?

5
Drivers / Re: new driver development.
« on: January 15, 2018, 05:06:06 AM »
Do you have a link for where I might get the source code for tripwire? I am kind of curious what it's capabilities are.

6
Drivers / Re: Sending large strings through socket efuns
« on: January 11, 2018, 05:43:41 PM »
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.

7
Drivers / Re: Sending large strings through socket efuns
« on: January 10, 2018, 10:09:22 PM »
It seems that the arrays are also all stack allocated as local variables.

8
Drivers / Re: Sending large strings through socket efuns
« on: January 10, 2018, 09:35:49 PM »
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.   

9
Drivers / Re: new driver development.
« on: December 25, 2017, 02:42:48 PM »
Does all the code in the mudlib reside in a single sandbox? I am wondering if there are security measures to prevent coders from tripping on each others toes. I am not familiar with the tripwire module you mentioned do you have a link? I am curious if it prevent's all malicious code where the code takes too many cpu cycles to execute and how it does so.

10
Drivers / Re: new driver development.
« on: December 21, 2017, 06:20:00 AM »
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.

11
Open Chat / Re: Merry Christmas and a happy New Year!
« on: December 21, 2017, 06:08:13 AM »
Merry Christmas to everyone reading this (and Adam as well of course).

12
General / Re: My Renewed Interest in LPMud stuff
« on: December 12, 2017, 06:27:12 PM »
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).

13
Design Lab / Re: Testing in LPC
« on: December 04, 2017, 07:59:03 AM »
I think I could see this being used for mudlib code. For realms and domain code I think it might be a bit harder to teach content coders to do this properly but it's still a good idea. In the past I have noticed that a many content coders simply don't have much of a technical background so they might need quite a bit of help in implementing proper testing. Neat idea though.

14
General / Re: My Renewed Interest in LPMud stuff
« on: December 04, 2017, 07:14:20 AM »
I have been actually interested in writing a lpc -> java transpiler but I suspect I might be able to equally do a lpc -> ecmascript6 one. Lately I have been hanging out on IRC so haven't been on I3 much. I have been learning about lisp compilers, IR representations and optimizations there. I suspect it might take me about a week to make good progress on a transpiler for lpc->java. To javascript might take a bit more time since I am uncertain about the best ways to map to javascript (i.e. instrumentation for security and so on).

15
Intermud / Re: I3 Testing Server
« on: November 28, 2017, 08:03:42 PM »
I think the old intermud-2 protocol had a problem with multiple muds not being consistent on things like what muds were connected to a given channel and what not. I think no one analyzed the protocol to make sure that consistency is guaranteed. Not sure there was ever a specification document or design document of some sort.

Pages: [1] 2 3 ... 13