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

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

OT: improve this simple algorithm?

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

Contents

  OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 15:55 -0500
    Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-12 21:20 +0000
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 23:28 -0500
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:52 +0100
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-13 10:16 -0500
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 16:53 +0100
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 11:18 +0000
    Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 23:30 +0000
      Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 05:12 +1300
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 16:34 +0000
          Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 10:07 +1300
            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 22:25 +0000
              Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 12:02 +1300
                Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 23:27 +0000
                  Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 19:06 +1300
                    Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 10:45 +0000
                      Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 13:28 +0100
                        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 12:58 +0000
                          Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 15:39 +0100
                            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 15:04 +0000
                              Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 12:19 -0500
                                Re: OT: improve this simple algorithm? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-15 09:46 -0800
                                Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 18:59 +0000
                            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-16 11:59 +0000
                      Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-16 09:02 +1300
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 11:17 +0100
                  Re: OT: improve this simple algorithm? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-15 21:38 +0000
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 11:44 -0500
        Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-14 18:11 +0000
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 13:33 -0500
            Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 01:49 +0000
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-14 10:38 -0800
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 12:56 -0500
        Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-14 13:50 -0500
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 14:42 -0500
            Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-14 15:25 -0500
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-14 11:03 -0800
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 16:08 -0500
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 11:30 +0100
              Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 11:17 +0000
                Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 17:35 -0500
                  Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 17:39 -0500
                  Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 23:19 +0000
                    Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 18:53 -0500
                      Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 19:08 -0500
                      Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-16 01:30 +0000
                        Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-16 07:39 -0500
                  Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-16 07:37 -0500
            Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-15 09:46 -0500
              Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 12:38 -0500
                Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 23:07 +0000
                Re: OT: improve this simple algorithm? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:54 -0800
                  Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-28 20:17 -0500
                    Re: OT: improve this simple algorithm? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-29 06:08 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:45 +0100
      Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-14 10:10 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:19 +0100
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 23:57 -0500
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:34 +0100
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-13 23:57 -0500
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-13 23:00 -0800
        Re: OT: improve this simple algorithm? Ike Naar <ike@sdf.lonestar.org> - 2019-11-14 07:53 +0000
          Re: OT: improve this simple algorithm? guinness.tony@gmail.com - 2019-11-14 02:34 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 10:01 +0100
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 11:27 +0000
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 12:46 +0100
              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 12:01 +0000
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 14:05 +0100
    Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-12 18:34 -0800
      Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-12 19:01 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 17:08 +0100
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 17:06 +0000
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 19:11 +0000
        Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 05:15 +1300
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 18:13 +0000
          Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 20:16 +0100
            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 20:03 +0000
              Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 04:51 +0100
        Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-14 10:15 -0800
          Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:52 +0100
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:57 +0100
          Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-13 23:23 +1300
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 11:53 +0000
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 14:02 +0100
              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 13:40 +0000
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 17:01 +0100
                  Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 16:28 +0000
                    Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 22:49 +0100
                      Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 22:38 +0000
                        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 23:06 +0000
                        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 10:10 +0100
                          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 10:42 +0000
                            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 12:53 +0100
                              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 12:28 +0000
                                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 14:21 +0100
                                  Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 14:28 +0000
                                    Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 15:38 +0100
                        Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:37 +0100
                          Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:38 +0100
            Re: OT: improve this simple algorithm? Thiago Adams <thiago.adams@gmail.com> - 2019-11-13 05:21 -0800

Page 1 of 5  [1] 2 3 4 5  Next page →

#147976 — OT: improve this simple algorithm?

You clc guys are masters at this stuff.

Goal: Find all the open intervals in an ordered set of numbers

nbrs  = [1, 2, 4, 5, 7, 12, 1300, 10000]
opens = [(3, 3), (6, 6), (8, 11), (13, 1299), (1301, 9999)]

I think 'open intervals' is the right terminology.

My simple algorithm:

if nbrs is contiguous then exit
else
   for i in range(nbrs)
     if nbrs[i+1] - nbrs[i] > 1 then
       startinterval =  nbrs[i] + 1
       if nbrs[i+1] - startinterval >= 1 then
         endinterval = nbrs[i+1] - 1



==============================================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void) {

   int i = 0, x = 0;
   int nums[] = {1, 2, 4, 5, 7, 12, 1300, 10000};
   //int nums[] = {3,4,5,7,8};  //sequential, for testing
   int lenNums = sizeof(nums)/sizeof(nums[0]);
   int start = nums[0];
   int end   = nums[lenNums-1];
   char *interval = "";
   char *intervals[sizeof(char*) * lenNums];

   //check for no open intervals
   if((end-start)==(lenNums-1)) {
     printf("Number set is sequential from %d to %d\n",start,end);
     exit(0);
   }	
	
   //find open intervals
   x = 0;
   for(i=0;i<lenNums;i++) {
     if(nums[i+1]-nums[i] > 1) {
       start = nums[i]+1;
       if(nums[i+1]-start >= 1) {
         end = nums[i+1]-1;
         //end of algorithm

         sprintf(interval,"(%d,%d)",start,end);
         intervals[x] = interval;    //assignment seems to work
         printf("%s ",intervals[x]);
         x++;

       }
     }		
   }

printf("\n\n");

//Why do the following not work, given that the
//assignment and printf() in the loop above seems to?
printf("Interval 1 = %s\n",intervals[0]);
printf("Interval 2 = %s\n",intervals[1]);
printf("Interval 3 = %s\n",intervals[2]);
printf("Interval 4 = %s\n",intervals[3]);
printf("Interval 5 = %s\n",intervals[4]);
printf("\n");
for(i=0;i<x;i++) {
   printf("%s ",intervals[i]);
}  	


printf("\nDone");
exit(0);		
}
==============================================

[toc] | [next] | [standalone]

#147977

On 12/11/2019 20:55, DFS wrote:
> You clc guys are masters at this stuff.
> 
> Goal: Find all the open intervals in an ordered set of numbers
> 
> nbrs  = [1, 2, 4, 5, 7, 12, 1300, 10000]
> opens = [(3, 3), (6, 6), (8, 11), (13, 1299), (1301, 9999)]

(If already sorted, then this task is fairly trivial, just a bit fiddly. 
For example in my script language:

     proc start=
         nbrs  := [1, 2, 4, 5, 7, 12, 1300, 10000]
         println -nbrs         # or inot nbrs
     end

Output is:

     [0,3,6,8..11,13..1299,1301..9999]

Which is most of it done (needs to properly define the lower bound, and 
format output as desired). But the approach here involves bita-rrays, 
which can use lots of memory for big numbers.)

> I think 'open intervals' is the right terminology.
> 
> My simple algorithm:
> 
> if nbrs is contiguous then exit
> else
>    for i in range(nbrs)
>      if nbrs[i+1] - nbrs[i] > 1 then
>        startinterval =  nbrs[i] + 1
>        if nbrs[i+1] - startinterval >= 1 then
>          endinterval = nbrs[i+1] - 1
> 
> 

>    char *intervals[sizeof(char*) * lenNums];

Use char ** here; see below.

>          sprintf(interval,"(%d,%d)",start,end);
>          intervals[x] = interval;    //assignment seems to work

Same problem as a week or two ago: all intervals[x] point to the same 
interval string, ie. the last one when done.

I used this helper function

     char* allocstring(char* s){
        char *t=malloc(strlen(s)+1);
        strcpy(t,s);
        return t;
     }

then the assignment becomes:

         intervals[x] = allocstring(interval);

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

#148213

On 11/12/2019 4:20 PM, Bart wrote:
> On 12/11/2019 20:55, DFS wrote:
>> You clc guys are masters at this stuff.
>>
>> Goal: Find all the open intervals in an ordered set of numbers
>>
>> nbrs  = [1, 2, 4, 5, 7, 12, 1300, 10000]
>> opens = [(3, 3), (6, 6), (8, 11), (13, 1299), (1301, 9999)]
> 
> (If already sorted, then this task is fairly trivial, just a bit fiddly. 
> For example in my script language:
> 
>      proc start=
>          nbrs  := [1, 2, 4, 5, 7, 12, 1300, 10000]
>          println -nbrs         # or inot nbrs
>      end
> 
> Output is:
> 
>      [0,3,6,8..11,13..1299,1301..9999]


Your language already has builtin functions to find gaps in a sequence? 
Sweet.  Or did you just now write it?



> Which is most of it done (needs to properly define the lower bound, and 
> format output as desired). But the approach here involves bita-rrays, 
> which can use lots of memory for big numbers.)

>> I think 'open intervals' is the right terminology.
>>
>> My simple algorithm:
>>
>> if nbrs is contiguous then exit
>> else
>>    for i in range(nbrs)
>>      if nbrs[i+1] - nbrs[i] > 1 then
>>        startinterval =  nbrs[i] + 1
>>        if nbrs[i+1] - startinterval >= 1 then
>>          endinterval = nbrs[i+1] - 1


