View Issue Details

IDProjectCategoryView StatusLast Update
0000233LDMud 3.5Implementationpublic2018-01-30 03:59
ReporterlarsAssigned ToGnomi  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Fixed in Version3.5.0 
Summary0000233: Programs, Blueprints, Virtual Inheritance
DescriptionShort: 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.
TagsNo tags attached.

Relationships

related to 0000061 new 'use' directive to replace most uses of prototypes. 

Activities

Gnomi

2008-07-17 06:33

manager   ~0000745

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.

Sorcerer

2008-07-17 11:03

updater   ~0000746

I agree with Gnomi that virtual inherits should always be merged. Virutal inherits probably cause more errors the way they are now.

zesstra

2011-02-14 16:35

administrator   ~0001985

Last edited: 2011-02-14 16:36

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.

Gnomi

2014-02-10 23:53

manager   ~0002218

Last edited: 2014-02-11 00:03

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.

Gnomi

2014-02-11 08:21

manager   ~0002219

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.

zesstra

2018-01-28 21:31

administrator   ~0002297

Fix committed in revision e380a9b4f62161bfbc45fc8cce027a7bc481a0a4 to master branch (see changeset 1184 for details). Thank you for reporting!

Gnomi

2018-01-29 18:59

manager   ~0002304

Fix committed in revision e380a9b4f62161bfbc45fc8cce027a7bc481a0a4 to master branch (see changeset 1248 for details). Thank you for reporting!

Gnomi

2018-01-29 21:57

manager   ~0002355

Fix committed in revision e380a9b4f62161bfbc45fc8cce027a7bc481a0a4 to master branch (see changeset 2572 for details). Thank you for reporting!

Gnomi

2018-01-30 03:59

manager   ~0002406

Fix committed in revision e380a9b4f62161bfbc45fc8cce027a7bc481a0a4 to master branch (see changeset 2465 for details). Thank you for reporting!

Issue History

Date Modified Username Field Change
2004-11-26 22:39 lars New Issue
2008-07-17 06:33 Gnomi Note Added: 0000745
2008-07-17 06:34 Gnomi Project LDMud => LDMud 3.5
2008-07-17 11:03 Sorcerer Note Added: 0000746
2009-10-02 03:02 zesstra Relationship added related to 0000061
2011-02-14 16:35 zesstra Note Added: 0001985
2011-02-14 16:36 zesstra Note Edited: 0001985
2014-02-10 15:17 Gnomi Assigned To => Gnomi
2014-02-10 15:17 Gnomi Status new => assigned
2014-02-10 23:53 Gnomi Note Added: 0002218
2014-02-11 00:03 Gnomi Note Edited: 0002218
2014-02-11 08:21 Gnomi Note Added: 0002219
2017-09-30 16:08 Gnomi Status assigned => resolved
2017-09-30 16:08 Gnomi Resolution open => fixed
2017-09-30 16:08 Gnomi Fixed in Version => 3.5.0
2018-01-28 21:31 Source_changeset_attached => ldmud.git master af6e88cc
2018-01-28 21:31 Source_changeset_attached => ldmud.git master e380a9b4
2018-01-28 21:31 Source_changeset_attached => ldmud.git master 86cda0b6
2018-01-28 21:31 zesstra Note Added: 0002297
2018-01-29 18:59 Gnomi Source_changeset_attached => ldmud.git master af6e88cc
2018-01-29 18:59 Gnomi Source_changeset_attached => ldmud.git master e380a9b4
2018-01-29 18:59 Gnomi Source_changeset_attached => ldmud.git master 86cda0b6
2018-01-29 18:59 Gnomi Note Added: 0002304
2018-01-29 21:57 Gnomi Source_changeset_attached => ldmud.git master af6e88cc
2018-01-29 21:57 Gnomi Source_changeset_attached => ldmud.git master e380a9b4
2018-01-29 21:57 Gnomi Source_changeset_attached => ldmud.git master 86cda0b6
2018-01-29 21:57 Gnomi Note Added: 0002355
2018-01-30 03:59 Gnomi Source_changeset_attached => ldmud.git master af6e88cc
2018-01-30 03:59 Gnomi Source_changeset_attached => ldmud.git master e380a9b4
2018-01-30 03:59 Gnomi Source_changeset_attached => ldmud.git master 86cda0b6
2018-01-30 03:59 Gnomi Note Added: 0002406