OpenXTalk Forums

I'm hoping someone can help with this:
I'm looking at the "DiffCompare" command in OXT.

Compare two strings, producing a string representing the changes between them in unified-diff format.

Obvious question: What is "unified-diff format"?
How do I interpret it?

According to ChatGPT:

Explanation of @@ -1,2 +1,2 @@
@@: This indicates the start of a chunk of differences.
-1,2: This means the changes start at line 1 in the first file and include 2 lines.
+1,2: This means the changes start at line 1 in the second file and include 2 lines.

Which is incorrect. It's only line 2 that changes

This is how AI thinks gymnastics works:
https://youtu.be/YwJIYj3hPAU

For the straight dope on tech subjects I often start with Wikipedia:
https://en.m.wikipedia.org/wiki/Diff#Unified_format

That illustrates perfectly why nobody should rely on AI in it's current form.
It's pretty freaky. (Reminds me of Dead Space and the "Necromorphs" with limbs flailing around for some reason)

Here's another example (I don't think it can replace humans just yet)

The wiki article lost me when it started mentioning "hunks" - surely they mean "chunks?" - but is ultimately not clear.
(I just want a one-liner explanation)

I'm just after a quick explanation, not an essay - but this is always the issue (and I'm no doubt the problem as I'm the common denominator) - perhaps I unreasonably expect things to be logical?

From what I can grasp, the - is supposed to show a line to delete, the + shows a line to add.
I was hoping to see something along the lines of (change: word 4 of line 2), and (add: word 9 and 10 to line 2), but no such luck.
Perhaps I'll have to write my own that makes sense?

After a bit of head scratching, my diff stack now produces this (it's the bare-bones of what I want). I'll likely whittle it down further to find word differences on each line. (I was trying to confuse it)
Does this work? Can anyone else suggest any changes or see an error in the logic of my function?

You might ask why I'm doing this?
(if you were thinking of Github - you'd be right)... I'm doing this to make my own changes-tracker to script in OXT Lite. The idea is this will be a user friendly github, but without the github part
OXT Lite will be able to look at everyone's proposed changes, identifiy what has stayed the same, and what has changed - and we (the community) can either "allow that change through" or "block that change", or "roll back the change" to the last version.

It's quite a lot to implement, but the key is getting this compare function to be human-readable and working reliably.
From there, the rest I think is possible.

Earlier, I mentioned that OXT lite wouldn't have loads of new features, and is more a bug fix release. However, I think that this function is needed if OXT Lite is going to ever be maintained or improved by multiple people (rather than just me). Because I have this (hatred is perhaps too strong a word... maybe indifference, or replusion?) to Github - I'll create my own that works for our purposes.

The nice thing about that is of course, it'll be aware of content inside .rev, .livecode, .livecodescript, and .oxtstack file types (which Github is not).
Does anyone have any objections to this? I currently imagine this being a preference (like "Developer Mode") that you can turn on. (It'll be off as default though). I think I'll also have to implement something like 'flood control' to stop a dDOS attack with only so many script change submissions allowed within a certain timeframe. It does also open it up to abuse though, so I'll need to carefully consider the details of how this is implemented. There also needs to be plenty of warnings along the lines of "you accept full responsibility for running script from potentially unknown sources on your computer"... or something like that. Just so we can't be blamed for someone running unverified code that hasn't been approved. That might also require a bit of careful contemplation.

But I think it's an important feature to add nonetheless, so that we can truly have a collaborative effort. I'm sure a lot more progress would be made, (and faster) - if everyone who comes here could test changes and submit them for review in an easier manner. Just the finer nuances of it need to be worked out beforehand.

So, next step is to check it can process differences in files... (which it can)

This is me opening a copy of the revanswerdialog.rev stack and comparing with the one loaded into the IDE currently.

So now to go about making the whole thing user-friendly, with a nice UI... (and making the compare faster when you are dealing with a script over 3400 lines long).

The diffCompare() function isn't documented very well, but it looks like it's intended to be used with the diffPatch() function:
get diffCompare(tOriginal,tChanged); put diffPatch(tOriginal,it) --returns original with changes

diffCompare() has a 3rd parameter that appears optional, indicating the number of unchanges lines to include before and after changes.
diffPatch() really seems like it's just returning tChanged. I don't get the point, unless maybe tChanged is unknown.

I don't think this is what you wanted for script version control. Your stack idea is also problematic, for example inserting a single blank line changes all the line numbering. You've put a lot of work into it though, so I don't want to discourage you, if it works good for you to make script changes easier. A script change usually isn't more than ten contiguous lines, so maybe it would be easiest for people to submit:
Description of reason for change.
In script of stack "revMenuBar", @line 356
change:
xxxxxxx
to:
yyyyyyy

Don't worry - I've not gone too much further with it after posting this last update.
Purely because of this reason - I didn't want to race off on a tangent, only to find that this was a bit null and void.

I'm still at the point where all suggestions are welcome.
Perhaps having a 'ticket-style' submission system would work better, where people select which lines they have changed and can 'post' that with a button within the IDE. Then when another user opens the IDe with 'Developer Community mode' turned on (that name isn't set in stone either ), then it'll notify them that there have been community changes to some stacks, and 'would you like to review each change?'. That might make more sense.

Thanks for the feedback though as this is the point of these posts. I don't want to go off and implement something that everyone else isn't happy with. Particularly if there's a better or more logical way to do it.

The problem about 'Community Editing' is that while an IDE might be downloadable containing, say, "Richmond's Crap" and a button/flag to let downloaders know that, they may be unaware of how those changes affect the functionality of the IDE, AND how, if they don't like those changes in the functionality they can revert to an earlier state of the IDE without those changes.

This is why I hope there can be a way for users to prepare MODULES that can implement changes they want to effect rather than editing the 'core' files of the IDE.

I guess in this instance, the stacks themselves are the modules. The bits that casual users can edit to make their own and do what they want.
I get what you mean about changing the core IDE and related files - I don't want it to be possible for people to just accept changes, then find the IDE no longer opens (or worse, becomes a vehicle for malware delivery).

This is why each change has to be vetted by the community first, or even a select few members, so they can test it out and 'allow the change' forward if need be. Still undecided the best way to do all this, but I do know it's got to be an easier process than github's. As mentioned, the fact that github can't read livecode, rev, or oxtstack files is a bit of an obvious reason why we also need something developed in house that is better suited to our efforts here.

I assumed 'unified diff' format is the one used by diff command-line tool

https://www.gnu.org/software/diffutils/ ... ified.html

tperry2x wrote: ↑Thu Aug 08, 2024 10:14 am the fact that github can't read livecode, rev, or oxtstack files is a bit of an obvious reason why we also need something developed in house that is better suited to our efforts here.

No pre-existing version control system is around is going to read any binary file that's unknown to it, so I get what you mean about 'in-house'. This is why the LC team did a lot of 'refactoring' to split away stacks code out to attachable behaviors scripts that are version control systems friendly and a separate binary stack that contained only the UI elements mostly. Some (unencrypted) stack files can mostly contain ascii text of script.

I agree with Richmond's comment too, tPerry and Paul should be the ones making proposed changes to IDE.

While on the topic of the dictionary database (text and/or SQLite), in addition to diffCompare() it could also be updated for $_GET_BINARY and the other '$' entries with two "_" chars from my post here:
viewtopic.php?p=9830#p9830