Is there a faster/better way (you mentioned bit-arrays - what does that 
code look like?  Seems complicated.  Why would you use such a thing to 
find these intervals?


>>    char *intervals[sizeof(char*) * lenNums];
> 
> Use char ** here; see below.

That created a couple warnings:

getintervals.c:38:22: warning: assignment to ‘char **’ from incompatible 
pointer type ‘char *’ [-Wincompatible-pointer-types]
    38 |         intervals[x] = str;
       |                      ^
getintervals.c:46:12: warning: format ‘%s’ expects argument of type 
‘char *’, but argument 2 has type ‘char **’ [-Wformat=]
    46 |   printf("%s ",intervals[i]);
       |           ~^   ~~~~~~~~~~~~
       |            |            |
       |            char *       char **



>>          sprintf(interval,"(%d,%d)",start,end);
>>          intervals[x] = interval;    //assignment seems to work
> 
> Same problem as a week or two ago: all intervals[x] point to the same 
> interval string, ie. the last one when done.

> I used this helper function
> 
>      char* allocstring(char* s){
>         char *t=malloc(strlen(s)+1);
>         strcpy(t,s);
>         return t;
>      }
> 
> then the assignment becomes:
> 
>          intervals[x] = allocstring(interval);


OK.  But outside fn() not strictly needed, so I did it in the loop, like so:


char interval[30];                         //set size to accomodate
                                              large range
char *intervals[sizeof(char*) * lenNums];  //no pointer to pointer

loop
  sprintf(interval,"[%d,%d]",start,end);
  char *str=malloc(strlen(interval)+1);
  strcpy(str,interval);
  intervals[x] = str;

It compiles and works - please tell me there's nothing wrong there.



I understand there "is no string type in C", but all that work to assign 
an array of chars to an array position?

Since I already sized the array up front and set interval to the correct 
value...

char *intervals[sizeof(char*) * lenNums];
sprintf(interval,"[%d,%d]",start,end);

... what's the use of having to create the temp/working variable, 
copying what's in interval to temp, then assigning the temp to the 
array?  The space is already allocated and the string is correctly set.

Either one of these /should/ work, but somebody's cruel:

sprintf(interval,"[%d,%d]",start,end);
strcpy(intervals[x],interval);

or

sprintf(interval,"[%d,%d]",start,end);
intervals[x] = interval;



Thanks for your help, man!  At some point I'll build up C-memory and 
stop asking easy questions.

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

#148219

On 13/11/2019 05:28, DFS wrote:

> 
> I understand there "is no string type in C", but all that work to assign
> an array of chars to an array position?
> 

The main point to understand is that there is no automatic memory
management in C.  If you need to store things with different sizes, you
have to allocate memory for them along the way - using malloc or related
functions.  And you have to free the memory after use.  (In most
systems, once the program stops all allocated memory will be freed by
the OS - but you should get in the habit of doing it correctly in the
program.)

You are learning C.  That means you need to understand these things, and
practice them.  You need to get the hang of when you need to allocate
memory and when to free it, and when you can pretend that a "char *" is
a bit like a string in the sense used by other languages, and when it is
not.

You need to build up a collection of functions that you have made (or
acquired) and understand, and can re-use.  So take Bart's "allocstring"
function and keep it (though I recommend being more generous with spaces
than Bart is - make your code as readable as possible).  Don't inline it
into the rest of your code.  That is the compiler's job.

And throw out your toy compilers.  Use a /good/ compiler - clang or gcc.
 Use its features well.  Use its warnings, and its optimisations (which
enable better warnings).  Use the sanitizers - look these up in the
reference manual for the compiler.  These will often tell you when you
are doing something bad, such as memory leaks, overflows, bad
conversions, etc.  They can be a big help in learning the language and
good programming habits.


If you are not trying to learn C specifically, and just want to learn
some programming to solve these kinds of programs, then C is definitely
the wrong choice of language.  You then want a language that handles
strings, memory allocation, sorting, lists, etc., at a higher level.
For example, a Python solution for your program here can be written in a
single line function :

def gaps(ns) :
    [(s + 1, t - 1) for (s, t) in zip(ns[:-1], ns[1:]) if (t - s) > 1]

gaps([1, 2, 4, 5, 7, 12, 1300, 10000])

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

#148233

On 11/13/2019 4:52 AM, David Brown wrote:
> On 13/11/2019 05:28, DFS wrote:
> 
>>
>> I understand there "is no string type in C", but all that work to assign
>> an array of chars to an array position?
>>
> 
> The main point to understand is that there is no automatic memory
> management in C.  If you need to store things with different sizes, you
> have to allocate memory for them along the way - using malloc or related
> functions.  And you have to free the memory after use.  (In most
> systems, once the program stops all allocated memory will be freed by
> the OS - but you should get in the habit of doing it correctly in the
> program.)
> 
> You are learning C.  That means you need to understand these things, and
> practice them.  You need to get the hang of when you need to allocate
> memory and when to free it, and when you can pretend that a "char *" is
> a bit like a string in the sense used by other languages, and when it is
> not.
> 
> You need to build up a collection of functions that you have made (or
> acquired) and understand, and can re-use.  So take Bart's "allocstring"
> function and keep it (though I recommend being more generous with spaces
> than Bart is - make your code as readable as possible).  Don't inline it
> into the rest of your code.  That is the compiler's job.

I do see the reuse and 'keep main small' value of the function, but two 
lines inline vs a longer function that adds processing overhead is 
something to consider.


> And throw out your toy compilers.  Use a /good/ compiler - clang or gcc.
>   Use its features well.  Use its warnings, and its optimisations (which
> enable better warnings).  Use the sanitizers - look these up in the
> reference manual for the compiler.  These will often tell you when you
> are doing something bad, such as memory leaks, overflows, bad
> conversions, etc.  They can be a big help in learning the language and
> good programming habits.

I use tcc and gcc (both -Wall), but haven't looked into optimizations 
and sanitizers.



> If you are not trying to learn C specifically, and just want to learn
> some programming to solve these kinds of programs, then C is definitely
> the wrong choice of language.  

I wrote VBA code for years (business db systems), never looked into C or 
python until a few years ago.  I've been missing a lot.



> You then want a language that handles
> strings, memory allocation, sorting, lists, etc., at a higher level.
> For example, a Python solution for your program here can be written in a
> single line function :
> 
> def gaps(ns) :
>      [(s + 1, t - 1) for (s, t) in zip(ns[:-1], ns[1:]) if (t - s) > 1]
> 
> gaps([1, 2, 4, 5, 7, 12, 1300, 10000])


I like python.  You can write nice one-two-liners like yours.


This one combines two arrays, dedupes it, sorts it lower-case and prints

for x,itm in enumerate(sorted(list(set().union(a,b)),key=str.lower)):
   print str(x+1)+'. '+itm



A post I made here contained C and python versions of the same program. 
The python was 17 lines total, the C about 100 (and ran 9x faster).

<NNgvF.21265$hh5.17108@fx07.iad>
Sat, 2 Nov 2019 10:53:01 -0400


Thanks for the hints and advice.

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

#148235

On 13/11/2019 16:16, DFS wrote:
> On 11/13/2019 4:52 AM, David Brown wrote:
>> On 13/11/2019 05:28, DFS wrote:
>>
>>>
>>> I understand there "is no string type in C", but all that work to assign
>>> an array of chars to an array position?
>>>
>>
>> The main point to understand is that there is no automatic memory
>> management in C.  If you need to store things with different sizes, you
>> have to allocate memory for them along the way - using malloc or related
>> functions.  And you have to free the memory after use.  (In most
>> systems, once the program stops all allocated memory will be freed by
>> the OS - but you should get in the habit of doing it correctly in the
>> program.)
>>
>> You are learning C.  That means you need to understand these things, and
>> practice them.  You need to get the hang of when you need to allocate
>> memory and when to free it, and when you can pretend that a "char *" is
>> a bit like a string in the sense used by other languages, and when it is
>> not.
>>
>> You need to build up a collection of functions that you have made (or
>> acquired) and understand, and can re-use.  So take Bart's "allocstring"
>> function and keep it (though I recommend being more generous with spaces
>> than Bart is - make your code as readable as possible).  Don't inline it
>> into the rest of your code.  That is the compiler's job.
> 
> I do see the reuse and 'keep main small' value of the function, but two
> lines inline vs a longer function that adds processing overhead is
> something to consider.
> 

No, it is not.  Well, it is something to consider (and it is good that
you are considering these things), and then to reject.

First, the processing overhead of the function call is totally
negligible in most PC programs.  It becomes relevant in some kinds of
code, on some processors - but not here.  The malloc call will taken
thousands of times more processing cycles than the call/return overhead.

Secondly, if you take my advice and use a better compiler, the compiler
will make better inlining decisions than you will when optimising.
(That's not a slight on you - it makes better inlining decisions than
most of us on most code.)  This is especially true if you get in the
habit of using "static" on functions and data that are not needed
outside the current file.  (This is very much a recommended practice
anyway, regardless of efficiency.)

Thirdly, and most importantly, any efficiency issues pale in comparison
to the improved structure, readability, and re-use you get from having
separate functions here.


> 
>> And throw out your toy compilers.  Use a /good/ compiler - clang or gcc.
>>   Use its features well.  Use its warnings, and its optimisations (which
>> enable better warnings).  Use the sanitizers - look these up in the
>> reference manual for the compiler.  These will often tell you when you
>> are doing something bad, such as memory leaks, overflows, bad
>> conversions, etc.  They can be a big help in learning the language and
>> good programming habits.
> 
> I use tcc and gcc (both -Wall), but haven't looked into optimizations
> and sanitizers.
> 

Don't worry about optimisations too much at this stage - but /do/ enable
"-O1" at least, because it lets the compiler give you better warnings.
And /do/ look at sanitizers.

I'd drop tcc entirely.  It's only purpose is if you are wanting to make
highly portable code that can be compiled with many compilers, and need
people to be able to compile your code on tiny or ancient computers.
Since that is not the case, tcc is pointless here.

> 
> 
>> If you are not trying to learn C specifically, and just want to learn
>> some programming to solve these kinds of programs, then C is definitely
>> the wrong choice of language.  
> 
> I wrote VBA code for years (business db systems), never looked into C or
> python until a few years ago.  I've been missing a lot.
> 

There is a philosophy that says programming in BASIC should be banned,
as it damages programmers for life.  I disagree - it's okay as a
starting language.  But you need to remember that C is not BASIC, and
many things work differently there.  (And Python is different again.)
Different languages have their pros and cons, and are suitable for
different types of programming.

> 
> 
>> You then want a language that handles
>> strings, memory allocation, sorting, lists, etc., at a higher level.
>> For example, a Python solution for your program here can be written in a
>> single line function :
>>
>> def gaps(ns) :
>>      [(s + 1, t - 1) for (s, t) in zip(ns[:-1], ns[1:]) if (t - s) > 1]
>>
>> gaps([1, 2, 4, 5, 7, 12, 1300, 10000])
> 
> 
> I like python.  You can write nice one-two-liners like yours.
> 

You can also write massive programs as well as short ones - I do both.
It is a language that works for a wide range of programs.  But it has
little overlap with C - I usually have no problem deciding if a task is
best done in C or Python.

> 
> This one combines two arrays, dedupes it, sorts it lower-case and prints
> 
> for x,itm in enumerate(sorted(list(set().union(a,b)),key=str.lower)):
>   print str(x+1)+'. '+itm
> 
> 
> 
> A post I made here contained C and python versions of the same program.
> The python was 17 lines total, the C about 100 (and ran 9x faster).
> 
> <NNgvF.21265$hh5.17108@fx07.iad>
> Sat, 2 Nov 2019 10:53:01 -0400
> 
> 
> Thanks for the hints and advice.

You are welcome.  And don't give up!  C is tough to master - it is not a
beginners' language.  But it is worth knowing it.

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

#148222

On 13/11/2019 04:28, DFS wrote:
> On 11/12/2019 4:20 PM, Bart wrote:
>> On 12/11/2019 20:55, DFS wrote:
>>> You clc guys are masters at this stuff.
>>>
>>> Goal: Find all the open intervals in an ordered set of numbers
>>>
>>> nbrs  = [1, 2, 4, 5, 7, 12, 1300, 10000]
>>> opens = [(3, 3), (6, 6), (8, 11), (13, 1299), (1301, 9999)]
>>
>> (If already sorted, then this task is fairly trivial, just a bit 
>> fiddly. For example in my script language:
>>
>>      proc start=
>>          nbrs  := [1, 2, 4, 5, 7, 12, 1300, 10000]
>>          println -nbrs         # or inot nbrs
>>      end
>>
>> Output is:
>>
>>      [0,3,6,8..11,13..1299,1301..9999]
> 
> 
> Your language already has builtin functions to find gaps in a sequence? 
> Sweet.  Or did you just now write it?

No, it just uses bit sets (you can try this code using that 'qq' 
program). If I use this smaller example:

    [1, 2, 4, 5, 7, 12]

Then in that language that represents an array of bits like this (always 
starts from element 0, and with index shown above):

     0  1  2  3  4  5  6  7  8  9  10 11 12
    (0, 1, 1, 0, 1, 1, 0, 1, 0, 0, 0, 0, 1)

Then the bit sequence can be inverted (like using C's "~" on the bits in 
an int), to get:

     0  1  2  3  4  5  6  7  8  9  10 11 12
    (1, 0, 0, 1, 0, 0, 1, 0, 1, 1, 1, 1, 0)

If you now read out the index values of the 1s, you get:

     [0, 3, 6, 8, 9, 10, 11]

which is normally printed as (0,3,6,8..11). This is not quite what you 
want,  because yours uses an arbitrary lower bound, not zero, and you 
want all sequences to be displayed as (a,b).

But, the scanning involved to do that is little different from doing it 
on the original data, so there is little point in doing this in C. It 
would also lot more memory for sequences like [1,2, 10 000000, 10001000] 
(ie. about 1.25MB here).

The advantage of this kind of representation is that if S is your 
original set, then 'N in S' returns 0 when N is within one of your 
'open' intervals (or 1 using 'N in -S'), in O(1) time. But it would need 
a lower bound adjustment.


> Is there a faster/better way (you mentioned bit-arrays - what does that 
> code look like?  Seems complicated.  Why would you use such a thing to 
> find these intervals?

See above. The answer depends on what you plan on doing with the 
results. But given data like (1, 2, 4, 5, 7, 12, 1300, 10000) you will 
always have to start by 'visiting' each element anyway. To just build a 
list of gaps, that might be all that's needed.

 >>nbrs  = [1, 2, 4, 5, 7, 12, 1300, 10000]
>>
> 
>>>    char *intervals[sizeof(char*) * lenNums];
>>
>> Use char ** here; see below.
> 
> That created a couple warnings:
> 
> getintervals.c:38:22: warning: assignment to ‘char **’ from incompatible 
> pointer type ‘char *’ [-Wincompatible-pointer-types]
>     38 |         intervals[x] = str;
>        |                      ^
> getintervals.c:46:12: warning: format ‘%s’ expects argument of type 
> ‘char *’, but argument 2 has type ‘char **’ [-Wformat=]
>     46 |   printf("%s ",intervals[i]);
>        |           ~^   ~~~~~~~~~~~~
>        |            |            |
>        |            char *       char **

What options did you use? I go no warnings from 'gcc -Wall -Wpedantic 
-Wextra' on the C code here:

    https://github.com/sal55/langs/blob/master/intervals.c

> OK.  But outside fn() not strictly needed, so I did it in the loop, like 
> so:
> 
> 
> char interval[30];                         //set size to accomodate
>                                               large range
> char *intervals[sizeof(char*) * lenNums];  //no pointer to pointer
> 
> loop
>   sprintf(interval,"[%d,%d]",start,end);
>   char *str=malloc(strlen(interval)+1);
>   strcpy(str,interval);
>   intervals[x] = str;
> 
> It compiles and works - please tell me there's nothing wrong there.

That's fine. But you might need this often enough that having it in a 
function is convenient. It also offers only one opportunity for typos 
instead of each time you write it. You don't need that 'str' variable in 
the main code. You can choose to put in a malloc failure check which 
would be too messy in the main code. It doesn't clutter up your main code...


> 
> 
> I understand there "is no string type in C", but all that work to assign 
> an array of chars to an array position?
> 
> Since I already sized the array up front and set interval to the correct 
> value...
> 
> char *intervals[sizeof(char*) * lenNums];
> sprintf(interval,"[%d,%d]",start,end);
> 
> ... what's the use of having to create the temp/working variable, 
> copying what's in interval to temp, then assigning the temp to the 
> array?  The space is already allocated and the string is correctly set.
> 
> Either one of these /should/ work, but somebody's cruel:
> 
> sprintf(interval,"[%d,%d]",start,end);
> strcpy(intervals[x],interval);
> 
> or
> 
> sprintf(interval,"[%d,%d]",start,end);
> intervals[x] = interval;


Use intervals[x]=allocstring(interval) as in my version, and you pretty 
much have that!

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

#147978

DFS <nospam@dfs.com> writes:

> You clc guys are masters at this stuff.
>
> Goal: Find all the open intervals in an ordered set of numbers
>
> nbrs  = [1, 2, 4, 5, 7, 12, 1300, 10000]
> opens = [(3, 3), (6, 6), (8, 11), (13, 1299), (1301, 9999)]
>
> I think 'open intervals' is the right terminology.

Not really.  The open interval (3, 3) contains no integers where as the
closed interval [3, 3] contains exactly one integer: 3.

  void print_gaps(int n, const int *data)
  {
       if (n > 1) {
            if (data[0] + 1 < data[1])
                 printf(" (%d, %d)", data[0] + 1, data[1] - 1);
            print_gaps(n - 1, data + 1);
       }
  }

To test drive it I used:

  int main(int argc, char **argv)
  {
       if (argc > 1) {
            int seq[argc-1];
            for (int a = 1; a < argc; a++)
                 seq[a-1] = atoi(argv[a]);
            print_gaps(argc-1, seq);
            putchar('\n');
       }
  }

-- 
Ben.

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

#147982

On 15/11/2019 00:27, Bart wrote:
> On 14/11/2019 09:01, David Brown wrote:
> 
>> gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare -O2
> 
>> There we go.  gcc has found your bug.
> 
> Except it might be interspersed with 1000 other warnings, most of which
> are irrelevant. Note this won't work when the array bound is a variable,
> as it usually is.

If you use -Werror from day one, you'll never end up with 1000 other 
warnings.

>> So (still pretending we did not see the warning from gcc showing the
>> problem), we know something is wrong - but we don't know what.  That is
>> where sanitizers come in:
>>
>> gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare -O2 -fsanitize=undefined
> 
> I get 'cannot find -lubsan', on Windows.

Doctor, it hurts when I do this.  Then don't do that!

You keep struggling (or at least pretending to struggle) with a broken 
environment when the sensible thing to do is dump it.

-- 
Ian.

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

#147984

On 14/11/2019 16:12, Ian Collins wrote:
> On 15/11/2019 00:27, Bart wrote:

>> I get 'cannot find -lubsan', on Windows.
> 
> Doctor, it hurts when I do this.  Then don't do that!


> You keep struggling (or at least pretending to struggle) with a broken 
> environment when the sensible thing to do is dump it.

What do you mean by a broken environment?

Windows? I've used it for 25 years; it's fine. Unless you've grown 
over-dependent on Linux systems and need all the extra hand-holding.

gcc? Yes, probably. Certainly, the failure of that option to work 
because it can't find -lubsan, which I'd never heard of, is hardly my 
fault. Nor is it not Windows'.

As I said, when I finally tried -lubsan, it couldn't detect a bounds 
array anyway, in the circumstances in which an array is most often used.

No doubt there are yet more options that can be piled on, but then you 
have to start questioning what you are doing, and what proportion of 
effort should be put into getting temperamental tools to work which can 
only detect some classes of software issues anyway.

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

#148005

On 15/11/2019 05:34, Bart wrote:
> On 14/11/2019 16:12, Ian Collins wrote:
>> On 15/11/2019 00:27, Bart wrote:
> 
>>> I get 'cannot find -lubsan', on Windows.
>>
>> Doctor, it hurts when I do this.  Then don't do that!
> 
> 
>> You keep struggling (or at least pretending to struggle) with a broken
>> environment when the sensible thing to do is dump it.
> 
> What do you mean by a broken environment?

You are continuously whinging about incomplete compiler installations 
(especially clang), old or missing libraries and on and on.

> Windows? I've used it for 25 years; it's fine. Unless you've grown
> over-dependent on Linux systems and need all the extra hand-holding.

There you go again, introducing unnecessary asides into a thread.  If by 
"hand-holding" you mean working package management then I'm all for it. 
You will find working package management on just about any platform 
other than windows, so it isn't a Linux thing at all.

If you want a working development environment on Windows do what we do 
at work, just install Windows Subsystem for Linux (WSL) and you'll have 
the best of both worlds on a single machine.  No more faffing around 
with cygwnin, mingw or other compromises.  I'll even give you the link 
so you can't plead ignorance:

https://docs.microsoft.com/en-us/windows/wsl/install-win10

-- 
Ian.

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

#148008

On 14/11/2019 21:07, Ian Collins wrote:
> On 15/11/2019 05:34, Bart wrote:

>>
>> What do you mean by a broken environment?
> 
> You are continuously whinging about incomplete compiler installations 
> (especially clang), old or missing libraries and on and on.

I just say that they don't work. Why they don't work, I don't want to 
get in to. clang used to work, but now it doesn't for whatever reason. 
(But before it stopped, it was turning all warnings on by default, 
making it hopeless for my generated code.)

I stick with stuff that I know works, is reliable, practical and repeatable.

With gcc, all I need is for this to work:

   gcc prog.c -oprog.exe
   gcc prog.c -oprog -lm -ldl

Possibly with -O3 or -m64. Sometimes, I need it to do this:

   gcc -shared prog.obj -oprog.dll

In other words, the basics necessary to get from source to executable.

>> Windows? I've used it for 25 years; it's fine. Unless you've grown
>> over-dependent on Linux systems and need all the extra hand-holding.
> 
> There you go again, introducing unnecessary asides into a thread.  If by 
> "hand-holding" you mean working package management then I'm all for it. 

I mean compiler options among other things, like over-elaborate make 
systems.

> You will find working package management on just about any platform 
> other than windows, so it isn't a Linux thing at all.
> 
> If you want a working development environment on Windows do what we do 
> at work, just install Windows Subsystem for Linux (WSL) and you'll have 
> the best of both worlds on a single machine.  No more faffing around 
> with cygwnin, mingw or other compromises.  I'll even give you the link 
> so you can't plead ignorance:
> 
> https://docs.microsoft.com/en-us/windows/wsl/install-win10

(My main machine is Windows 7.)

You don't seem to get that I don't WANT to use that stuff at all. I'm 
working to minimise or eliminate that boilerplate, which not mean just 
burying it under more layers.

Here's one recent experiment, which is not quite there because I'm just 
starting to use external, installable libraries that have different 
names between Windows and Linux.

Take these three source files (download them to the same place):

   https://raw.githubusercontent.com/sal55/langs/master/mu64.c (big)
   https://raw.githubusercontent.com/sal55/langs/master/stars.m
   https://raw.githubusercontent.com/sal55/langs/master/opengl.m

On Linux-64, compile the first as:

   gcc mu64.c -omu -lm -ldl

This is a compiler for the other two .m files, which generates C code 
then invokes a compiler.

These files are an OpenGL demo (not mine; converted from a C example I 
found). I kept them separate as you don't like things in the same file.

Build this demo program like this:

   ./mu stars

(It has a dependency on libraries glut, GL and GLU; if not present then 
don't bother, and if it doesn't work then forget it.)

If it works, then that should be it; run it as ./stars.

You've build my entire whole-program compiler in one compiler 
invocation. And built an OpenGL application in one invocation of that 
compiler with the only input being one source module file.

As I said, I'm not interested in any of your tools! Only the basics.

(The issue I mentioned is to do with the 'cclib' line inside stars.m; 
the details are different between Windows and Linux. It is not anyway a 
detail that anyone building such programs needs to worry about.)

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

#148011

On 15/11/2019 11:25, Bart wrote:
> On 14/11/2019 21:07, Ian Collins wrote:
>> On 15/11/2019 05:34, Bart wrote:
> 
>>>
>>> What do you mean by a broken environment?
>>
>> You are continuously whinging about incomplete compiler installations
>> (especially clang), old or missing libraries and on and on.
> 
> I just say that they don't work. Why they don't work, I don't want to
> get in to. clang used to work, but now it doesn't for whatever reason.
> (But before it stopped, it was turning all warnings on by default,
> making it hopeless for my generated code.)
> 
> I stick with stuff that I know works, is reliable, practical and repeatable.
> 
> With gcc, all I need is for this to work:
> 
>     gcc prog.c -oprog.exe
>     gcc prog.c -oprog -lm -ldl
> 
> Possibly with -O3 or -m64. Sometimes, I need it to do this:
> 
>     gcc -shared prog.obj -oprog.dll
> 
> In other words, the basics necessary to get from source to executable.
> 
>>> Windows? I've used it for 25 years; it's fine. Unless you've grown
>>> over-dependent on Linux systems and need all the extra hand-holding.
>>
>> There you go again, introducing unnecessary asides into a thread.  If by
>> "hand-holding" you mean working package management then I'm all for it.
> 
> I mean compiler options among other things, like over-elaborate make
> systems.
> 
>> You will find working package management on just about any platform
>> other than windows, so it isn't a Linux thing at all.
>>
>> If you want a working development environment on Windows do what we do
>> at work, just install Windows Subsystem for Linux (WSL) and you'll have
>> the best of both worlds on a single machine.  No more faffing around
>> with cygwnin, mingw or other compromises.  I'll even give you the link
>> so you can't plead ignorance:
>>
>> https://docs.microsoft.com/en-us/windows/wsl/install-win10
> 
> (My main machine is Windows 7.)

That explains a lot...  You do realise that it will turn into a pumpkin 
in a couple of months on 14/01/20?

-- 
Ian.

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

#148012

On 14/11/2019 23:02, Ian Collins wrote:
> On 15/11/2019 11:25, Bart wrote:

>> (My main machine is Windows 7.)
> 
> That explains a lot...

Sorry, it explains what? Why do you guys get so hot and bothered about 
operating systems? If you told me what OS and version /you/ had, it 
would mean nothing to me and I wouldn't care anyway.

For programming, I need little more than a functioning file system (and 
I've managed without one as well).

>  You do realise that it will turn into a pumpkin 
> in a couple of months on 14/01/20?

I'd still be using XP if the hardware that ran it hadn't packed up. I'm 
one of those people who really don't care.

So, what happens on 14th Jan, no more upgrades? If only!

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

#148017

On 15/11/2019 12:27, Bart wrote:
> On 14/11/2019 23:02, Ian Collins wrote:
>> On 15/11/2019 11:25, Bart wrote:
> 
>>> (My main machine is Windows 7.)
>>
>> That explains a lot...
> 
> Sorry, it explains what? 

Why you hot some many problems.  More modern Windows is a much better 
environment.

>>    You do realise that it will turn into a pumpkin
>> in a couple of months on 14/01/20?
> 
> I'd still be using XP if the hardware that ran it hadn't packed up. I'm
> one of those people who really don't care.
> 
> So, what happens on 14th Jan, no more upgrades? If only!

Unless you cough up $$$ for extended support, yes.

-- 
Ian.

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

#148023

On 15/11/2019 06:06, Ian Collins wrote:
> On 15/11/2019 12:27, Bart wrote:
>> On 14/11/2019 23:02, Ian Collins wrote:
>>> On 15/11/2019 11:25, Bart wrote:
>>
>>>> (My main machine is Windows 7.)
>>>
>>> That explains a lot...
>>
>> Sorry, it explains what? 
> 
> Why you [hit so] many problems.  More modern Windows is a much better 
> environment.

The problems occur trying to emulate or import Linux with all its 
multitudinous systems and utilities that your and others' software 
development seems to depend on.

I on the other hand have never got in to any of that. I'm used to 
development with zero or minimal other software to help out, and 
therefore used to being self-sufficient.

I think that is still a useful trait now, when you look at what people 
seem to need to build the simplest application.

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

#148026

On 15/11/2019 11:45, Bart wrote:
> On 15/11/2019 06:06, Ian Collins wrote:
>> On 15/11/2019 12:27, Bart wrote:
>>> On 14/11/2019 23:02, Ian Collins wrote:
>>>> On 15/11/2019 11:25, Bart wrote:
>>>
>>>>> (My main machine is Windows 7.)
>>>>
>>>> That explains a lot...
>>>
>>> Sorry, it explains what? 
>>
>> Why you [hit so] many problems.  More modern Windows is a much better
>> environment.
> 
> The problems occur trying to emulate or import Linux with all its
> multitudinous systems and utilities that your and others' software
> development seems to depend on.
> 
> I on the other hand have never got in to any of that. I'm used to
> development with zero or minimal other software to help out, and
> therefore used to being self-sufficient.
> 
> I think that is still a useful trait now, when you look at what people
> seem to need to build the simplest application.
> 

Do you complain that people use screws when putting up shelves?  After
all, they rely on such complicated and difficult to use tools as
"screwdrivers" - and it doesn't work well when you try to bash them in
with your rock.  And some people even use /electric/ screwdrivers - how
ridiculous is that, using something that makes them more productive and
makes their lives easier?  You tried it once, but couldn't figure out
how to charge the batteries and resorted to bashing in the screws with
the handle of the electric screwdriver.  That was even worse than your
rock, proving that everyone else is wrong to use these "screw" thingies.

We get it.  You like your rocks.  You don't like complicated
screwdrivers, and are totally baffled by electric tools.  Maybe that
means you'd survive a nuclear war or zombie apocalypse better than the
rest of us.  In the meantime, let others use proper tools without
whining about your own troubles yet again.

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

#148027

On 15/11/2019 12:28, David Brown wrote:
> On 15/11/2019 11:45, Bart wrote:
>> On 15/11/2019 06:06, Ian Collins wrote:
>>> On 15/11/2019 12:27, Bart wrote:
>>>> On 14/11/2019 23:02, Ian Collins wrote:
>>>>> On 15/11/2019 11:25, Bart wrote:
>>>>
>>>>>> (My main machine is Windows 7.)
>>>>>
>>>>> That explains a lot...
>>>>
>>>> Sorry, it explains what?
>>>
>>> Why you [hit so] many problems.  More modern Windows is a much better
>>> environment.
>>
>> The problems occur trying to emulate or import Linux with all its
>> multitudinous systems and utilities that your and others' software
>> development seems to depend on.
>>
>> I on the other hand have never got in to any of that. I'm used to
>> development with zero or minimal other software to help out, and
>> therefore used to being self-sufficient.
>>
>> I think that is still a useful trait now, when you look at what people
>> seem to need to build the simplest application.
>>
> 
> Do you complain that people use screws when putting up shelves?  After
> all, they rely on such complicated and difficult to use tools as
> "screwdrivers" - and it doesn't work well when you try to bash them in
> with your rock.  And some people even use /electric/ screwdrivers - how
> ridiculous is that, using something that makes them more productive and
> makes their lives easier?  You tried it once, but couldn't figure out
> how to charge the batteries and resorted to bashing in the screws with
> the handle of the electric screwdriver.  That was even worse than your
> rock, proving that everyone else is wrong to use these "screw" thingies.
> 
> We get it.  You like your rocks.  You don't like complicated
> screwdrivers, and are totally baffled by electric tools.  Maybe that
> means you'd survive a nuclear war or zombie apocalypse better than the
> rest of us.  In the meantime, let others use proper tools without
> whining about your own troubles yet again.

You like your tools, I like mine let's leave it at that.

There are advantages and disadvantages to yours, and the same for mine.

To take the analogy of the electric screwdriver, bear in mind that I 
create my own - considerably faster, smaller and lighter than yours.

Your one wouldn't be just a screwdriver, but come with its own team of 
inspectors that check and double check every single thing you do against 
a set of standards, and won't pass your efforts unless it's absolutely 
perfect.

Sod that.

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

#148028

On 15/11/2019 13:58, Bart wrote:

> You like your tools, I like mine let's leave it at that.
> 

If you can leave it at that, then fair enough.  Stop spreading your fud,
lies, exaggerations, and incompetence when other people are discussing
other tools.  If there is a discussion about good tools to aid C
development, and good software development processes, then please do not
join in and cause irritation and confusion just because /you/ can't
cope.  When people are asking for limited but tiny and fast tools, or
about how to make a simple C compiler, or about private languages, then
of course it makes sense to talk about your own tools.

It gets really annoying that whenever there is a thread or branch
discussing tools, and ways to make developers' lives easier (whether
they are beginners or serious developers), we /always/ have to fight
your posts telling people how difficult it all is, why C is so terrible,
how unfair it is that others can use compilers and build systems that
are beyond your understanding, and how fantastic you find it to save
milliseconds on compile times.

If you were selling your compilers and your languages, I could
understand where you are coming from.  As it is, the only motivation I
can think of is that you write to bug people.

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

#148030

On 15/11/2019 14:39, David Brown wrote:
> On 15/11/2019 13:58, Bart wrote:
> 
>> You like your tools, I like mine let's leave it at that.
>>
> 
> If you can leave it at that, then fair enough.  Stop spreading your fud,
> lies, exaggerations, and incompetence when other people are discussing
> other tools.  If there is a discussion about good tools to aid C
> development, and good software development processes, then please do not
> join in and cause irritation and confusion just because /you/ can't
> cope.  When people are asking for limited but tiny and fast tools, or
> about how to make a simple C compiler, or about private languages, then
> of course it makes sense to talk about your own tools.
> 
> It gets really annoying that whenever there is a thread or branch
> discussing tools, and ways to make developers' lives easier

It wouldn't make /my/ life easier.

/I/ find it annoying that if I'm having trouble building some open 
source program on Windows, the suggestions that are made involve using 
WSL; or MSYS2, or CYGWIN; or give up on that POS OS and use a real one 
like Linux. Or I get insulted as to my capabilities.

Anything other than attempt to make the process simple and reliable 
enough that it can just be built anywhere without fuss, and without 
trying to turn my environment upside-down trying to match the 
developers' build systems rather than the other way around.

Maybe my examples of how I think finished open sources can be made more 
simply available can inspire others. Rather than we all sink deeper into 
a mire of ever-more elaborate build systems and wider and wider 
dependencies.


  (whether
> they are beginners or serious developers), we /always/ have to fight
> your posts telling people how difficult it all is, why C is so terrible,
> how unfair it is that others can use compilers and build systems that
> are beyond your understanding, and how fantastic you find it to save
> milliseconds on compile times.

Do you have an example of my telling a beginner what tools to use or not 
use?

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web