View Issue Details

IDProjectCategoryView StatusLast Update
0000663LDMud 3.5LPC Languagepublic2015-05-10 18:18
ReporterGnomi Assigned Tozesstra  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformi686OSDebian GNU/LinuxOS Version4.0
Target Version3.5.0Fixed in Version3.5.0 
Summary0000663: RfC: Remove some configuration switches in 3.5.x
DescriptionThe reduce complexity of the code and fragmentation of the language some configuration options should be removed.

USE_ARRAY_CALLS can always be on. The only visible change is, that instead of throwing an error on call_other with arrays it does work.

USE_STRUCTS, too. That makes 'struct' a reserved word. Might break code, that uses 'struct' as a variable or function name.

USE_NEW_INLINES should also be always on. 'function' will become a reserved word and might break code, where it is used a variable or function name. But other than that it should be compatible to older inlines. (It won't throw an error when outer variables are referenced.)
TagsNo tags attached.

Relationships

parent of 0000557 resolvedzesstra Remove conditional compilation of structs and new inlines 
parent of 0000213 closedzesstra Disallow callothers on Arrays [was: Special -> notation for array call-others] 
parent of 0000774 resolvedzesstra Remove configuration switch USE_ARRAY_CALLS 
parent of 0000775 resolvedzesstra Remove add_light() / configuration switch USE_SET_LIGHT 
parent of 0000776 resolvedzesstra RfC: Remove alists permanently 
parent of 0000778 resolvedzesstra Permamently activate new cleanup behaviour: remove NEW_CLEANUP and LOG_NEW_CLEANUP 
parent of 0000779 closedzesstra Permanently activate the modifier 'nosave': remove configuration switch USE_LPC_NOSAVE 

Activities

zesstra

2009-06-18 03:10

administrator   ~0001222

I agree for all three of them.

fufu

2009-06-18 05:13

manager   ~0001226

I disagree with always enabling USE_ARRAY_CALLS (It makes code harder to read; foo->bar() may hide a loop when array calls are enabled. There's also the possibility of passing arrays instead of objects to functions to cause interesting effects. It's also another trap for beginners to fall into. And finally, writing the equivalent map_objects() call is not hard.)

I agree with enabling the other two features by default (unlike array calls, these are features that you have to use consciously - and finding code that contains a new keyword using grep isn't that hard).

zesstra

2009-06-22 05:34

administrator   ~0001228

What about NEW_CLEANUP? I think, we could make that non-optional as well.

Gnomi

2009-06-23 03:17

manager   ~0001229

I agree, that NEW_CLEANUP can be made mandatory. Also LOG_NEW_CLEANUP code can be removed.

Then there are USE_AVL_FREELIST, MALLOC_ORDER_LARGE_FREELISTS and MALLOC_ORDER_SLAB_FREELISTS. Do we have something to measure memory fragmentation, so we can decide, whether they help or not?

zesstra

2009-06-23 15:56

administrator   ~0001232

Just to keep in mind a short discussion with Gnomi about evaluating the fragmentation one simple idea:

Eine einfache Moeglichkeit waere vermutlich, offline (wie GC) den heap komplett zu durchlaufen und dann ein Art Bitmap zu machen. Fuer jedes Wort ein Pixel und dann kennzeichnen, ob belegt (1) oder nicht (0) und dann graphisch darstellen. Das waer dann was fuer Menschen zum Angucken. Etwas in der Art wie hier: http://blog.pavlov.net/2007/11/10/memory-fragmentation/
Ich wuerde vermuten, dass das trotz der Einfachheit einen ernsthafen Hinweis gibt, ob diese Defines irgendeine Aenderung zum besseren bewirken und ob das signifikant genug ist, damit man ueberhaupt was sieht. Allerdings muesste man bei dem Vergleich IMHO immer die gleiche Sequenz von Lade-/Clone-/Destruct-Vorgaengen machen.

(Sorry for the german, I just too lazy right now. It is basically the same approach as described in the link.)

Coogan

2009-09-20 05:36

reporter   ~0001283

I'd also drop USE_LPC_NOSAVE (although an earlier report of mine was the reason for implementing that configuration switch) and make use of 'nosave' mandantory.

Coogan

2009-09-20 05:47

reporter   ~0001284

BTW: When looking at the settings files in a 3.4.x-archive, all muds are using alists. (The exception is the settings file of Traumland -- who is Traumland? Never heard, and even unknown for our inetd.)

From this point of usage, it would be better to change the alists-default to "yes" or, to clean up the code for the case #ifndef USE_ALISTS, and another switch would be gone.

Why should one support an option nobody uses?

(In 3.2.x, there is no such option yet and support of alists mandantory.)

invisible

2009-09-20 07:17

reporter   ~0001285

I can only speak for Beutelland, but we do not use alists although they are enabled. It simply is because we derived our settings-file from Silberland :-)

I guess it's the same for many other MUDs (just like almost every autoconf-script checks for a fortran compiler *g*)

Gnomi

2009-09-20 09:48

manager   ~0001286

Those muds who don't mention alists in their settings file don't use alists (as it is deactivated by default). So Avalon, Beutelland, DT2, Gestrandet, Heaven7, Lethynna, Timewarp and UNItopia don't use them, too. (And speaking for UNItopia: We don't want them back.)

