Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #150379 > unrolled thread

Best C compiler

Back to article view | Back to comp.lang.c

Contents

  Best C compiler "Usenet Advocate #1337" <test@dont-email.me> - 2020-03-03 22:38 -0500
    Re: Best C compiler Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-04 04:36 +0000
    Re: Best C compiler Autist <autist69@gmail.com> - 2020-03-04 07:16 +0100
      Re: Best C compiler "Usenet Advocate #1337" <test@dont-email.me> - 2020-03-04 18:48 -0500
        Re: Best C compiler Autist <autist69@gmail.com> - 2020-03-05 06:14 +0100
    Re: Best C compiler already5chosen@yahoo.com - 2020-03-04 01:05 -0800
    Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-04 11:04 +0000
      Re: Best C compiler Real Troll <Real.Troll@Trolls.com> - 2020-03-04 07:25 -0400
        Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-04 11:35 +0000
        Re: Best C compiler gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-04 13:10 +0000
          Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-04 06:12 -0800
        Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-04 10:00 -0800
          Re: Best C compiler Real Troll <real.troll@trolls.com> - 2020-03-04 22:59 -0400
      Re: Best C compiler gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-04 13:07 +0000
    Re: Best C compiler fir <profesor.fir@gmail.com> - 2020-03-04 06:26 -0800
      Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-04 18:08 +0100
        Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-04 09:26 -0800
          Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-04 18:31 +0100
            Re: Best C compiler scott@slp53.sl.home (Scott Lurndal) - 2020-03-04 22:31 +0000
              Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 06:44 +0100
                Re: Best C compiler Real Troll <real.troll@trolls.com> - 2020-03-05 03:20 -0400
                  Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 08:22 +0100
                Re: Best C compiler scott@slp53.sl.home (Scott Lurndal) - 2020-03-05 16:30 +0000
                  Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 17:40 +0100
                    Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-05 08:55 -0800
                      Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 18:47 +0100
                        Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-05 10:06 -0800
                          Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 20:12 +0100
                            Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-05 11:53 -0800
                        Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-06 01:56 -0800
                          Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-06 14:41 +0100
                            Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-06 05:48 -0800
                              Re: Best C compiler chad <cdalten@gmail.com> - 2020-03-06 06:23 -0800
                                Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-06 07:01 -0800
                                  Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-06 16:09 +0100
                                    Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-06 09:52 -0800
                                      Re: Best C compiler Guillaume <message@bottle.org> - 2020-03-06 19:11 +0100
                                        Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-08 09:10 +0000
                                          Re: Best C compiler Guillaume <message@bottle.org> - 2020-03-08 16:08 +0100
                                            Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-08 18:21 +0000
                                              Re: Best C compiler Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-03-08 14:57 -0400
                                                Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-08 19:32 +0000
                                                  Re: Best C compiler Christopher Collins <ccollins476ad@gmail.com> - 2020-03-09 12:44 -0700
                                                    Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-10 07:22 +0000
                                          Re: Best C compiler "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-08 14:34 -0700
                                            tsan (was Re: Best C compiler) Vir Campestris <vir.campestris@invalid.invalid> - 2020-03-11 21:55 +0000
                                              Re: tsan (was Re: Best C compiler) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-11 15:21 -0700
                              Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-06 15:27 +0100
                          Re: Best C compiler Richard Damon <Richard@Damon-Family.org> - 2020-03-07 12:15 -0500
                            Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-07 17:50 +0000
                              Re: Best C compiler Richard Damon <Richard@Damon-Family.org> - 2020-03-07 13:00 -0500
                              Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-08 06:16 -0700
                                Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-08 13:39 +0000
                                  Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-10 13:44 -0700
                                    Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-11 03:34 +0000
                                      Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-11 03:27 -0700
                                        Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-11 15:28 +0000
                                          Re: Best C compiler Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-12 02:51 -0700
                                            Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-12 11:58 +0000
                                              Re: Best C compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 07:01 -0700
                                        Re: Best C compiler Bart <bc@freeuk.com> - 2020-03-11 16:08 +0000
                            Re: Best C compiler Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-08 09:17 +0000
                    Re: Best C compiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-05 23:32 +0000
                      Re: Best C compiler David Brown <david.brown@hesbynett.no> - 2020-03-06 12:37 +0100
        Re: Best C compiler fir <profesor.fir@gmail.com> - 2020-03-04 14:52 -0800
    Re: Best C compiler jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-04 22:09 +0100
    Re: Best C compiler Philipp Klaus Krause <pkk@spth.de> - 2020-03-05 08:48 +0100
      Re: Best C compiler Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-05 12:29 +0100
        Re: Best C compiler David Brown <david.brown@hesbynett.no> - 2020-03-05 12:41 +0100
    Re: Best C compiler "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-03-06 12:11 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#150442

On March 8, 2020 14:21, Jorgen Grahn wrote:

> On Sun, 2020-03-08, Guillaume wrote:
>> Le 08/03/2020 à 10:10, Jorgen Grahn a écrit :
>>> Even though I don't do stepwise debugging a lot myself, one feature
>>> worth mentioning is stopping and then going backwards through the
>>> states.  That can help you find the earlier point where things started
>>> going wrong.
>>> 
>>> There's support for this in gdb nowadays.
>>
>> That's interesting. I don't do stepwise debugging a lot either, but when
>> I do, I occasionally use gdb - and I didn't know it supported this.
> 
> https://www.gnu.org/software/gdb/news/reversible.html
> 
> There may be other choices too.  I remember being shown a separate
> tool for Linux for this, but I cannot remember its name (it was
> something brief and generic like 're').

ITYM rev(1) or tac(1), but neither apply to debuggers.

>> I'll
>> certainly have a look (although again it wouldn't beat a complete log -
>> much easier to read and handle than having to step 'backwards',
>> especially if you need to have a view over a relatively long sequence of
>> events - but this functionality can still be handy to have.)
> 
> That's what I have against stepwise debugging, too: I get lost in the
> tree of choices.  Quite different from using the debugger to look at a
> single state, e.g. in a core dump or at a breakpoint.
> 
> /Jorgen
> 

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#150443

On Sun, 2020-03-08, Lew Pitcher wrote:
> On March 8, 2020 14:21, Jorgen Grahn wrote:
>
>> On Sun, 2020-03-08, Guillaume wrote:
>>> Le 08/03/2020 à 10:10, Jorgen Grahn a écrit :
>>>> Even though I don't do stepwise debugging a lot myself, one feature
>>>> worth mentioning is stopping and then going backwards through the
>>>> states.  That can help you find the earlier point where things started
>>>> going wrong.
>>>> 
>>>> There's support for this in gdb nowadays.
>>>
>>> That's interesting. I don't do stepwise debugging a lot either, but when
>>> I do, I occasionally use gdb - and I didn't know it supported this.
>> 
>> https://www.gnu.org/software/gdb/news/reversible.html
>> 
>> There may be other choices too.  I remember being shown a separate
>> tool for Linux for this, but I cannot remember its name (it was
>> something brief and generic like 're').
>
> ITYM rev(1) or tac(1), but neither apply to debuggers.

None of them -- although a problem with the name was that it sounded
like the name of an ancient text manipulating filter like those.

Speaking of filters and debuggers, the last two times I had to debug,
the solution was to provoke a core dump, and then

  % sort coredump | uniq -c

A very blunt tool, but if you have a huge memory leak and just need to
blame the right subsystem, worth a try.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150458

On 2020-03-08, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
[...]

> Speaking of filters and debuggers, the last two times I had to debug,
> the solution was to provoke a core dump, and then
>
>   % sort coredump | uniq -c
>
> A very blunt tool, but if you have a huge memory leak and just need to
> blame the right subsystem, worth a try.

Would you mind clarifying this a bit?  Is `coredump` a regular ELF core
file or is it some text representation of one?

I did try running that pipeline on a core file but the output wasn't
meaningful (to me).

Chris

[toc] | [prev] | [next] | [standalone]

#150460

On Mon, 2020-03-09, Christopher Collins wrote:
> On 2020-03-08, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> [...]
>
>> Speaking of filters and debuggers, the last two times I had to debug,
>> the solution was to provoke a core dump, and then
>>
>>   % sort coredump | uniq -c
>>
>> A very blunt tool, but if you have a huge memory leak and just need to
>> blame the right subsystem, worth a try.
>
> Would you mind clarifying this a bit?  Is `coredump` a regular ELF core
> file or is it some text representation of one?
>
> I did try running that pipeline on a core file but the output wasn't
> meaningful (to me).

Oh, sorry! I meant

% strings coredump | sort | uniq -c

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150444

On 3/8/2020 1:10 AM, Jorgen Grahn wrote:
> On Fri, 2020-03-06, Guillaume wrote:
>> Le 06/03/2020 à 18:52, Malcolm McLean a écrit :
>>> You can break when x goes to zero, but you then lose the information about
>>> the previous values. Which is often important.
>>> (...)
>>
>> Logging and otherwise instrumenting code are invaluable tools and
>> debuggers are no replacement for that in many cases in which not just a
>> specific condition, but the whole succession of events leading to it is
>> important to understand what happens. Which is usually completely
>> unpractical to do with debuggers alone.
> 
> Even though I don't do stepwise debugging a lot myself, one feature
> worth mentioning is stopping and then going backwards through the
> states.  That can help you find the earlier point where things started
> going wrong.
> 
> There's support for this in gdb nowadays.

One time, a long time ago, Iirc even posted about it here way back, I 
had to debug a piece of software that had a nasty race condition. A 
single function spawned several threads to help compute a single result, 
joined them, then returned it. The function would block until the result 
was ready.

Well, the race condition would cause things to return false results from 
time to time during testing. So, I isolated the function, in the 
debugger. Allowed it to spawn the threads, and paused them at certain 
lines in the code. So I had a state with several threads all paused. 
Then I allowed one thread to run, by resuming it running up to a point 
then paused it again. Allowed the other threads to run, and noticed that 
they would overwrite a variable willy nilly, without any 
synchronization. I can see how running a single thread worked every 
time. Then, noticed how two threads running caused the problem. Well, 
there was a variable that was outside of a critical section that was 
being mutated without using proper sync. Finally fixed it.

Imvho, being able to pause threads at precise points during debugging 
can be useful, from time to time.

[toc] | [prev] | [next] | [standalone]

#150495 — tsan (was Re: Best C compiler)

On 08/03/2020 21:34, Chris M. Thomasson wrote:
<snip>
> Then I allowed one thread to run, by resuming it running up to a point 
> then paused it again. Allowed the other threads to run, and noticed that 
> they would overwrite a variable willy nilly, without any 
> synchronization.
</snip>

FYI this is what tsan is for

https://clang.llvm.org/docs/ThreadSanitizer.html

(and many similar ones)

Andy

[toc] | [prev] | [next] | [standalone]

#150497 — Re: tsan (was Re: Best C compiler)

On 3/11/2020 2:55 PM, Vir Campestris wrote:
> On 08/03/2020 21:34, Chris M. Thomasson wrote:
> <snip>
>> Then I allowed one thread to run, by resuming it running up to a point 
>> then paused it again. Allowed the other threads to run, and noticed 
>> that they would overwrite a variable willy nilly, without any 
>> synchronization.
> </snip>
> 
> FYI this is what tsan is for
> 
> https://clang.llvm.org/docs/ThreadSanitizer.html

Indeed. Fwiw, I am friends with the guy who created Relacy, and who 
works on tsan. We go way back on comp.programming.threads:

https://github.com/dvyukov/relacy

> 
> (and many similar ones)

Right. However, when I had to do this, was a long time ago, well before 
Relacy.

[toc] | [prev] | [next] | [standalone]

#150425

>> Then we restart the code and make a breakpoint where x is set.

> x is set ten thousand times before it goes to zero.

Unlikely that you have code where there are thousand places
where x is set. Usually there's only one and normally you
simply place a conditional breakpoint there.

[toc] | [prev] | [next] | [standalone]

#150431

On 3/6/20 4:56 AM, Malcolm McLean wrote:
> On Thursday, 5 March 2020 17:48:08 UTC, Bonita Montero  wrote:
>>> Depends on the code. Debuggers are useful if the error occurs on the
>>> first few iterations of the code.
>>
>> Do you know conditional breakpoints ?
>>
>>> However if it takes many iterations before the bug becomes evident,
>>> a printf trace of the program's state can be more useful.
>>
>> Yeeees, a printf every iteration for a lot iterations.
>> Makes _perfectly_ sense to me.
>> printf()-debugging is a shit.
>>
> Say that we have the line
> y = 1/x;
> 
> x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?
> 
> if we put in the line
> printf("x = %e\n", x);
> 
> then we get a list of all values of x before x goes to zero. There might be 
> ten thousand of them. But likely things start to go wrong in the last hundred 
> or so. We might see x gradually decrease in absolute value, wildly oscillate, or get into a pattern of alternating positive and negative values which steadily get lower. Or it might not be that all values until the last one look fine,
> but we have a few isolated very low values further up in the trace.
> The printf() method allows us to quickly monitor the state of the variable.
> 

