2018Jan02 Core Version

Cores are the underlying magic that make the Arduino API possible
Post Reply
User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

2018Jan02 Core Version

Post by mrburnette » Sat Jan 13, 2018 8:07 pm

During an earlier thread today, I was discussing the April 2017 core and the current (Jan02 2018) master with a member who was having some I2C issues with old sketches. Used to work, he says, and did not now. I was not very sympathetic saying that I was aware of some wiring changes. Well, that was an understatement.

My own local copy of the compare was from the July/August timeframe. I thought it was time to upgrade. Renaming the /Arduino/hardware/STM32 directory to STM32_, I downloaded the master. I extracted the code to /Arduino/hardware/STM32. Then I used Linux Meld to compare the two core folders.

What I saw was somewhat disturbing as Meld showed the source code side-by-side and highlighted the changes. Darn! The whole core has changed in 6 months.
/------------------------------------------Summer 2017 -------------------------------------/-------------------------------Winter 2018 -------------------------------------/
ReallyNotGood.png
ReallyNotGood.png (172.43 KiB) Viewed 267 times
Worst, when comparing individual source files, there is no specific reference to when/who requested the changes! Yes, I could go to git to figure it all out, but that is not the point - I should be able to make that determination from the source code. Valuable information is being lost, IMO. I'm not too happy about this.
/------------------------------------------Summer 2017 -------------------------------------/-------------------------------Winter 2018 -------------------------------------/
Idonotlikethis.png
Idonotlikethis.png (110.41 KiB) Viewed 267 times
Can we do better in the future?

Ray

User avatar
RogerClark
Posts: 7693
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: 2018Jan02 Core Version

Post by RogerClark » Sat Jan 13, 2018 8:26 pm

Ray,

It’s best to use git to determine why a change was made.
I find GitHub has the best UI for this. Each commit will have a comment, and it’s normally possible to track down if the commit was in response to a merge of a pull request, in which case you can see who the PR was from.

In some cases, the PRs I get sent contain changes to extraneous file that were not intended to be changed as part of the PR, so in these cases if it’s the person sending the PR can fix the PR ( e.g Steve Strong had problems with his fork which often resulted in loads of unrelated changes coming with a PR),I sometimes have to manually copy the new version of files into my local copy and then commit them as if they were my change.
However in these cases I usually add a comment to indicate who sent the files.


As you know, I have to make a call on each of the PRs, based on value to the community of the change, versus risk of the change causing problems.
I don’t always get this right, and I don’t have time to extensively test every change.

It looks like the changes to I2C may still have bugs, so one potential solution is to create a “Release” from just prior to that change. So I will investigate doing that today if I get time.

I am quite time poor at the moment as our house needed a lot of fairly major repairs, including replacing part of the and also some new stump foundations, most if this I do myself, hence these have taken priority, over processing PRs

User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: 2018Jan02 Core Version

Post by mrburnette » Sat Jan 13, 2018 8:34 pm

RogerClark wrote:
Sat Jan 13, 2018 8:26 pm
<...>
As you know, I have to make a call on each of the PRs, based on value to the community of the change, versus risk of the change causing problems.
I don’t always get this right, and I don’t have time to extensively test every change.

It looks like the changes to I2C may still have bugs, so one potential solution is to create a “Release” from just prior to that change. So I will investigate doing that today if I get time.

I am quite time poor at the moment as our house needed a lot of fairly major repairs, including replacing part of the and also some new stump foundations, most if this I do myself, hence these have taken priority, over processing PRs

First, your obligation is not primarily to this forum. Most of us old-timers git (pun) that...

Second, everyone should have a ZIP backup of the core (or the knowledge of how to use Git to regress in time) so that critical project code still works. That is the user's responsibility.

Third, I believe it is simply unwise for you to create branches in github for pre-releases ... you'll go crazy and it really is not beneficial. New users should start with the current code: everyone else has the old code on their dev platform. They can use ZIP.

But, I am still not too happy about not having the author of a change annotated in the source code tree. Authors that submit pulls should annotate... there is no excuse for not doing this, IMO.


Ray

User avatar
Rick Kimball
Posts: 1078
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: 2018Jan02 Core Version

