There’s one thing I noticed: if debugging is disabled, then parenthesis highlighting is also disabled (as well as other visual aids, if I remember well?). The editor also feels faster because of this, but navigating parentheses becomes slightly more tedious without it.
Dex > On Apr 25, 2020, at 3:25 PM, sleepnova <wanpee...@gmail.com> wrote: > > > That may help to reduce misimpression. And plus, maybe append some message to > error message to inform user that they can turn on errortrace if they need > more detailed debugging information, when errortrace doesn't enabled. > > To be clarify, what you mentioned is "Preserve errortrace" option, what about > "Debugging" option, is it a must enabled option in a non-debugging run? > > <截圖 2020-04-25 下午9.22.20.png> > > > Sorawee Porncharoenwase <sorawee.pw...@gmail.com> 於 2020年4月25日 週六 下午8:17寫道： >> It could go either way, no? I've also heard a lot of people complaining that >> debugging Racket programs is difficult because the stack trace is not >> useful, and this is because they use the command-line version which doesn't >> have errortrace enabled (by default). >> >> Perhaps what you really are complaining is that the option to enable/disable >> errortrace is not easily discoverable. Would it help if at: >> >> <Screen Shot 2020-04-25 at 05.11.29.png> >> >> >> the text is changed from `racket, with debugging` to `racket, with debugging >> (slower)`. And the texts are linkified so that when `racket` is clicked, it >> leads you to the non-detailed language setting, and when `with debugging >> (slower)` is clicked, it leads you to the detailed language setting? >> >> On Sat, Apr 25, 2020 at 3:51 AM Liwei Chou <wanpee...@gmail.com> wrote: >>> Thanks Dexter, >>> >>> Yes, now I know it’s due to the debugging and tracing configuration. After >>> turn off debugging and profiling, it becomes. >>> >>> cpu time: 20 real time: 20 gc time: 0 >>> >>> If disable Preserve stacktrace also, I got. >>> >>> cpu time: 7 real time: 7 gc time: 0 >>> >>> Which is pretty decent, 16x acceleration. >>> >>> It's not a problem for me now. However, this behavior may give some new >>> users the wrong impression that the language may not be very efficient, >>> which may make some people choose not to continue trying it. >>> >>> From the perspective of increasing adoption and reducing barriers, it's not >>> a good thing. >>> >>> If Racket team can consider making normal run and debug run using different >>> default settings, which conventional development environments usually do, >>> that can easily solve this problem. >>> >>> Dexter Lagan於 2020年4月25日星期六 UTC+8下午5時17分31秒寫道： >>>> >>>> Hi Liwei, >>>> >>>> I believe disabling debugging and tracing does accelerate the evaluation >>>> quite a bit from inside DrRacket. On my system, it seems to be running my >>>> code at the same speed as the main racket binary. >>>> >>>> Dex >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Racket Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to racket-users+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/racket-users/cb5e4fa5-2766-4242-aff5-8933bee637c6%40googlegroups.com. > > > -- > - sleepnova > 呼叫小黃創辦人 & CEO > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CABa2-7O1cv_sOrGRWxoHetdwDLiKLSOpZdt8T3YPj4yQQome7w%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/71148F23-E424-4580-8CAB-DC40AA0B5D47%40gmail.com.