Another alternative, that doesn't generate as long of an output is to
instrument the code to save the values of x in an array being used as a
circular buffer. Then when x takes on the bad value, you can look at
just the recent history of the changes.

[toc] | [prev] | [next] | [standalone]

#150432

Richard Damon <Richard@Damon-Family.org> writes:

> On 3/6/20 4:56 AM, Malcolm McLean wrote:
>> On Thursday, 5 March 2020 17:48:08 UTC, Bonita Montero  wrote:
>>>> Depends on the code. Debuggers are useful if the error occurs on the
>>>> first few iterations of the code.
>>>
>>> Do you know conditional breakpoints ?
>>>
>>>> However if it takes many iterations before the bug becomes evident,
>>>> a printf trace of the program's state can be more useful.
>>>
>>> Yeeees, a printf every iteration for a lot iterations.
>>> Makes _perfectly_ sense to me.
>>> printf()-debugging is a shit.
>>>
>> Say that we have the line
>> y = 1/x;
>> 
>> x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?
>> 
>> if we put in the line
>> printf("x = %e\n", x);
>> 
>> then we get a list of all values of x before x goes to zero. There might be 
>> ten thousand of them. But likely things start to go wrong in the last hundred 
>> or so. We might see x gradually decrease in absolute value, wildly oscillate, or get into a pattern of alternating positive and negative values which steadily get lower. Or it might not be that all values until the last one look fine,
>> but we have a few isolated very low values further up in the trace.
>> The printf() method allows us to quickly monitor the state of the variable.
>> 
>
> Another alternative, that doesn't generate as long of an output is to
> instrument the code to save the values of x in an array being used as a
> circular buffer. Then when x takes on the bad value, you can look at
> just the recent history of the changes.

But I imagine this is an argument for using an interactive debugger
since this is the sort of thing they should do, either through a "show
last 20 values of x at this watch point" or by providing an embedded
scripting language so you can do what you like to store a process data
coming from the instrumented program.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150433

On 3/7/20 12:50 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> 
>> On 3/6/20 4:56 AM, Malcolm McLean wrote:
>>> On Thursday, 5 March 2020 17:48:08 UTC, Bonita Montero  wrote:
>>>>> Depends on the code. Debuggers are useful if the error occurs on the
>>>>> first few iterations of the code.
>>>>
>>>> Do you know conditional breakpoints ?
>>>>
>>>>> However if it takes many iterations before the bug becomes evident,
>>>>> a printf trace of the program's state can be more useful.
>>>>
>>>> Yeeees, a printf every iteration for a lot iterations.
>>>> Makes _perfectly_ sense to me.
>>>> printf()-debugging is a shit.
>>>>
>>> Say that we have the line
>>> y = 1/x;
>>>
>>> x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?
>>>
>>> if we put in the line
>>> printf("x = %e\n", x);
>>>
>>> then we get a list of all values of x before x goes to zero. There might be 
>>> ten thousand of them. But likely things start to go wrong in the last hundred 
>>> or so. We might see x gradually decrease in absolute value, wildly oscillate, or get into a pattern of alternating positive and negative values which steadily get lower. Or it might not be that all values until the last one look fine,
>>> but we have a few isolated very low values further up in the trace.
>>> The printf() method allows us to quickly monitor the state of the variable.
>>>
>>
>> Another alternative, that doesn't generate as long of an output is to
>> instrument the code to save the values of x in an array being used as a
>> circular buffer. Then when x takes on the bad value, you can look at
>> just the recent history of the changes.
> 
> But I imagine this is an argument for using an interactive debugger
> since this is the sort of thing they should do, either through a "show
> last 20 values of x at this watch point" or by providing an embedded
> scripting language so you can do what you like to store a process data
> coming from the instrumented program.
> 

Maybe, if your debugger has that capability and you know how to use it,
and running under such a debugger is possible and doesn't slow things
down too much.

Adding the functionality yourself is fairly simple and straight forward
(assuming you were good and all updates to x funnel through an
appropriate point).

A side benefit of roll your own is it is easier to also record some
auxiliary inputs relating to that update to help you decode the history.

[toc] | [prev] | [next] | [standalone]

#150438

