2.1.0 Release #114
2.1.0 Release #114
Conversation
Added an initialization flag to the scene state to denote when a scene is first loading. SCENE operator aborts if the flag is present.
Buffered input Clear-on-new-entry Apply-on-Enter Abort-on-navigation Incrementers wrap around 16-bit limits Number entry blocks if it would exceed limits
Now tracking script number in the execution state and script last run times in the script state. One line tap tempo (hit F1 twice): 1: M LAST M: TR.P 1
AVG -32767 -32768 == -32767 AVG 32767 32766 == 32767
Maximum depth set by WHILE_DEPTH (default 10000)
SCRIPT was breaking W. Now it doesn't.
If conditions and for loop iterators do not transcend their execution depth. Live mode now behaves like this: > L 1 4: A I > A => 4 > I => 0 I is 0 because it exists in a different context than the first command.
As a result, the code is cleaner and easier to read. Short story: only SCRIPT should call es_push and es_pop
Conflicts: docs/ops/controlflow.toml src/state.c src/state.h src/teletype.c
|
Yes, I'm done making changes to this branch. If bugs get discovered past this point, that's what the third digit in the release number is for! ;) Merge away! |
|
@tehn did this get "squash merged"? |
|
yes, but then i had to do a couple master push for doc updates.
…On Fri, Oct 13, 2017 at 4:32 AM Sam Doshi ***@***.***> wrote:
@tehn <https://github.com/tehn> did this get "squash merged"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#114 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAPEcNDYajwiHDl4X9DdidHnrGl0LnsMks5sryAHgaJpZM4P1-ae>
.
|
|
Did you mean to "squash" it? (i.e. turn the >100 commits into a single one) Be careful, GitHub changed the merge box on PRs to give 3 options. |
|
indeed, that was the default (which i did notice was different).
now that you're bringing this up, of course it makes sense that i should've
left all of the commits atomic for traceability, right?
…On Fri, Oct 13, 2017 at 11:11 AM, Sam Doshi ***@***.***> wrote:
Did you mean to "squash" it? (i.e. turn the >100 commits into a single one)
Be careful, GitHub changed the merge box on PRs to give 3 options.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#114 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAPEcFh0cmh_mgO3SGmUdbX8dsWYCBjqks5sr32GgaJpZM4P1-ae>
.
|
|
Usually yes. Sometimes you want to use the other options. Also, it's messed up the contributors graph a bit, so @burnsauce doesn't get quite as much recognition on it as he deserves. (Though we all know how much work he has put into it!) |
|
I must say that I was looking forward to seeing my 200+ commits appear on the graph. It's hard for me to put forward technical arguments as to why it shouldn't have been squashed because they would be disingenuous in light of that. Just posting this here to voice my opinion before too many more commits stack up and it might be harder to redo the PR. |
|
i think recognizing everybody's contributions is super important. but feels like commit history should be more driven by what makes it more useful/efficient for us. i had commits that were some silly typo or such, i wouldn't want them creating noise on the master branch. but yeah i'm not sure how to balance it with trackability... is there a way to cherry pick what to squash? interesting question this... |
|
So firstly, if this had happened to me, I would feel pretty hacked off. By all metrics @burnsauce should be the 2nd highest contributor to the repo behind me. That commit history will also be really helpful with The only way to solve this now is to do some history rewriting and then force pushing. I'm pretty sure that I can do that, by branching of So basically, we're stuck between a rock and a hard place. Whatever we do, I think we should decide quickly. |
|
Right one more option, the following branch: https://github.com/samdoshi/teletype/tree/burnsauce-master Has all of @burnsauce commits merged back in, because they're merged in there is no need to force push. But it does make the commit history look really really wonky. Here is the diff: master...samdoshi:burnsauce-master You can see all the commits, but also see that it doesn't change anything. Here is the blame: https://github.com/samdoshi/teletype/blame/burnsauce-master/src/turtle.c You can see that all the original commits are showing up. |
|
@samdoshi Thank you for following up on this! I really appreciate the work and attention that you put into this, especially considering your limited time. Also I apologise for claiming it's 200+ commits, as it's only 100+. I think I might be developing dyslexia of some sort. Numeric transposition has been happening to me with alarming regularity. |
|
augh, i am terribly sorry for this. there was no technical reason, other
than my over-multi-tasking caused me to do the default merge (which seems
to have changed in the github UI?).
i am up for any solution that can fix this and bestow the proper merit on
@burnsauce, to whom i'm super grateful. again i apologize for the mess.
…On Sun, Oct 15, 2017 at 7:06 AM, Poindexter Frink ***@***.***> wrote:
@samdoshi <https://github.com/samdoshi> Thank you for following up on
this!
I really appreciate the work and attention that you put into this,
especially considering your limited time.
Also I apologise for claiming it's 200+ commits, as it's only 100+. I
think I might be developing dyslexia of some sort. Numeric transposition
has been happening to me with alarming regularity.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#114 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAPEcEyS0un7S-KDHSc7kTFBemh50HMrks5ssecogaJpZM4P1-ae>
.
|
|
@tehn yeah GitHub changed the UI, the default option seems to change, so you really need to focus on it. It's good that they offer the options now, but it is confusing. Shall I open up a PR to merge the commits back in then? I think it works, but it's a bit at the edge of my |
|
please do, if you have the time to attempt to rectify this. thank you!
…On Sun, Oct 15, 2017 at 8:46 AM, Sam Doshi ***@***.***> wrote:
@tehn <https://github.com/tehn> yeah GitHub changed the UI, the default
option seems to change, so you really need to focus on it. It's good that
they offer the options now, but it is confusing.
Shall I open up a PR to merge the commits back in then? I think it works,
but it's a bit at the edge of my git knowledge. @cmcavoy
<https://github.com/cmcavoy> / @jlmitch5 <https://github.com/jlmitch5>
either of you have any insight?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#114 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAPEcDa06E-rHBdizddUINZYIvCIpNRXks5ssf6rgaJpZM4P1-ae>
.
|
|
Thank you both for taking the time! Sorry to @scanner-darkly for any additional work this will bestow upon your grid fork :( |
|
Agreed the expanded commit history is very useful (especially for someone, like myself, using this repo as a way to learn more about C/C++ embedded dev). I don't really understand what you did with that PR @samdoshi, but it looks to be working great! I would say this way is especially good because it might be weird to rewrite history with force pushes since the master branch has releases off of it. I don't know what would happen to them. That brings up a point...I guess this would be merged into master, so it wouldn't be present in the 2.1.0 release tag, but would be for all subsequent releases off of master. I assume that's fine just wanted to bring it up. |
|
Somewhat painful news: the prune job I did removing the .zip files and .hex files that I once added to the repo did not take. I only found this out by checking burnsauce-master@samdoshi/teletype with BFG which means that I did push those things onto the branch. Seems that history will need to be rewritten at least for 2.1.0. Sorry that my git-newbieness has dirtied the repo. For reference, I used https://rtyley.github.io/bfg-repo-cleaner/ with and it found stuff that I thought I had already deleted with :( |
|
@burnsauce get a cleaned up branch sorted for me, then I can take it from there. Because @tehn squash merged it, none of the zip files are in the current |
|
My master has been cleaned of these references. Edit: I have gained a lot of experience over the past month, but I still have much to learn. Thank you for your patience. |
|
Can you check for PDF files too? |
|
No PDF files found! :) |
|
for my grid2 branch i could probably just rebase off whatever the master ends up with? this shouldn't be a problem if i understand correctly, it should be able to replay my changes with no conflicts. and i think we should have a discussion on commit etiquette - blame and tracking is very useful, but maybe that means putting more care into what goes into a commit - when i start development i might have a bunch of commits that is work in progress/just me forgetting to do things/silly typos, i don't think those would be useful for blame and would just create more noise for others. thoughts? |
|
If there were an easy way to selectively roll up a sequential series of commits into one after the fact, that would allow one to hide typo and other premature commit fixes while retaining the richness of the commit metadata. Is that something git can do? |
|
Yes, you need to Google "git interactive rebase". Read through a couple of the links to get an idea of how it works. One thing to remember with (I've had a busy day, so I'm not going to be able to doing any more on this today. So if you want to use the time to rewrite history a bit, go for it.) |
|
Interactive rebase/squashing is a good option. A couple other notes (sorry if this is all super obvious):
This is very good advice, and really, any time you are about to do |
|
I gave rewriting the history for my changes a shot, but the squashes are less automatic than I expected, leading me to have to manually fix merges. As this could lead to bugs, I'm not going to engage in this activity at this point in time. Knowing how to squash will lead me to cleaner commit logs in the future. I have no interest in creating noise, and would consider a feature/bugfix PLUS its documentation 1 commit. @samdoshi, you can consider my master branch as ready to go whenever you want to commit surgery. Thank you all for the guidance. |
Re-add commits lost due to squashing of PR #114
What does this PR do?
Updates master branch to 2.1.0
Provide links to any related discussion on lines.
https://llllllll.co/t/teletype-2-1-firmware-beta-rc2-every-et-al/9192
How should this be manually tested?
Use the new features.
Any background context you want to provide?
All design choices and features have been approved by @tehn
If the related Github issues aren't referenced in your commits, please link to them here.
EVERY implementation fixes #111
I think the rest have been referenced by number.
I have,