View Issue Details

IDProjectCategoryView StatusLast Update
0000637LDMud 3.5Efunspublic2009-06-03 18:06
Reporterzesstra Assigned Tozesstra  
Status resolvedResolutionfixed 
Target Version3.5.0Fixed in Version3.5.0 
Summary0000637: RfC: Remove the efun cat()
DescriptionIn the discussion about 0000636 on -d-code, there was a suggestion to remove the efun cat(). cat() is nearly the same as read_file()+tell_object() - the biggest difference being that cat() does not read in the whole file.
Please comment on this idea.
TagsNo tags attached.


related to 0000636 closedzesstra LDMud 3.3 Wrong *****TRUNCATED**** message and fixed MAX_LINES in cat() 
related to 0000228 resolvedzesstra LDMud 3.5 Remove efun tail() (was: cat(), tail() should take limits) 



2009-05-19 04:31

administrator   ~0001116

Ah, BTW: For a removal I would suggest the following strategy: deprecate the efun now in 3.3.x and remove it in 3.5.1, because I don't like to remove it from one minor release to the other. I had a quick look in our mudlib and it is used about 110 times, so we have to introduce a sefun as replacement in MG.

I guess, it is a good idea to start our reference simul_efun.c which contains suggestions for sefuns emulating removed efuns (I think, we discussed the in some other bug shortly).


2009-05-19 04:33

manager   ~0001117

I agree.


2009-05-22 04:00

reporter   ~0001132

I once thought cat() could be the superhighway for files on the disk to be copied to a socket bypassing the main LPC memory.. like throwing an mp3, an xvid, an flv or mp4 directly at an httpd or socket of other protocol.


2009-05-22 06:19

administrator   ~0001138

Mhm, that would be a different semantic compared to the current one. You could think of mmapping a file to some memory page(s), directly use that as buffer and transfer it. Possible, and reportedly faster then lseek()+read(). Using sendfile() may be another approach, but I don't know, if sendfile() is POSIX and widely supported. But in both cases, it is very different to the current cat(), which transfers a range of lines, not the complete file or a range of bytes.
So probably it would be better to use a differently named efun() (e.g. sendfile()) for this.
How often do you transfer (large) files directly without any pre-processing?


2009-05-22 07:01

reporter   ~0001140

We do have situations where swfs, applets, javascripts and graphics need to come from the same host as the http application, and I increasingly like to implement web applications on top of psyced because of its decentralized multi-user awareness.

But if ldmud/psyced were a rock solid httpd, I would probably kick out Apache, migrate all websites... saving one IP address and simplifying my general web technology configuration. I have some DJ mixes for download etc, so files can enter the hundreds of megs range.

Then again, I might be a borderline case.

Other thoughts go into direction of doing file sharing or pubsub apps using the userbase.. throwing MP3s at PSYC sockets in order to have them distributed to all subscribers in realtime.. sendfile(2) allows for using incoming TCP sockets instead of files as the source, which is interesting, too.

So I guess you are right, cat() is a candidate for simul_efun. sendfile() or something like it is the thing.


2009-05-22 07:05

reporter   ~0001141

Last edited: 2009-05-22 07:05

Heheh .. wait... the LPC tradition is to have implicit sockets tied to objects.. therefore, sendfile(inobject, outobject...) is too much like socket libs.

cat() already uses the implicit output socket being this_interactive(), now if the source can be an interactive object instead of string - poof, you are copying data from that interactive's socket to this interactive's socket without even changing the lpc API much.


2009-05-22 07:14

administrator   ~0001142

You are certainly a borderline case. ;-) At least compared to all muds, which don't really transfer large files as raw data. And additionally, I think some sendfile() on the telnet socket will break something. ;-) So, it is something which can only be used on other (TCP) sockets.
I guess, if somebody wants to work on it, I don't object, by I personally would probably do other things first. I looked up sendfile() and found out, that it is not standardized in any way and its use in portable programs is discouraged. That suggests using mmap() to me for implementing sendfile().


2009-05-22 07:23

administrator   ~0001143