On Saturday, 7 March 2020 17:50:23 UTC, Ben Bacarisse  wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> 
> > On 3/6/20 4:56 AM, Malcolm McLean wrote:
> >> On Thursday, 5 March 2020 17:48:08 UTC, Bonita Montero  wrote:
> >>>> Depends on the code. Debuggers are useful if the error occurs on the
> >>>> first few iterations of the code.
> >>>
> >>> Do you know conditional breakpoints ?
> >>>
> >>>> However if it takes many iterations before the bug becomes evident,
> >>>> a printf trace of the program's state can be more useful.
> >>>
> >>> Yeeees, a printf every iteration for a lot iterations.
> >>> Makes _perfectly_ sense to me.
> >>> printf()-debugging is a shit.
> >>>
> >> Say that we have the line
> >> y = 1/x;
> >> 
> >> x goes to zero and it crashes. Now we could break on x == 0, but that won't tell us what happened to x before it went to zero. Or we could break on fabs(x) < epsilon, but what do we use for epsilon, how do we set up the condition in the debugger, and will it give us false positives?
> >> 
> >> if we put in the line
> >> printf("x = %e\n", x);
> >> 
> >> then we get a list of all values of x before x goes to zero. There might be 
> >> ten thousand of them. But likely things start to go wrong in the last hundred 
> >> or so. We might see x gradually decrease in absolute value, wildly oscillate, or get into a pattern of alternating positive and negative values which steadily get lower. Or it might not be that all values until the last one look fine,
> >> but we have a few isolated very low values further up in the trace.
> >> The printf() method allows us to quickly monitor the state of the variable.
> >> 
> >
> > Another alternative, that doesn't generate as long of an output is to
> > instrument the code to save the values of x in an array being used as a
> > circular buffer. Then when x takes on the bad value, you can look at
> > just the recent history of the changes.
> 
> But I imagine this is an argument for using an interactive debugger
> since this is the sort of thing they should do, either through a "show
> last 20 values of x at this watch point" or by providing an embedded
> scripting language so you can do what you like to store a process data
> coming from the instrumented program.
> 
> -- 
> Ben.
>
If you go down the route of writing scripts for the debugger, then you 
get bugs in the scripts.

[toc] | [prev] | [next] | [standalone]

#150439

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Saturday, 7 March 2020 17:50:23 UTC, Ben Bacarisse  wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
<cut>
>> > Another alternative, that doesn't generate as long of an output is to
>> > instrument the code to save the values of x in an array being used as a
>> > circular buffer. Then when x takes on the bad value, you can look at
>> > just the recent history of the changes.
>> 
>> But I imagine this is an argument for using an interactive debugger
>> since this is the sort of thing they should do, either through a "show
>> last 20 values of x at this watch point" or by providing an embedded
>> scripting language so you can do what you like to store a process data
>> coming from the instrumented program.
>>
> If you go down the route of writing scripts for the debugger, then you 
> get bugs in the scripts.

You make it sound inevitable.  You may get bugs, and when you do they
may be trivial and immediately obvious.  You are not, I hope, advocating
against optional functionality on the grounds that it can go wrong.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150461

On Sunday, 8 March 2020 13:39:49 UTC, Ben Bacarisse  wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> 
> > If you go down the route of writing scripts for the debugger, then you 
> > get bugs in the scripts.
> 
> You make it sound inevitable.  You may get bugs, and when you do they
> may be trivial and immediately obvious.  You are not, I hope, advocating
> against optional functionality on the grounds that it can go wrong.
> 
Adding options because it is technically possible to do so, without
any consideration of how easy the software is to use, isn't a route
to good design. Particularly if it is decided to provide a user
interface in the form of a scripting language.

[toc] | [prev] | [next] | [standalone]

#150464

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, 8 March 2020 13:39:49 UTC, Ben Bacarisse  wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> 
>> > If you go down the route of writing scripts for the debugger, then you 
>> > get bugs in the scripts.
>> 
>> You make it sound inevitable.  You may get bugs, and when you do they
>> may be trivial and immediately obvious.  You are not, I hope, advocating
>> against optional functionality on the grounds that it can go wrong.
>> 
> Adding options because it is technically possible to do so, without
> any consideration of how easy the software is to use, isn't a route
> to good design. Particularly if it is decided to provide a user
> interface in the form of a scripting language.

We largely agree.  The fact that any script can have bugs is not, on its
own, enough to ban embedded scripting from all applications.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150471

