Copying scripts to text file

[marksmithhfx]

Are there any utilities around for copying all of the scripts to a text file, for documentation purposes or using in "compare" exercises?

[richmond62]

Dunno: I just open the scriptEditor, do select all and then copy-paste.

Of course, if you really want to spend the extra time, you can copy the script into a textField and export that to a Text or RTF document.

[dunbarx]

I have done this in the past. I wrote a simple gadget that (pseudo)

Code: Select all

repeat with y = 1 to the number of cds
put the script of cd y after scriptLog
  repeat with x = 1 to the number of controls of cd y
    put the script of control x of cd y after scriptLog
    
  --  and then
  put the script of this stack after scriptLog
  
 -- and then
  get going on any substacks

You get the picture, as Klaus would say. You can also include the names of the objects as you go down the list.

Craig

[kdjanz]

Script Tracker by Brian Milby on the forum here takes all of the scripts from any stack and puts them in text files so that you can use Git or whatever to track them or edit them externally. An essential piece of software for me.

https://github.com/bwmilby/scriptTracker

Thanks again Brian!

[FourthWorld]

Can you tell us more about the goals you're looking to serve with such a tool?

[richmond62]

I'd start a bit like this:
-

[FourthWorld]

Yeah, dumping scripts isn't the hard part. I used to have a habit of writing a script dumper with each new xTalk I picked up. But I stopped doing that when I noticed I never actually did any meaningful work with the output.

More recently I've identified a set it needs related to version comparison, and have begun the harder task of understanding needs so that the tool that emerges from this process is one I'll actually use.

My question for the OP is goal-focused for that reason. As with many things in life, implementation can become trivial once goals are well understood.

[richmond62]

Yeah, dumping scripts isn't the hard part.

Yeah, my posting was meant to be mildly sarcastic.

[richmond62]

using in "compare" exercises

Not clear if the OP is a teacher, but could be as 'compare and contrast' exercises are something of an obsession in certain areas.
-

[FourthWorld]

Yeah, the possibilities for guessing are nearly endless.

I'm eager to hear what Mark has to say.

[marksmithhfx]

Can you tell us more about the goals you're looking to serve with such a tool?

Yeah, recently someone sent me some hacks to my program, but with little information provided and no "in code" identification I couldn't find them. So I was looking for a quick way to compare the two versions to see if in fact the program sent back was the same one I sent out , or if not, then at least ID where the changes are. The suggestion made by kdjanz looks interesting because i probably should get more into git for version control reasons and this might be a good foot in the door.

PS sounds like your new planned tool would do the trick Richard.

[marksmithhfx]

Script Tracker by Brian Milby on the forum here takes all of the scripts from any stack and puts them in text files so that you can use Git or whatever to track them or edit them externally. An essential piece of software for me.

https://github.com/bwmilby/scriptTracker

Thanks again Brian!

Thanks KD, and hello to a fellow Canadian. This sounds a bit more involved than I was hoping for, but, also sounds like a good opportunity to get my feet wet with Git for the old version control. Currently on folder 111 for this program

[FourthWorld]

Thanks, Mark. Yes, it seems we both need the same tool.

GitHub is a wonderful system, as was Sourceforge before it and whatever will inevitably replace it in the future.

When an org has dependency on one specific tool over others, the others must be adapted to conform to the expectations/limitations of the main dependency.

The tooling available in our community for deconstructing/reconstructing LC's native format to and from GitHub-required formats have been a godsend for such teams.

But not all teams have that specific dependency.

I work with many professional devs who are drawn to LC because of the flexibility to bind code, UI, and even data into compact single files in nearly infinite ways based on the needs of a given project.

For them, adding deconstruction/reconstruction to their workflows breaks their stride, understandably given that it goes against the grain of The xTalk Way.

Exploring this last year,I noticed that the team quietly added a key component of git right into the engine: diffCompare and diffMerge.

Attempting those in script is both arduous and perilous. But with the industry standard algos now available to us easily, the rest is just comparing elements in arrays derived from object queries.

So at the moment I'm drafting the UI for this, a way to drop two different versions of a stack file into the window and review a list of property and script diffs, applying them selectively as one sees fit.

Progress has been slowed by client project needs, but work continues in the late hours as time permits.

It's not intended to replace GitHub. Not at all; where GitHub is a good fit for a team keep enjoying it.

This is a simpler, smaller-scope tool focused on review and merge. For myself, I use Nextcloud for versioned archives (with the added bonus that it keeps local copies in sync across all my machines), so I have no interest/need for handling those aspects.

I'll post more once it's ready for external testing...

[kdjanz]

Thanks KD, and hello to a fellow Canadian. This sounds a bit more involved than I was hoping for, but, also sounds like a good opportunity to get my feet wet with Git for the old version control. Currently on folder 111 for this program

ScriptTracker is very simple and does NOT require you to use GIT - in fact it is the other way around. By using ScriptTracker you can turn scripts locked inside LiveCode into text files that you can put on Git or use Diff or whatever other tools you have that work with text files. His cool extra (that I confess I have not used) is that ScriptTracker monitors those text files, so if you make changes outside with another text editor or tool, it can be set to automatically update your stack when you re-open it.

My usual use for ST is to dump all of my scripts to text, then put them all together in another text editor (BBedit for preference) and then print them so that I can get a big picture of the flow of my program. When I have scripts everywhere in different objects, I lose track of the big picture and printing them out gives me an overview of being able to see everything at once. I guess not being able to hold it all in your head at once is a symptom of age, so I have to work out my own coping strategies.

Do try! You literally have nothing to lose!

Kelly

[bwmilby]

So at the moment I'm drafting the UI for this, a way to drop two different versions of a stack file into the window and review a list of property and script diffs, applying them selectively as one sees fit.

This sounds very interesting. The goal of my tool is just to allow tracking of differences in the scripts themselves, so other object changes are not detected. I've given some thought of how to add something like that, but it would involve serializing the rest of the stack file into a text format compatible with diff. Doing that for the non-binary parts of the stack wouldn't be that difficult. Binary wouldn't be all that hard, but would just end up with large chunks of encoded data that would increase the file size. Most of the work has probably already been done with the lcVCS code, but my goal wouldn't be to go that far with it (especially the number of files/folders created). If I did add it, the data elements that would be tracked would probably be limited somewhat.

My personal reason for using ScriptTracker is so I can easily track what has changed in scripts when contributing to projects. The project uses GitHub as the repository so all of the script only stuff is tracked easily. My tool allows me to check in the new script files along with the binary stack so it is easy for a reviewer to know what scripts where changed and be able to go back if needed. The project is moving much of the code to script only stacks, but for those that have not been updated yet it is very helpful to me. For my personal projects, it allows others to suggest code changes (via a PR) that I can easily incorporate back into my binary stack using the tool.