Author Topic: Comparing source files  (Read 2785 times)

0 Members and 1 Guest are viewing this topic.

Online DiTBho

  • Super Contributor
  • ***
  • Posts: 3995
  • Country: gb
Re: Comparing source files
« Reply #25 on: March 29, 2024, 12:58:20 pm »
That's an interesting approach, although obviously quite different. As I understand it, you could have two "completely" different source files, if the corresponding ASTs are the same, it would show no difference.

it only works with "my-c" sources, refuses "c" sources, and the first thing it chckes is the "level", so it can only compares
Code: [Select]
{
   { source0:level0, source1:level0 } <--------- this is 90% compatible with C/89, but not 100%
   { source0:level1, source1:level1 }
   { source0:level2, source1:level2 }
   { source0:level3, source1:level3 }
}

It would then miss any code style difference, comments, etc.

Yup, this is a defect. There must be Only one style.

To reduce the things I have to develop, I forced only one style, which is imposed to the user, and whatever the user writes (spaces, tabs, personal indentation), the tool always re-formats the source with the imposed style.

Comments are special-cases. A comment is recognized as "token_comment", managed as block, and its context is handled by the traditional diff algorithm, including CR.

Tabs are not allowed, and automatically converted into 4 spaces, as well as CR LF are automatically converted into CR LF (DOS --> Unix)
So, comments keep CRs LFs, you can see differences between the same comment, e.g. { typos fixed, more details added &| removed, ... } in two different sources.

edit:
fixed
« Last Edit: March 31, 2024, 06:56:10 am by DiTBho »
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Online cfbsoftware

  • Regular Contributor
  • *
  • Posts: 118
  • Country: au
    • Astrobe: Oberon IDE for Cortex-M and FPGA Development
Re: Comparing source files
« Reply #26 on: March 30, 2024, 07:43:30 pm »
CR LF are automatically converted into CR (DOS --> Unix)
Shouldn't that be:
Quote
CR LF are automatically converted into LF (DOS --> Unix)
Chris Burrows
CFB Software
https://www.astrobe.com
 
The following users thanked this post: DiTBho

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6471
  • Country: fi
    • My home page and email address
Re: Comparing source files
« Reply #27 on: March 30, 2024, 09:03:40 pm »
Yup.  The four newline conventions, listed by the most well-known OSes that used them:
  • LF ("\n"): Unix, BSDs, Linux, Android, OS X.
     
  • CR ("\r"): Old Mac OS prior to X.
     
  • CR LF ("\r\n"): DOS, Windows.
     
  • LF CR ("\n\r"): An error, but invisible on most systems, behaving like a normal newline, and is thus occasionally encountered in the wild.  Can also occur in Unix/BSD/Linux/etc. systems when using tty devices (terminals, serial ports) with termios INLCR and ICRNL set on input with the other side using CR LF newlines.
My own conception for "universal newlines" is supporting any mix of the four, optionally with NUL ("\0") also considered a newline.
 
The following users thanked this post: DiTBho

Online Picuino

  • Super Contributor
  • ***
  • Posts: 1002
  • Country: es
    • Picuino web
Re: Comparing source files
« Reply #28 on: March 30, 2024, 09:24:58 pm »
+1 for Beyond Compare.
There are versions for Win, Mac and Linux, and with trial versions.
https://www.scootersoftware.com/download
« Last Edit: March 30, 2024, 09:26:34 pm by Picuino »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14711
  • Country: fr
Re: Comparing source files
« Reply #29 on: March 30, 2024, 09:53:58 pm »
Yup.  The four newline conventions, listed by the most well-known OSes that used them:
  • LF ("\n"): Unix, BSDs, Linux, Android, OS X.
     
  • CR ("\r"): Old Mac OS prior to X.
     
  • CR LF ("\r\n"): DOS, Windows.
     
  • LF CR ("\n\r"): An error, but invisible on most systems, behaving like a normal newline, and is thus occasionally encountered in the wild.  Can also occur in Unix/BSD/Linux/etc. systems when using tty devices (terminals, serial ports) with termios INLCR and ICRNL set on input with the other side using CR LF newlines.
My own conception for "universal newlines" is supporting any mix of the four, optionally with NUL ("\0") also considered a newline.

Yes.
 
The following users thanked this post: DiTBho

Online DiTBho

  • Super Contributor
  • ***
  • Posts: 3995
  • Country: gb
Re: Comparing source files
« Reply #30 on: March 31, 2024, 06:48:13 am »
Fixed  :-+

LF CR ("\n\r"): An error, but invisible on most systems, behaving like a normal newline, and is thus occasionally encountered in the wild.  Can also occur in Unix/BSD/Linux/etc. systems when using tty devices (terminals, serial ports) with termios INLCR and ICRNL set on input with the other side using CR LF newlines.



umm, speaking of being invisible, I never noticed it on the DEC VT525(1994) hardware terminal with /usr/bin/screen on /dev/ttyS0
it shouldn't have worked  :-//
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6471
  • Country: fi
    • My home page and email address
Re: Comparing source files
« Reply #31 on: March 31, 2024, 08:48:57 pm »
LFCR "\n\r" works on Unix, BSD/Linux/etc., and VT terminals because while LF "\n" is a full newline, CR "\r" only returns the cursor to the beginning of the current line.  Thus, the effect of LF CR "\n\r" is exactly the same as LF "\n" only.  Invisible, like I said!

This is often exploited by POSIXy command-line programs that report progress using e.g.
    fprintf(stderr, "\r%.2f%% done", 100.0*i/n);
    fflush(stderr);  // Optional; normally/by default, this is not needed
followed by
    fprintf(stderr, "\r                   \r"); // or "\r\022[K"
    fflush(stderr);  // Optional; normally/by default, this is not needed
where "\033[K" (or "\e[K" where \e represents ASCII/ISO Latin/UTF-8 code 27 = 0x1B = ESC) is the ANSI Control Sequence for clearing the current line from the current cursor position to the end of the line without moving the cursor, when the maximum number of characters needed to "erase" the progress output is unknown.

If the progress is reported to standard output, or there is more information printed to standard error that may have been redirected to a file, often the followup is just a simple fprintf(stderr, "\n"); or fprintf(stderr, "\rCompleted.     \n");, as that way the progress information will look like a single line in the file, but won't otherwise mess up the output.
« Last Edit: March 31, 2024, 08:51:07 pm by Nominal Animal »
 
The following users thanked this post: DiTBho

Offline dobsonr741

  • Frequent Contributor
  • **
  • Posts: 687
  • Country: us
Re: Comparing source files
« Reply #32 on: April 03, 2024, 04:24:05 am »
Araxis Merge. They are in this business was for a long time, and for a reason.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf