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.

Topics - silenus

Pages: [1] 2 3
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?

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 / 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 / Contributions to the driver
« on: October 18, 2015, 06:33:40 PM »
I have been thinking about experimenting with some driver hacking are contributions being accepted into the driver?

Drivers / Difficulties compiling 2.27 under OS X
« on: October 21, 2014, 11:19:18 AM »
I am having some difficulties getting fluffos to compile under OS X 10.10 Yosemite. There is a type error in the interpret.c code with LPC_INT and long being type incompatible and also a problem with posix timers since OS X doesnt have these (there is a problem with time_h not being defined out in the posix_timers.c). The last hurdle I have encountered is that libiconv isnt linking properly. Is there an older version of comm.c that lacks the fliconv hooks? Will the code work if I strip out the translate and get_translator calls?

Thanks in advance,

P.S. unfortunately my linux laptop died on me so I am not forced to use the mac for compiling fluff.

Drivers / smart pointers as a change to the driver for refcounting
« on: October 02, 2014, 11:36:13 AM »
Would it make sense to replace perhaps as a stop gap measure until garbage collection goes in all pointers array_t, object_t etc. with ref counting smart pointers and then removing the free_* calls from the driver. It would seem to me that this would simplify maintenance.

Drivers / custom memory allocators and macros versus C++
« on: September 20, 2014, 12:56:36 PM »
This might be a bit of a beginners question concerning the implementation of the fluffos driver. But I was looking at some of the code recently and I was somewhat curious what the benefits are of having multiple memory allocation macros in the code are. It would seem to me that the system defaults mainly to sysmalloc these days. Do the  two newer 32 and 64 bit mallocs see much use? and how about the older brk() dependent smalloc? What are the advantages of these nowadays?

It would be nice not to worry if a stl container needs a custom allocator to place nice with the current allocators even if after testing one decides to plug one in to make it compatible with the different variants. Has anyone considered writing a simple mark and sweep garbage collector to replace the ref counting stuff?

Drivers / Current Fluffos licence
« on: January 20, 2014, 11:10:02 AM »
Hi I am curious about the current state of fluffos and which files are licensed under what kind of restrictions etc. I am thinking of rewriting portions with some new code (wondering how best to licence the new code).

Drivers / Optimizing LPC for JIT use
« on: January 10, 2014, 09:16:57 AM »
I am curious to what extent people feel it may or may not be possible to optimize LPC for JIT use. The main issues I see are that any return value from a call other is of mixed type making it difficult to infer types without some sort of caching strategy and perhaps constant program inference of an interprocedural nature. This is probably nontrivial to do even for an existing LPC driver such as dgd or fluffos and may involve replacing the virtual machine or many opcodes with typed versions rather than relying on dynamic type field identification at runtime.

Drivers / standard malloc and brk in smalloc.c
« on: May 13, 2013, 06:30:06 AM »
I have been wondering if the sbrk brk calls are used anywhere other than in smalloc.c. I have been wondering how problematic it would be to have the custom allocators replaced by the default standard library one.



Drivers / memory management fluffos
« on: September 01, 2009, 01:44:01 AM »
I have been playing around with the memory management routines in FluffOS and was looking for some general advice on how to go about perhaps removing certain block allocation behavior in the current system among other things. Testing with DeadSouls 2.10 I noticed that the system tends to like allocating data on my build in chunks of 200k-400k which is something i would like to avoid.

1) I am curious which subsystem (I am having difficulties tracing it in gdb) may be responsible for these block allocations (if anyone knows).

2) Also I am curious about the stralloc.c subsystem. I am thinking of replacing this as part of an experiment (with cords) but I am somewhat uncertain about how to test to see my changes aren't causing crashes. The problem is the cord library has specific instructions for handling concat, substr etc whereas stralloc.c returns char*. Is my best bet here to use a custom C++ ADT to wrap the interface in question and thus trap through the type system all the cstring type stuff including indexing via [].

Thanks in advance.

Drivers / Closures
« on: July 03, 2009, 02:18:16 AM »
I am currently thinking through anon function support for the driver I am working on. It's probably not as far along as the Terebi driver which Zod seems to be doing a good job with but progress in general has been good. I am debating currently about how best to implement anonymous functions and whether or not they should be allowed to access stack variables in the enclosing static scopes. I know ldmud support these but currently but fluffos does not. Is it a useful feature? I suspect it's significantly more work to implement since you need to have your semantic analysis determine which variables "escape" and require their stack frames(or elements of) to be places on the heap.

Drivers / class/structs and LPC
« on: March 17, 2009, 02:16:19 AM »

I have been trying to understand the class construct and it's exact role in LPC and the potential complications it causes and possible resolutions. My understanding is that the implementation of the class construct varies depending on the dialect of LPC and in some cases does not exist (dgd). LDmud implementation for example differs from FluffOS in that at the very least definitions are inherited from parents.

The fundamental problematic aspect of this type is that it's a name type where both the type information and structural information is erased after compilation with fluffos(i.e. it's converted into a mixed array). This results in some pretty nasty cast requirements and structural equivalence issues when dealing with call other while simple name equivalence is instead used when the definitions are compared within the same object. The situation is quite messy and perhaps why dgd decided not to include this user defined type mechanism into the dgd LPC variant.

For the driver I am working(if it ever sees the light of day) on I am quite tempted to drop this type for these reasons unless the problem or introducing type definitions can be resolved in some clean manner with name based semantics being preferred i.e. class A { int x } != class B { int x } even though they have the same structure. I suspect this problem cannot be resolved really without having some sort of "global" namespace where the user defined types can reside. Once you have multiple namespaces you will always run into some sort of problem. The difficulty here is LPC has no real global namespace for types. One idea maybe to extend the naming convention for programs based on the file name so that you can do stuff like filename%type1? to refer to a class outside it's original scope? The current solution in fluffos seems somewhat unacceptable IMHO(though maybe ppl have gotten use to it).

Design Lab / LPC++ toy
« on: March 02, 2009, 08:15:18 PM »
I have been thinking about changes to the basic LPC language for the new driver (relaunched?) project I have been working on and was curious about getting some input. I am currently working on the  type-checking and translation phases of the project so before things are more set in stone.... The main difference in the system would be a more extensive type system which supports a number of new types. The syntax for how all this would work is still up for grabs. The basic idea is to extend the type system to support records(read anonymous structs) and tuples (ala python) as well as simple recursive types as well as typing function variables + introducing pattern matching.

The price of all this is perhaps some new syntax and removal of certain features from current LPC to accomodate them. My suggested changes are as follows-

1) removal of the comma operator to accommodate tuples. (1,"string",4) would be a tuple return and could be used to return/assign multiple values.
2) abbreviate "({" to "[" and "([" to "{". According to my grammar thus far this change doesn't seem to create an ambiguity.
3) change declarations as follows [int] for arrays {int} for mappings introduce (int,string,int) for tuples and (label1: int, label2 : string) for records.
4) a function type (int,int) -> string for example
5) all for disjoint unions of types like in pike via string | int | float x; etc.
6) include a new labelling mechanism for types i.e. def x = type- allowing for old style classes and new style recursive types

now some of these changes are just a matter of taste. So obviously they can be reverted to a form which may be more LPC like. I.e. 2) can be backed out (obviously) and 3) & 4) might be possible to modify to make it more C like. i.e. use pike style array(int) and mapping(string,int) for example with functions being maybe string fun(int,int) f; though that might be difficult to parse.

Any comments would be appreciated.


Pages: [1] 2 3