You are changing the _semantics_ and the API of cat() significantly. cat() counts _lines_ in textfiles (which don't really exist in random files) and transfers the desired range of lines.
What you suggest can not attempt to count lines if its purpose is to efficiently transfer (large) binary files, you can either transfer a complete file or a range [byte_x...byte_y].
And using an object as source for cat() instead of a string describing the location of a file is also a major change in API, although that can be alleviated a bit by using 'mixed'.
And then cat has to raise a privilege violation, because you can't allow random objects to copy raw data from the socket of one interactive to the socket of another interactive.


2009-05-22 07:37

reporter   ~0001144

Uh oh.. always neglecting some details like the *lines* feature of cat() which would require some #define CAT_USE_BYTES flag to make sense for binary files.

Ok, let's send the cat() to simul-efun-wonderland and think of sendfile() elsewhere...


2009-05-23 18:07

manager   ~0001148

I'm for removing cat() as well. Here's a possible sefun replacement (depending on the mudlib it may require some efun:: prefixes):

#define CAT_MAX_LINES 50

varargs int cat(string file, int start, int num)
    if (extern_call())

    int more;

    if (num < 0)
        return 0;

    if (!start || !this_player())
        start = 1;

    if (!num || num > CAT_MAX_LINES) {
        num = CAT_MAX_LINES;
        more = strlen(read_file(file, start+num, 1));

    string txt = read_file(file, start, num);
    if (!txt)
        return 0;

    tell_object(this_player(), txt);

    if (more)
        tell_object(this_player(), "*****TRUNCATED****\n");

    return strlen(txt & "\n");

Where do we want to put compatibility sefuns? How about ${TOP}/mudlib/deprecated/cat.c for this one?


2009-05-23 18:08

manager   ~0001149

Sorry, the ' || !this_player()' condition belongs to the previous if. (It was an afterthought, and I pasted it to the wrong location.)


2009-05-25 09:59

administrator   ~0001152

Ok, then it is decided. I will take care of this soon.
${TOP}/mudlib/deprecated/ sounds good to me. Additionally, we might include a ${TOP}/mudlib/deprecated/simul_efun.c which #includes all the single files (each coding one removed efun as sefun) in that directory.


2009-05-26 07:53

administrator   ~0001161

efun marked as deprecated in r2593.
I move this bug to 3.5 and set the target version to 3.5.1 for removal. I will add the sefun Fuchur suggested later today or tomorrow.


2009-06-03 18:06

administrator   ~0001192

cat() was removed in r2627.

Issue History

Date Modified Username Field Change
2009-05-18 14:16 zesstra New Issue
2009-05-18 14:16 zesstra Status new => assigned
2009-05-18 14:16 zesstra Assigned To => zesstra
2009-05-18 14:16 zesstra Status assigned => feedback
2009-05-19 04:31 zesstra Note Added: 0001116
2009-05-19 04:33 Gnomi Note Added: 0001117
2009-05-22 04:00 lynx Note Added: 0001132
2009-05-22 06:19 zesstra Note Added: 0001138
2009-05-22 07:01 lynx Note Added: 0001140
2009-05-22 07:05 lynx Note Added: 0001141
2009-05-22 07:05 lynx Note Edited: 0001141
2009-05-22 07:14 zesstra Note Added: 0001142
2009-05-22 07:23 zesstra Note Added: 0001143
2009-05-22 07:37 lynx Note Added: 0001144
2009-05-23 18:07 fufu Note Added: 0001148
2009-05-23 18:08 fufu Note Added: 0001149
2009-05-25 09:54 zesstra Relationship added related to 0000636
2009-05-25 09:59 zesstra Note Added: 0001152
2009-05-25 09:59 zesstra Status feedback => assigned
2009-05-26 07:53 zesstra Note Added: 0001161
2009-05-26 07:53 zesstra Project LDMud 3.3 => LDMud 3.5
2009-05-26 07:54 zesstra Product Version 3.3.718 =>
2009-05-26 07:54 zesstra Target Version 3.3.719 => 3.5.0
2009-06-03 18:06 zesstra Note Added: 0001192
2009-06-03 18:06 zesstra Status assigned => resolved
2009-06-03 18:06 zesstra Fixed in Version => 3.5.0
2009-06-03 18:06 zesstra Resolution open => fixed
2009-09-30 15:56 zesstra Relationship added related to 0000228