View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000295 | LDMud | LPC Compiler/Preprocessor | public | 2004-11-26 23:58 | 2022-10-06 19:31 |
| Reporter | Assigned To | Gnomi | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000295: External modules in LPC | ||||
| Description | Short: External modules in LPC From: Andy <Andreas.Klauer@epost.de> Date: Tue, 4 Jun 2002 20:52:11 +0200 Type: Feature State: New Hi Lars, immer, wenn ich mich langweile, komme ich auf dumme Gedanken. So hat es sich auch gestern zugetragen, bei einer trˆdeligen Bahnfahrt *schnarch*. Wie w‰re es, Fremdkˆrper in LPC integrierbar zu machen. Mit "Fremdkˆrper" meine ich: - Fremdsprachen, z.B. Perl, UDL, ... - Externe Programme, z.B. diff/patch, Tiny Fugue, ... ;-) - Interne Programme, z.B. Pfadfinder :-) - Alles mˆgliche andere sonst auch noch Wie ich mir das ungef‰hr vorstelle: Jeder Fremdkˆrper ist im Grunde ein Modul, das zur Compile-Zeit in den Driver eingebunden wird. (Meinetwegen auch dynamisch, aber das w‰re wohl zu kompliziert). Jedes Modul besitzt einen Grundstock von Funktionen, die vom LPC-Objekt aus direkt oder indirekt aufgerufen werden. (Mehr dazu gleich). Im Moment fallen mir dazu nur zwei Funktionen ein: void modul_embedded(string text, varargs mixed * options) (Indirekter Aufruf) mixed modul_exec(string type, varargs mixed * data) (Direkter Aufruf) Der Driver selbst muss den Modulen ausserdem Service-Funktionen anbieten: - Von welchem Objekt wird das Modul gerade repr‰sentiert? - Aufruf von LFuns (im eigenen und anderen Objekten), SEFuns, EFuns - Zugriff auf lokale & private Variablen & Funktionen des eigenen Objektes - ‹berpr¸fung & Modifikation des Eval-Verbrauchs etc. Desweiteren brauchts noch ein paar Hooks, bzw. Funktionen die im Master aufgerufen werden, damit dort z.B. das Zugriffsrecht auf Fremdkˆrper geregelt werden kann. Dann nat¸rlich muss die generelle Verwendung von Modulen in LPC mˆglich gemacht werden. Wie das aussehen kˆnnte, k.A., ich mache mal ein Beispiel als Pr‰prozessoranweisungen: #use modulname[, modulname2[, ..., modulnameN] (Lars says: inherit "modulname" would be more LPC like) #embed [modulname] #endembed #use Gibt an, welche Module dieses Objekt verwenden mˆchte. Das Objekt repr‰sentiert also ab diesem Zeitpunkt die Module. Bei den Modulen handelt es sich also um so etwas ‰hnliches wie Inherits. Mit der Einbindung der Module stehen dem Objekt die Grundfunktionen zur Verf¸gung, also z.B. modulname_exec. (Oder wenn es einfacher ist, auch modul_exec(name, ...)). Zwischen #embed [modulname] und #endembed kann man Text einbinden, der nicht von LPC / Pr‰prozessor geparsed wird, sondern der Funktion modul_embedded unmodifiziert ¸bergeben wird. (Oder evtl. besser, vom Modul abgefragt werden kann.) Dabei kˆnnte es sich z.B. um Perl-Sourcecode handeln. Der MUD-Wizard kˆnnte dann solchen LPC-Code schreiben: ------ Beispiel 1 ------- // Ein Raum mit der Langbeschreibung "Hello World." #use perl #embed print "Hello World.\n" #endembed inherit "room"; void create() { string str = modul_exec("perl", M_EMBEDDED_ARG); // M_EMBEDDED_ARG ist einfach ein Flag, das dem Modul sagt, dass der embedded text verwendet werden soll set_long(str); } ----- Ende Beispiel 1 ----- ----- Beispiel 2 ----- // Ein diff/patch in LPC :-) #use diff,patch string diff(string file1, string file2, varargs mixed * options) { return apply(#'modul_exec, "diff", file1, file2, options); // Leserechte etc. checkt das Modul selbst. } int patch(string file, string patch, varargs mixed * options) { return apply(#'modul_exec, "patch", file1, patch, options); } ---- Ende Beispiel 2 ---- ---- Beispiel 3 ---- // Ein Pfadfinder. #use pfadfinder string suche_pfad(mixed start, mixed ziel, mixed * real_big_room_info_matrix) { return modul_exec("pfadfinder", start, ziel, real_big_room_info_matrix); } ---- Ende Beispeil 3 ---- Nat¸rlich gibts schon sowas wie ERQ. Im Gegensatz dazu w‰ren solche Module jedoch keine Schnittstellen im herkˆmmlichen Sinn (auch wenn z.B. ein Perl-Modul eine Schnittstelle zu einem externen Perl-Interpreter darstellen kˆnnte). Der Vorteil w‰re, da? eben die Module teil des LPC-Objektes w‰ren; die Module werden also durch LPC-Objekte repr‰sentiert. Als Teil des Drivers kann man den Modulen Daten ¸bergeben, wie jeder anderen LPC-Funktion auch, in Form von Referenzen, komplexen Datentypen etc, was ¸ber den ERQ nicht mˆglich w‰re. Wenn Module andere EFuns aufrufen, sollte die EFun dabei denken, das Objekt selbst h‰tte diese Funktion aufgerufen. Schreibrechte und sonstige MUD-Internas lie?en sich so besser abhandeln als ¸ber die ERQ-Schnittstelle. Man kann damit eine Ecke verr¸cktere Sachen machen als mit ERQ. z.B. ein #use tinyfugue im Player. Immer wird dar¸ber gewitzelt, TinyFugue in LPC zu ¸bersetzen und das den Telnet-Spielern als Client vorzusetzen. Als Fremdkˆrpereinbindung w‰re es relativ einfach zu lˆsen, indem man den Output vom MUD an den Player dem TinyFugue-Modul als Input vorsetzt und den Output vom TinyFugue wiederum an den Player schickt... Zumindest theoretisch. Danke soweit schonmal f¸rs Lesen meiner wirren Gedanken.. *duck-und-unters-sofa-kriech* ;-) Gruss D‰umling Menaures | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
Just a comment to the use of different programming languages inlined into LPC code: I think, this is a nightmare for (ordinary) wizards who know LPC and not the used language. I imagine a wizard responsible for a domain who has to debug such an object and does not know perl (to use that example). And actually: even I don't want to deal with several different languages in one object. A different thing is easier use of external functionality, e.g. DNS resolving, pathfinding by calling specific efuns without knowing anything about the language that external service is coded in. |
|
|
I'd really like to be able to load additional modules into the driver to offer some functionality to LPC programms, mostly in form of additional efuns. As a goal: All of our pkg-* files should be loadable as modules. :-) |
|
|
I agree, but that should IMHO be a different issue, because this deals so much with embedding/inline a different language into LPC code. I suggest to create a bug about loadable modules in 3.5 and close this one... |
|
|
ldmud's Python integration should cover this, right? |
|
|
It covers may idea of offering additional efuns. But the original idea had a lot more suggestions for adding language elements to enable modules for the current file and passing data (code) verbatim to the module. |
|
|
I think the Python integration in current LDMud releases offer much of the desired extensibility. The syntax extension however is something I don't agree with as it looks very foreign to LPC. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 23:58 |
|
New Issue | |
| 2009-09-27 14:50 | zesstra | Note Added: 0001316 | |
| 2009-09-29 11:18 | Gnomi | Note Added: 0001339 | |
| 2009-09-30 14:53 | zesstra | Note Added: 0001366 | |
| 2021-04-15 17:29 | fufu | Note Added: 0002586 | |
| 2021-04-15 17:52 | Gnomi | Note Added: 0002588 | |
| 2022-10-06 19:31 | Gnomi | Assigned To | => Gnomi |
| 2022-10-06 19:31 | Gnomi | Status | new => closed |
| 2022-10-06 19:31 | Gnomi | Resolution | open => won't fix |
| 2022-10-06 19:31 | Gnomi | Note Added: 0002692 |
