I think, like many others, that there are too complex macros in Pike and that it's a big problem for code readibility.
I guess you're talking of things like the block_alloc system, fsort.h, the volymous macros for doing string stuff once for each string width, and the undisputed king of the hill: The interpret_functions.h macro system. Things like THREADS_DISALLOW is just an ordinary macro and can hardly be considered a readability problem.
I know what you mean; I got fairly frustrated too the first time I tried to grep through the source for the definition of get_marker and couldn't find it anywhere. Still, once you've groked how it works it's damn handy.
Some of the string processing stuff could probably have been written without macros and instead accept the performance hit, and it got to be possible to clean up the interpret_functions.h stuff somehow. Using macros to at compile time choose between a heap of separate functions and a giant case is a bit over the edge imho; trusting function inlining just a little would have made it a lot simpler.
But apart from that, you have to consider what the alternatives would be before dissing it (which doesn't imply that I think every single remaining macro is altogether nice and tidy, though). For e.g. block_alloc and fsort, I can only think of C++ templates as being able to improve it in any way.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-05-18 12:39: Subject: Re: Nettle cmod segfault
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
As we are speaking of that, wouldn't it be possible to make this macros with a little less code in it (and generally in macros used in Pike)?
Possible - yes. A good idea - probably not. I've looked at many of the macros and usually think they make sense, at least when rtldebug and dmalloc isn't enabled. For the most part, they get overly bloated only when debug is enabled; it's not uncommon that the debug parts are a bit sloppy and don't bother to isolate some overly long debug checks into functions.
I think, like many others, that there are too complex macros in Pike and that it's a big problem for code readibility.
Anyway about the debug, I compiled with rtldebug but Pike doesn't seem to care much about it, at least I have the same output during the segfault. I uncomment VERBOSE_THREADS_DEBUG in pike_threadlib.h thought. Here is the result:
(Isn't the problem is that THREADS_DISALLOW is called 2 times without THREADS_ALLOW in between backend.cmod and hash.cmod ?)
THREADS_ALLOW() /home/david/Pike/7.6/src/backend.cmod:2333 t:08383000(#0) THREADS_DISALLOW() /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 t: 08ded800(#0) KEY k:0xa043d80, o:0x8bf3000 LOCK k:0xa043d80, m:0x8c07ad0(0x8c07ad0), t:0x8bf3000 KEY k:0xa043dc0, o:0x8bf3000 LOCK k:0xa043dc0, m:0x8c07a70(0x8c07a70), t:0x8bf3000 UNLOCK k:0xa043dc0 m:(0x8c07a70) t:0x8bf3000 o:0x8bf3000 THREADS_ALLOW() /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:136 t:08d ed800(#0) THREADS_DISALLOW() /home/david/Pike/7.6/src/backend.cmod:2340 t:08383000(#0) THREADS_DISALLOW() /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 t: 08ded800(#0) /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138: Fatal error:
Program received signal SIGSEGV, Segmentation fault. 0x2861755a in f_HashState_update (args=1) at /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 138 THREADS_DISALLOW(); #0 0x2861755a in f_HashState_update (args=1) at /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 #1 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db1688, arg2=0x3) at /home/david/Pike/7.6/src/apply_low.h:214 #2 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=1) at /home/david/Pike/7.6/src/interpret_functions.h:1958 #3 0x856b339 in ?? () #4 0x8070f3e in eval_instruction ( pc=0x856b138 "¡0\207.\b\203@\034\024ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:1229 #5 0x808ac41 in o_catch (pc=0x856b138 "¡0\207.\b\203@\034\024ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:2027 #6 0x807c1f8 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #7 0x856b132 in ?? () #8 0x8070f3e in eval_instruction ( pc=0x90d1328 "¡0\207.\b\203@\034\024ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:1229 #9 0x808ac41 in o_catch (pc=0x90d1328 "¡0\207.\b\203@\034\024ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:2027 #10 0x807c1f8 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #11 0x90d1322 in ?? () ---Type <return> to continue, or q <return> to quit--- #12 0x8070f3e in eval_instruction (pc=0x9571fd8 "ÇD$\004\005") at /home/david/Pike/7.6/src/interpret.c:1229 #13 0x808ac41 in o_catch (pc=0x9571fd8 "ÇD$\004\005") at /home/david/Pike/7.6/src/interpret.c:2027 #14 0x807c1f8 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #15 0x9571fd2 in ?? () #16 0x8070f3e in eval_instruction ( pc=0x956dbc6 "\213\r0\207.\b¸:$©ö÷Ø\211A\034ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:1229 #17 0x808ab04 in mega_apply (type=APPLY_STACK, args=8, arg1=0x0, arg2=0x0) at /home/david/Pike/7.6/src/interpret.c:1982 #18 0x808ad50 in f_call_function (args=8) at /home/david/Pike/7.6/src/interpret.c:2053 #19 0x285f890d in container_callback (this=0xa005d00, thisobj=0x8db2cd8, v=0x98b4360, startc=0x8b0e588, cstartc=2006, endc=0x8b0e588, cendc=3885, st=0x852efb0, cutstart=0x852efbc, ccutstart=0x852efc0, cutend=0x8b0e588, ccutend=3892) at /home/david/Pike/7.6/src/modules/Parser/html.c:2735 #20 0x285fabe0 in do_try_feed (this=0xa005d00, thisobj=0x8db2cd8, st=0x852efb0, feed=0x852efbc, finished=1, ignore_tag_cb=0) at /home/david/Pike/7.6/src/modules/Parser/html.c:3224 #21 0x285fc942 in try_feed (finished=1) at /home/david/Pike/7.6/src/modules/Parser/html.c:3737 ---Type <return> to continue, or q <return> to quit--- #22 0x285fd3de in html_finish (args=1) at /home/david/Pike/7.6/src/modules/Parser/html.c:3932 #23 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db2cd8, arg2=0xc) at /home/david/Pike/7.6/src/apply_low.h:214 #24 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=55) at /home/david/Pike/7.6/src/interpret_functions.h:1958 #25 0x9571a8b in ?? () #26 0x8070f3e in eval_instruction ( pc=0x956dbc6 "\213\r0\207.\b¸:$©ö÷Ø\211A\034ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:1229 #27 0x808ab04 in mega_apply (type=APPLY_STACK, args=8, arg1=0x0, arg2=0x0) at /home/david/Pike/7.6/src/interpret.c:1982 #28 0x808ad50 in f_call_function (args=8) at /home/david/Pike/7.6/src/interpret.c:2053 #29 0x285f890d in container_callback (this=0xa005f00, thisobj=0x8db2ed0, v=0x98b4570, startc=0x8b0e5a0, cstartc=123, endc=0x8b0e5a0, cendc=16534, st=0x852ef70, cutstart=0x852ef7c, ccutstart=0x852ef80, cutend=0x8b0e5a0, ccutend=16541) at /home/david/Pike/7.6/src/modules/Parser/html.c:2735 #30 0x285fabe0 in do_try_feed (this=0xa005f00, thisobj=0x8db2ed0, st=0x852ef70, feed=0x852ef7c, finished=1, ignore_tag_cb=0) at /home/david/Pike/7.6/src/modules/Parser/html.c:3224 #31 0x285fc942 in try_feed (finished=1) at /home/david/Pike/7.6/src/modules/Parser/html.c:3737 ---Type <return> to continue, or q <return> to quit--- #32 0x285fd3de in html_finish (args=1) at /home/david/Pike/7.6/src/modules/Parser/html.c:3932 #33 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db2ed0, arg2=0xc) at /home/david/Pike/7.6/src/apply_low.h:214 #34 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=55) at /home/david/Pike/7.6/src/interpret_functions.h:1958 #35 0x9571a8b in ?? () #36 0x8070f3e in eval_instruction (pc=0x8c99b06 "ÇD$\004\e") at /home/david/Pike/7.6/src/interpret.c:1229 #37 0x808ac41 in o_catch (pc=0x8c99b06 "ÇD$\004\e") at /home/david/Pike/7.6/src/interpret.c:2027 #38 0x807c1f8 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #39 0x8c99b00 in ?? () #40 0x8070f3e in eval_instruction ( pc=0x8b2f564 "¡0\207.\b\203@\034\017ÇD$\004\234") at /home/david/Pike/7.6/src/interpret.c:1229 #41 0x808ac41 in o_catch (pc=0x8b2f564 "¡0\207.\b\203@\034\017ÇD$\004\234") at /home/david/Pike/7.6/src/interpret.c:2027 #42 0x807c1f8 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #43 0x8b2f55e in ?? () #44 0x8070f3e in eval_instruction ( ---Type <return> to continue, or q <return> to quit--- pc=0x8b2f527 "\213\r0\207.\b¸Ù\nM÷÷Ø\211A\034Ç\004$\226") at /home/david/Pike/7.6/src/interpret.c:1229 #45 0x808ab04 in mega_apply (type=APPLY_STACK, args=2, arg1=0x0, arg2=0x0) at /home/david/Pike/7.6/src/interpret.c:1982 #46 0x808ad50 in f_call_function (args=2) at /home/david/Pike/7.6/src/interpret.c:2053 #47 0x8165cde in new_thread_func (data=0xbfbfef6c) at /home/david/Pike/7.6/src/threads.c:868 #48 0x282e71b4 in _thread_start () from /usr/lib/libc_r.so.4 #49 0x0 in ?? ()
/ Brevbäraren
But apart from that, you have to consider what the alternatives would be before dissing it (which doesn't imply that I think every single remaining macro is altogether nice and tidy, though). For e.g. block_alloc and fsort, I can only think of C++ templates as being able to improve it in any way.
Writing our own preprocessor has been a success for modules, so perhaps that is also a possible way to go here.
/ Martin Nilsson (räfsfiskal)
Previous text:
2004-05-18 23:51: Subject: Re: Nettle cmod segfault
I think, like many others, that there are too complex macros in Pike and that it's a big problem for code readibility.
I guess you're talking of things like the block_alloc system, fsort.h, the volymous macros for doing string stuff once for each string width, and the undisputed king of the hill: The interpret_functions.h macro system. Things like THREADS_DISALLOW is just an ordinary macro and can hardly be considered a readability problem.
I know what you mean; I got fairly frustrated too the first time I tried to grep through the source for the definition of get_marker and couldn't find it anywhere. Still, once you've groked how it works it's damn handy.
Some of the string processing stuff could probably have been written without macros and instead accept the performance hit, and it got to be possible to clean up the interpret_functions.h stuff somehow. Using macros to at compile time choose between a heap of separate functions and a giant case is a bit over the edge imho; trusting function inlining just a little would have made it a lot simpler.
But apart from that, you have to consider what the alternatives would be before dissing it (which doesn't imply that I think every single remaining macro is altogether nice and tidy, though). For e.g. block_alloc and fsort, I can only think of C++ templates as being able to improve it in any way.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se
-
Martin Nilsson (r�fsfiskal) ＠ Pike (-) developers forum -
Martin Stjernholm, Roxen IS ＠ Pike developers forum