_xtian_

2011-02-14 13:11

reporter   ~0001973

So there seems to be a consensus regarding always enabling:

USE_STRUCTS
USE_NEW_INLINES
USE_LPC_NOSAVE
NEW_CLEANUP
 Also LOG_NEW_CLEANUP code can be removed.

And recent discussions reached the agreement to keep:
USE_ARRAY_CALLS


Also it has been proposed to enable
USE_ALISTS - but, personally, I am surprised that it is still in use and would have proposed to DISable it completely.


Also, read the comment from Gnomi: https://ldmud.eu/mantis/view.php?id=663#c1229 regarding memory-defines.

zesstra

2011-02-14 13:19

administrator   ~0001974

The first 5 mentioned in 0000663:0001973 are settled, I agree.

I suggest to discuss the ones without consensus separately and will create separate entries and link them to this issue (see above). Otherwise, this issue will get even more confusing than it is right now. ;-)

zesstra

2015-05-10 18:18

administrator   ~0002254

I believe, we are finished with this concerning 3.5.0.

Issue History

Date Modified Username Field Change
2009-06-18 03:00 Gnomi New Issue
2009-06-18 03:05 zesstra Relationship added parent of 0000557
2009-06-18 03:10 zesstra Note Added: 0001222
2009-06-18 05:13 fufu Note Added: 0001226
2009-06-22 05:34 zesstra Note Added: 0001228
2009-06-23 03:17 Gnomi Note Added: 0001229
2009-06-23 15:56 zesstra Note Added: 0001232
2009-09-20 05:36 Coogan Note Added: 0001283
2009-09-20 05:47 Coogan Note Added: 0001284
2009-09-20 07:17 invisible Note Added: 0001285
2009-09-20 09:48 Gnomi Note Added: 0001286
2009-11-17 12:36 zesstra Relationship added parent of 0000213
2010-03-27 05:22 zesstra Target Version => 3.5.0
2011-02-13 23:20 zesstra Relationship added parent of 0000774
2011-02-14 12:35 zesstra Relationship added parent of 0000775
2011-02-14 13:11 _xtian_ Note Added: 0001973
2011-02-14 13:19 zesstra Note Added: 0001974
2011-02-14 13:34 zesstra Relationship added parent of 0000776
2011-02-14 14:15 zesstra Relationship added parent of 0000777
2011-02-14 14:17 zesstra Relationship added parent of 0000778
2011-02-14 14:21 zesstra Relationship added parent of 0000779
2015-05-06 18:22 zesstra Relationship deleted parent of 0000777
2015-05-10 18:16 zesstra Assigned To => zesstra
2015-05-10 18:16 zesstra Status new => assigned
2015-05-10 18:17 zesstra Summary RfC: Remove some configuration switches => RfC: Remove some configuration switches in 3.5.x
2015-05-10 18:18 zesstra Note Added: 0002254
2015-05-10 18:18 zesstra Status assigned => resolved
2015-05-10 18:18 zesstra Fixed in Version => 3.5.0
2015-05-10 18:18 zesstra Resolution open => fixed