Modify words/all.asm to allow more local forth words

[bjchapm]

diff --git a/words/all.asm b/words/all.asm
index 07306f0..020837f 100644
--- a/words/all.asm
+++ b/words/all.asm
@@ -72,8 +72,11 @@ _load_user_vars_loop:
                 ; followed by any user-defined words from user_words.asc.
                 ; These are stored sequentially in ROM so we can evaluate them together.
                 ; If you have neither, this section can be commented out.
-                jsr push_inline_addru_literal
-                .byte user_words_end-user_words_start  ; length goes TOS
+                ; jsr push_inline_addru_literal
+                ; .byte user_words_end-user_words_start  ; length goes TOS
+;               BJC proposed change 
+                jsr push_inline_2literal
+                .word user_words_end-user_words_start  ; length goes TOS
                 .word user_words_start                 ; start address goes NOS
                 jsr w_evaluate

The original code only allows 256 bytes of user defined words if I understand correctly. Is this a reasonable change?

[trafficpest]

I did this same mod on mine

[SamCoVT]

I do think that's a reasonable change. Do you want to do a PR or do you want me to patch it?

[bjchapm]

I do think that's a reasonable change. Do you want to do a PR or do you want me to patch it?

Could you patch it? Still learning how to do PRs and I already have another pending. Thanks!

[SamCoVT]

I can patch it, but I'd also be happy to walk you through creating an additional PR if you want the practice. Using git is the best way to learn git, and I'm certainly not a pro, so practice for you is also practice for me. Tali is the project I learned git on.

Also, if you're talking about your #212 PR for tetris, it's already been merged. You can get up to date with

git checkout master-64tass
git pull

It looks like you've been working in the master-64tass branch in your own repository. That's generally not a good idea because you may want to pull changes I've committed over to your system periodically. If we both edit the same area in a file, it will not merge nicely and you'll have to fix it manually, which is not fun. The better way is to create a branch for anything you might want to submit as a Pull Request, and in reality for any work that you do even if you aren't planning a PR.

Starting in any branch, you can use

git checkout -b mynewbranch

to create mynewbranch as an exact copy of the branch you are in (the -b creates a new branch, and then it immediately checks it out - there is also a git branch command to create a new branch, but it does NOT switch over to it). Any commits will go into mynewbranch, and you can always go back to a different branch (including master-64tass) with

git checkout myotherbranch

The branch name shows up in the PR, so it's good to give it a descriptive name. For this one, I'll recommend something like:

git checkout -b more_local_forth_words

then make your changes, commit, and for the first push you will need to use

git push -u origin more_local_forth_words

This tells git to set where to push this branch to, creating the branch in the remote repo if it doesn't exist. The origin sends it to your Tali repo on github. It is possible to have the name of the branch on github be different than the name of the branch on your computer, but don't do that.

If you want to make more changes in this branch, just commit them and you can now just use

git push

because your local branch is already connected to the origin branch.

Then, when you create the PR, just make sure you issue your PR against SamCoVT/TaliForth2 and the master-64tass branch from your repo and your branch. Github tries to be helpful, so it will mention if you've pushed recently and it looks like you want to create a PR, but sometimes it gets things wrong so do double check and make sure it's my repo and the master-64tass branch set as the base for the PR, and it's the correct branch you want in your repo.

Once your PR has been accepted, you can just switch to the master-64tass branch and pull to get your master branch up to date and then you should create a new branches from there.

If you get yourself into a royal mess, you can always back up your files (copy them to a folder OUTSIDE of the project folders on your computer), then check out Tali again into a new folder, create a new branch, copy your files in, and commit/push them to your github repo. The interwebs know how to get you out of most of the messes you might get yourself into, because someone else has done it before (and was nice enough to document it, even if it's a mess). You're also welcome to open an issue here if you just want Tali-specific help working with git.

If you're really not intersted in messing more with git, just let me know and I'll go ahead and apply your patch - otherwise I'll wait for another PR from you.

[bjchapm]

Once again, thanks for the instruction and thanks for the encouragement -- I'll set up the new branch and the PR. I need to figure this stuff out better anyway, especially because I'll have a bigger PR coming to add back in support for the Planck SBC.

Happy Fourth of July!

[bjchapm]

Pull request submitted. Thanks!

[SamCoVT]

This looks good. Just so you can see how it works on the other end of a PR, here's the process I used to merge this (read only if interested)

The first thing is to note the PR number (#215 in this case), as that's how I'll get this particular PR on my computer. To get a copy of this on my computer, I use git fetch like so:

git fetch origin pull/215/head:more_local_forth_words

This fetches the head (most recent version) of your PR so I have a local copy in a branch. The number is your PR# and the name after the : is my local branch name (it often does not match the name that the PR author used).

Then I check out your branch so I can look at it.

git checkout more_local_forth_words

In this case, I've already looked at the source code on github and I'm pretty sure it's going to assemble and work, so I use:

make gitready

to use a special make target that assembles tali, runs all of the tests, and updates the manual (because the docs/WORDLIST.md file, which is generated from the source code, is used in the manual).

I see that it has passed all of the tests, so I check what additional files I will be committing using git status and see :

        modified:   docs/WORDLIST.md
        modified:   docs/manual.html
        modified:   taliforth-py65mon.bin
        modified:   tests/results.txt

That's what I am expecting, so I add the modified files and commit that to my local branch (eg. this commit won't show up in the PR or in your repo).

git add -u
git commit -m "Merging #215"

Then I change to my main branch and merge my local updated branch to bring in all of the changed files (including the generated files like docs/WORDLIST.md and taliforth-py65mon.bin)

git checkout master-64tass
git merge more_local_forth_words

Which results in:

Auto-merging docs/WORDLIST.md
warning: Cannot merge binary files: taliforth-py65mon.bin (HEAD vs. more_local_forth_words)
Auto-merging taliforth-py65mon.bin
CONFLICT (content): Merge conflict in taliforth-py65mon.bin
Auto-merging tests/results.txt
CONFLICT (content): Merge conflict in tests/results.txt
Automatic merge failed; fix conflicts and then commit the result.

and here is where I realize I made a mistake and should have just merged your simple change and then done the make gitready afterwords. Fortunately it's just the generated files that it is complaining about, so I can just regenerate them.

make gitready
git add -u
git commit -m "Completing merge of PR #215"

Everything looks good at this point, so I push to github.

git push

This is the moment where you will see on github that the PR has been merged.

[SamCoVT]

Now that the PR is merged, you can do:

git checkout master-64tass
git pull

and you will be up to date. Note that I've merged another PR around the same time, so you will have both updates in your local version now.