On Wednesday, 11 March 2020 03:34:28 UTC, Ben Bacarisse  wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> 
> > On Sunday, 8 March 2020 13:39:49 UTC, Ben Bacarisse  wrote:
> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >> 
> >> > If you go down the route of writing scripts for the debugger, then you 
> >> > get bugs in the scripts.
> >> 
> >> You make it sound inevitable.  You may get bugs, and when you do they
> >> may be trivial and immediately obvious.  You are not, I hope, advocating
> >> against optional functionality on the grounds that it can go wrong.
> >> 
> > Adding options because it is technically possible to do so, without
> > any consideration of how easy the software is to use, isn't a route
> > to good design. Particularly if it is decided to provide a user
> > interface in the form of a scripting language.
> 
> We largely agree.  The fact that any script can have bugs is not, on its
> own, enough to ban embedded scripting from all applications.
> 
No, but of all the interfaces that you can offer to the user, a scripting
interface probably offers the most flexibility combined with the worst
ease of use. Once scripts get above a certain very basic level of
complexity, the user, now a programmer, makes errors. That's the experience
of software engineering.

However a debugger is in a special situation, in it is already designed
to remove bugs from a scripting language. 

[toc] | [prev] | [next] | [standalone]

#150477

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 11 March 2020 03:34:28 UTC, Ben Bacarisse  wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> 
>> > On Sunday, 8 March 2020 13:39:49 UTC, Ben Bacarisse  wrote:
>> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> >> 
>> >> > If you go down the route of writing scripts for the debugger, then you 
>> >> > get bugs in the scripts.
>> >> 
>> >> You make it sound inevitable.  You may get bugs, and when you do they
>> >> may be trivial and immediately obvious.  You are not, I hope, advocating
>> >> against optional functionality on the grounds that it can go wrong.
>> >> 
>> > Adding options because it is technically possible to do so, without
>> > any consideration of how easy the software is to use, isn't a route
>> > to good design. Particularly if it is decided to provide a user
>> > interface in the form of a scripting language.
>> 
>> We largely agree.  The fact that any script can have bugs is not, on its
>> own, enough to ban embedded scripting from all applications.
>> 
> No, but of all the interfaces that you can offer to the user, a scripting
> interface probably offers the most flexibility combined with the worst
> ease of use. Once scripts get above a certain very basic level of
> complexity, the user, now a programmer, makes errors. That's the experience
> of software engineering.

I was not suggesting that other interfaces were /not/ provided.  Are you
saying that scripting is like a drug so even providing it as an option
will draw inexperienced people into some sort spiral of buggy
dependence?  It should simply be an option for those who find it useful.

> However a debugger is in a special situation, in it is already designed
> to remove bugs from a scripting language.

I don't follow.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150502

On Wednesday, 11 March 2020 15:28:43 UTC, Ben Bacarisse  wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> 
> > No, but of all the interfaces that you can offer to the user, a scripting
> > interface probably offers the most flexibility combined with the worst
> > ease of use. Once scripts get above a certain very basic level of
> > complexity, the user, now a programmer, makes errors. That's the experience
> > of software engineering.
> 
> I was not suggesting that other interfaces were /not/ provided.  Are you
> saying that scripting is like a drug so even providing it as an option
> will draw inexperienced people into some sort spiral of buggy
> dependence?  It should simply be an option for those who find it useful.
>
If you provide an option, then the users have to learn about and
explore that option, before they decide whether it is useful to them or
not. That takes time. Then, in many environments, getting to know a new
software package is not an unusual thing, it's a constant situation.
Then many users will be reluctant to reject the option too quickly,
because if it is provided, that must mean it is useful.
So you can waste a lot of time by providing functions which are difficult
to use, even if they are optional.
Then does the debugger have an option to save scripts? That's a relatively
easy option to provide, so by your logic, it should be provided. But
then what will happen is that scripts are written and saved by other
members of the team, and passed about. Suddenly the scripting interface
is not so optional. And you have to learn, not just a very basic subset
of the scripting language, but all the facilities that are used by any
member of the team, anywhere.
You very quickly create a monster.
> 
> > However a debugger is in a special situation, in it is already designed
> > to remove bugs from a scripting language.
> 
> I don't follow.
>
A debugger is designed to remove bugs. If it accepts a scripting language,
some scripts will inevitably contain bugs. So it's adding bugs as well
as removing them. You could have a meta debugger that steps through the
debugging script interactively to help the user find bugs.

If the software package is not a debugger, then the scripts will also
potentially contain bugs, but the overall aim is not to remove bugs.

[toc] | [prev] | [next] | [standalone]

#150504

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 11 March 2020 15:28:43 UTC, Ben Bacarisse  wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> 
>> > No, but of all the interfaces that you can offer to the user, a scripting
>> > interface probably offers the most flexibility combined with the worst
>> > ease of use. Once scripts get above a certain very basic level of
>> > complexity, the user, now a programmer, makes errors. That's the experience
>> > of software engineering.
>> 
>> I was not suggesting that other interfaces were /not/ provided.  Are you
>> saying that scripting is like a drug so even providing it as an option
>> will draw inexperienced people into some sort spiral of buggy
>> dependence?  It should simply be an option for those who find it useful.
>>
> If you provide an option, then the users have to learn about and
> explore that option, before they decide whether it is useful to them or
> not.

No they don't.  When I look at the menus for, say, OpenOffice there a
tons of things there I have no idea if they would be useful to me or
not.

> That takes time. Then, in many environments, getting to know a new
> software package is not an unusual thing, it's a constant situation.
> Then many users will be reluctant to reject the option too quickly,
> because if it is provided, that must mean it is useful.

I mean optional to use, not "you must decide once and for all, if you
want to use this".  Users "reject" this sort of option all the time by
simply not using it.  And I can't begin to list the optional parts of
Emacs that are completely unknown to me.

> So you can waste a lot of time by providing functions which are difficult
> to use, even if they are optional.

If you are right (and I don't think you are) what do you suggest?
Should only certain approved people be allowed to use highly functional
software, or should everyone have to use the Notepads of this world in
case too much time is wasted?  Capitalism can't have that -- people
learning stuff they might not need!

> Then does the debugger have an option to save scripts? That's a relatively
> easy option to provide, so by your logic, it should be provided.

Of course.  It should have an option to save all it's state.  Don't they
do that now?  Some didn't I know, that that was decades ago when they
were primitive.  If I've instrumented a program with watch points and
conditional breaks and so on, surely I don't have to re-do that every
time I start a new session?

> But
> then what will happen is that scripts are written and saved by other
> members of the team, and passed about.

Cooperation will happen.

> Suddenly the scripting interface
> is not so optional. And you have to learn, not just a very basic subset
> of the scripting language, but all the facilities that are used by any
> member of the team, anywhere.

Hmm... are you hoping that software design will solve management issues?
I think that's doomed.  If the team can't cope with the scripting, the
team should not use it.

> You very quickly create a monster.

Do you have a set of rules about how limited software should be so as to
make it maximally productive and minimally distracting (AKA
intellectually stimulating)?  Obviously scripting is out (is it out in
all contexts?), but what about other things that might waste people's
time like regular expressions?

>> > However a debugger is in a special situation, in it is already designed
>> > to remove bugs from a scripting language.
>> 
>> I don't follow.
>>
> A debugger is designed to remove bugs.

Ah, I think this may be part of the problem.  I think a debugger is
there to help programmers understand the dynamic behaviour of they
programs.  The debugger itself does not remove any bugs, and it's value
should go beyond finding bugs.

> If it accepts a scripting language,
> some scripts will inevitably contain bugs. So it's adding bugs as well
> as removing them.

In both cases it's the programmer, and both are potential rather than
certain.  Obviously you are using anthropomorphism as a shorthand, but I
think it's a particularly confusing way to say it.  People might be able
to find bugs using a debugger, and people might also introduce bugs into
the process by writing bad scripts.

> You could have a meta debugger that steps through the
> debugging script interactively to help the user find bugs.

You could.  I don't think that would be very useful though.  Any
programmer finding themselves in the position where they don't know what
their scripts are doing should know to back out of that.

> If the software package is not a debugger, then the scripts will also
> potentially contain bugs, but the overall aim is not to remove bugs.

Many of your comments were very general and I've replied to them in the
vein.  Should they all be taken to apply only in the context of a
debugger?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150857

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> I can't begin to list the optional parts of Emacs that are
> completely unknown to me.

That's a relief.  If you _could_ begin to list the optional parts
of Emacs (or anything else, for that matter) that are completely
unknown to you, I would be seriously worried for the fate of the
Universe.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web