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 ... 14
1
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 21, 2019, 07:50:47 pm »
TBH I am not sure how far I will take the FluffOS code atm. A JIT would be nice but as there are no new mud developers and the community is somewhat dwindling it might simply not be worth the effort for me. I added to the issues just in case I decided to do it. There are some simple things I am trying to do with FluffOS such as upgrading the system to use C++ fully and get rid of the global variables which are more just edit changes to the code. The VM in FluffOS has a lot more opcodes than the one in DGD so doing anything with it involves a fair deal of tedious case by case coding with a lot of cases.

2
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 21, 2019, 06:39:52 am »
I think the added processing power gained by JIT would probably open up new applications or make it possible to revisit the design decisions made in old style muds. Obviously there is little interest in such things now. A* path finding is one thing that did run slowly on muds servers about a decade ago. 

3
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 21, 2019, 12:25:26 am »
I remember from a long time ago now we talked about Hamlet's plans to introduce STM into FluffOS(which he later abandoned). I would assume the final implementation of Hydra is somewhat similar using commit and rollbacks for threads of execution inside the driver. I think Hamlet gave up because it would take a fair deal of work to get all the global variables to play nice with his ideas for the software transactional memory implementation. STM hasn't really caught on yet as a programming model (perhaps given limitations in scalability beyond 8/16 independent threads). I figure if someone could address some of these issues with new ideas perhaps it would gain more traction. 

4
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 10, 2019, 05:27:34 am »
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.

5
Drivers / Re: New fluffos repo containing the 2.28 version.
« on: September 10, 2019, 05:22:42 am »
This repository has been moved to-

https://github.com/silenus-dionysus/fluffos-2.x

I am in the process of some minor clean up and converting the code over to C++. There are other things in the issues section pertaining to future plans.

6
Drivers / New fluffos repo containing the 2.28 version.
« on: May 21, 2019, 06:24:26 am »
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.


7
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.

8
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.

9
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()?

10
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?

11
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.

12
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.

13
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.

14
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.   

15
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.

Pages: [1] 2 3 ... 14