Post by Rick Kimball » Sat Jan 13, 2018 9:41 pm

mrburnette wrote:
Sat Jan 13, 2018 8:07 pm
Worst, when comparing individual source files, there is no specific reference to when/who requested the changes! Yes, I could go to git to figure it all out, but that is not the point - I should be able to make that determination from the source code. Valuable information is being lost, IMO. I'm not too happy about this.
Can we do better in the future?

Ray
In github, you can go to a specific file and click the history button for the file. It will show who and why things changed.
Also, the history shows all the files changed for the same commit.

For the file you mentioned above here is the history:

https://github.com/rogerclarkmelbourne/ ... b_cdcacm.c

https://github.com/rogerclarkmelbourne/ ... 5e5d85dcab
-rick

User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: 2018Jan02 Core Version

Post by mrburnette » Sun Jan 14, 2018 12:03 am

Rick Kimball wrote:
Sat Jan 13, 2018 9:41 pm
<...>
In github, you can go to a specific file and click the history button for the file. It will show who and why things changed.
Also, the history shows all the files changed for the same commit.

For the file you mentioned above here is the history:

https://github.com/rogerclarkmelbourne/ ... b_cdcacm.c

https://github.com/rogerclarkmelbourne/ ... 5e5d85dcab
Rick,

Well, I knew how to revert to a specific point, but had not discovered the individual file history.

I can live with this. It just means I have to pull the entire git and replicate locally. Or, keep an browser window open to examine history.

Thanks for the educational tip :lol:

There is, IMO, value in having the metadata embedded as comments but with numerous changes, I can understand how comments can become messy. :cry:


Ray

Ollie
Posts: 205
Joined: Thu Feb 25, 2016 7:27 pm

Re: 2018Jan02 Core Version

Post by Ollie » Sun Jan 14, 2018 4:34 pm

Ray,

I do share your thought process in this.

My solution has been to abandon Arduino and STM32duino libraries for STM32 development. My confidence in CubeMX libraries is increasing. They can be very verbose and bulky, but they seem to be quite well tested and validated. For larger systems with FreeRTOS the CubeMX is very reliable. I have serious doubts about Arduino and STM32duino libraries for real-time control.

Cheers, Ollie

stevestrong
Posts: 2070
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany
Contact:

Re: 2018Jan02 Core Version

Post by stevestrong » Sun Jan 14, 2018 6:14 pm

Well, I have full confidence in this (libmple) core, and in OUR work here.

I think the community does his best to keep it running.
Roger puts a lot of effort to keep it clean, committing only changes which are tested as good as possible.
Beside this, any time someone had a problem, it was discussed, and solved when turned out the problem was in the core.
This is why github is good for, to keep different versions and to allow a continuous improvement of the software.

Me, I have a web server running 7/24 on a blue pill since a year, updated 2 months ago with the actual core, still running.
And I am planning a new update (with the fresh core version) next week.

So I really cannot follow the skepticism related to the community's work.

User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: 2018Jan02 Core Version

Post by mrburnette » Sun Jan 14, 2018 6:53 pm

stevestrong wrote:
Sun Jan 14, 2018 6:14 pm
Well, I have full confidence in this (libmple) core, and in OUR work here.
<...>
So I really cannot follow the skepticism related to the community's work.
Steve,

My entire experience with software (outside acedemia) has been in a corporate world. Continuous churning of a release version is painful. At some point, it is time to ++version and move forward. My belief is we have passed the time to move to version 2.0 ...

My only desire yesterday in poking around in the core was to attempt to understand what changed from April '17 to January '18 and I was unable to make sense just using the sources. ... but it looks to me that every source changed. Yes, github does provide all the details.

Imagine a newbie's frustration when their source code breaks and will not compile over a period of just 6 months. I betcha they are shouting praises for the community that broke their project. Yesterday, the post was not from a newbie and while he and I knew the core had changed, it was still something that broke a previously working project. .. unacceptable in my mind. If syntax changes or SPI goes from software to hardware, then the darn version should get incremented ... "master" does not cut it in my book.

We can and must do a better job.

Of course, that is just my opinion.

Ray

Post Reply