View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000663 | LDMud 3.5 | LPC Language | public | 2009-06-18 03:00 | 2015-05-10 18:18 |
| Reporter | Gnomi | Assigned To | zesstra | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i686 | OS | Debian GNU/Linux | OS Version | 4.0 |
| Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
| Summary | 0000663: RfC: Remove some configuration switches in 3.5.x | ||||
| Description | The 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.) | ||||
| Tags | No tags attached. | ||||
| parent of | 0000557 | resolved | zesstra | Remove conditional compilation of structs and new inlines |
| parent of | 0000213 | closed | zesstra | Disallow callothers on Arrays [was: Special -> notation for array call-others] |
| parent of | 0000774 | resolved | zesstra | Remove configuration switch USE_ARRAY_CALLS |
| parent of | 0000775 | resolved | zesstra | Remove add_light() / configuration switch USE_SET_LIGHT |
| parent of | 0000776 | resolved | zesstra | RfC: Remove alists permanently |
| parent of | 0000778 | resolved | zesstra | Permamently activate new cleanup behaviour: remove NEW_CLEANUP and LOG_NEW_CLEANUP |
| parent of | 0000779 | closed | zesstra | Permanently activate the modifier 'nosave': remove configuration switch USE_LPC_NOSAVE |
|
|
I agree for all three of them. |
|
|
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). |
|
|
What about NEW_CLEANUP? I think, we could make that non-optional as well. |
|
|
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? |
|
|
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.) |
|
|
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. |
|
|
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.) |
|
|
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*) |
|
|
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.) |
|
|
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. |
|
|
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. ;-) |
|
|
I believe, we are finished with this concerning 3.5.0. |
| 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 |
