View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000233 | LDMud 3.5 | Implementation | public | 2004-11-26 23:39 | 2018-01-30 04:59 |
| Reporter | Assigned To | Gnomi | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.5.0 | ||||
| Summary | 0000233: Programs, Blueprints, Virtual Inheritance | ||||
| Description | Short: Separate Programs from Blueprints Date: Thu, 2 Nov 2000 10:12:23 +0100 (MET) From: Fini Jastrow <mud@hurrikap.rz.uni-leipzig.de> --- A way to prevent this scenario would be to keep a list of all programs. But that would mean that blueprints and programs are no longer identical. Hallo Mateese! Nein, ich bin noch nichtmal dazu gekommen auch nur in den Regexp-Code zu schauen. Zum Thema: Wenn eine nomask Funktion mehrfach virtuell ererbt wird, wirft das ja (seit neuem) keinen Fehler mehr. Das klappt auch ganz wunderbar. Ein Problem entsteht nur, wenn die Vererbung nicht ganz direkt ist, und diese nomask Funktion 'in der Zwischenzeit' neu geladen wurde - also im Driver auf eine andere Funktion zeigt, obwohl der 'vollspezifizierte' Name derselbe ist. Beispiel: 'Normalzustand' 'Fehlerzustand' A A / \ / \ / \ / \ B C B C \ / | | \ / | | D D1 D2 Den Fehlerzustand kann man zB erreichen durch: C laden (laed D implizit), D zerstoeren, B laden (laed D implizit). Nun gibt es zwei eigentlich gleiche Funktionen, die aber verschiedenen Funktionszeiger haben: in C nomask D::fun() --- aber eigentlich nomask D2:fun() in B nomask D::fun() --- aber eigentlich nomask D1:fun() Auf jeden Fall wirft es dann 'ploetzlich' irgenwann im Betrieb einen Fehler (nomask zweimal inheritet). Ich weiss nicht, ob man das so aendern kann, dass es trotzdem geht, ansonsten sollte das in der Docu erwaehnt werden denke ich - und eigentlich ist die Faehigkeit dann mehr oder weniger sinnlos, weil nicht wirklich sicher benutzbar. Hmm, was mir gerade einfaellt... ich weiss gar nicht, ob 'virtual' ueberhaupt in diesem Zustand geht, also ob D1 und D2 nur einen Variablenraum, haben. Ich werde das gleich mal nachsehen (wenn ich Zeit finde), wenn du willst schicke ich dir die Ergebnisse, sonst will ich dich nicht mit einer weiteren Mail stoeren. | ||||
| Tags | No tags attached. | ||||
| related to | 0000061 | new | 'use' directive to replace most uses of prototypes. |
|
|
This is a problem in UNItopia as well. Currently the variable sets of two virtual inherited programs of the same name are merged to one iff these programs are equal (i.e. have the same address in memory). I'd rather compare their signature (the names and types of all public and protected functions, variables and structs). For this to work virtual inherited functions should be called using the current object's program's inherit list (instead of the current program's inherit list), where the compiler should have prepared a translation between function indices. On a second thought in most of our virtual inheritances the virtual is mandatory, meaning that something will break if these programs are not merged. So why not always merge them and risk some dangling functions calls? Anyway this is to experimental for 3.3, so I move it to 3.5. |
|
|
I agree with Gnomi that virtual inherits should always be merged. Virutal inherits probably cause more errors the way they are now. |
|
|
You are probably right, although the merge dependent of the signature looks nice. On the other hand it would be at least good to know if a merge was 'risky', because the programs might not have been identical so you could think if reloading the inhertitance tree is needed instead. |
|
|
My plan is the following: Always merge virtual inherited programs that have the same name. If they not only have the same name but are the same program then everything works as it does today. If not then choose the newer program. The older program is replaced with a trampoline entry in the inherit list. For functions this might be done (hopefully) pretty easily by cross-defining their entries in the function table to the new inherit. For variables there need to be a translation table that maps each variable index of the old inherit to an index in the new inherit. If a function in the old inherit is missing in the new inherit replace it by an undefined entry (so it gives the error message "Undefined function" when called). This is the most incompatible change of this proposal, but I think this behavior is more tolerable then nomask errors when merging fails. If a variable in the old inherit is missing in the new inherit add it as a regular inherited virtual variable. Both (function cross-definition and variable index mapping) is done by comparing the name for publicly visible definitions (i.e. declared public or protected). Private functions or variables are ignored as they have no impact on the inheriting program. The trampoline entry shall not have a counted reference to the old program (the old program itself is not needed anymore, so we would like to free its memory), therefore we remember only the program's id number to recognize it when it's inherited again. |
|
|
If a function in the old inherit is missing or has an incompatible signature, or a variable has an incompatible type then the compiler should issue a warning. |
|
|
Fix committed in revision e380a9b4f62161bfbc45fc8cce027a7bc481a0a4 to master branch (see changeset 1184 for details). Thank you for reporting! |
|
|
Fix committed in revision e380a9b4f62161bfbc45fc8cce027a7bc481a0a4 to master branch (see changeset 1248 for details). Thank you for reporting! |
|
|
Fix committed in revision e380a9b4f62161bfbc45fc8cce027a7bc481a0a4 to master branch (see changeset 2572 for details). Thank you for reporting! |
|
|
Fix committed in revision e380a9b4f62161bfbc45fc8cce027a7bc481a0a4 to master branch (see changeset 2465 for details). Thank you for reporting! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 23:39 |
|
New Issue | |
| 2008-07-17 08:33 | Gnomi | Note Added: 0000745 | |
| 2008-07-17 08:34 | Gnomi | Project | LDMud => LDMud 3.5 |
| 2008-07-17 13:03 | Sorcerer | Note Added: 0000746 | |
| 2009-10-02 05:02 | zesstra | Relationship added | related to 0000061 |
| 2011-02-14 17:35 | zesstra | Note Added: 0001985 | |
| 2011-02-14 17:36 | zesstra | Note Edited: 0001985 | |
| 2014-02-10 16:17 | Gnomi | Assigned To | => Gnomi |
| 2014-02-10 16:17 | Gnomi | Status | new => assigned |
| 2014-02-11 00:53 | Gnomi | Note Added: 0002218 | |
| 2014-02-11 01:03 | Gnomi | Note Edited: 0002218 | |
| 2014-02-11 09:21 | Gnomi | Note Added: 0002219 | |
| 2017-09-30 18:08 | Gnomi | Status | assigned => resolved |
| 2017-09-30 18:08 | Gnomi | Resolution | open => fixed |
| 2017-09-30 18:08 | Gnomi | Fixed in Version | => 3.5.0 |
| 2018-01-28 22:31 | Source_changeset_attached | => ldmud.git master af6e88cc | |
| 2018-01-28 22:31 | Source_changeset_attached | => ldmud.git master e380a9b4 | |
| 2018-01-28 22:31 | Source_changeset_attached | => ldmud.git master 86cda0b6 | |
| 2018-01-28 22:31 | zesstra | Note Added: 0002297 | |
| 2018-01-29 19:59 | Gnomi | Source_changeset_attached | => ldmud.git master af6e88cc |
| 2018-01-29 19:59 | Gnomi | Source_changeset_attached | => ldmud.git master e380a9b4 |
| 2018-01-29 19:59 | Gnomi | Source_changeset_attached | => ldmud.git master 86cda0b6 |
| 2018-01-29 19:59 | Gnomi | Note Added: 0002304 | |
| 2018-01-29 22:57 | Gnomi | Source_changeset_attached | => ldmud.git master af6e88cc |
| 2018-01-29 22:57 | Gnomi | Source_changeset_attached | => ldmud.git master e380a9b4 |
| 2018-01-29 22:57 | Gnomi | Source_changeset_attached | => ldmud.git master 86cda0b6 |
| 2018-01-29 22:57 | Gnomi | Note Added: 0002355 | |
| 2018-01-30 04:59 | Gnomi | Source_changeset_attached | => ldmud.git master af6e88cc |
| 2018-01-30 04:59 | Gnomi | Source_changeset_attached | => ldmud.git master e380a9b4 |
| 2018-01-30 04:59 | Gnomi | Source_changeset_attached | => ldmud.git master 86cda0b6 |
| 2018-01-30 04:59 | Gnomi | Note Added: 0002406 |
