Deprecating Library functions in Blockly & Simple Libraries

twm47099

I hate to complain about either the Simple IDE version of C or BlocklyProp since I have found them both to be very useful.

But, a couple of times now, I've tried to demo BlocklyProp to some friends and was not able to run a program had written due to blocks I had used being deleted from BlocklyProp (embarrassing when the goal is to show how easy it is to use).

Likewise when I have tried sharing programs I had written using Simple Library 0945 with someone new to the Propeller and using the latest version Library, they just get errors due to the newer library no longer containing certain functions.

The latest occurrence was with the deprecating the drive_ramp functions. The new library uses an acceleration function which may be a better name for the function, but why is it necessary to remove the previous function? Couldn't a note just be added to the documentation that states the acceleration functions are preferred while retaining the older function for older programs that use it? Since the Libraries are built from individual function files if used in the specific user program, it would seem reasonable to just add the new function and any of its dependencies using new names for any changed files while keeping the old.

In my robots I've used drive_ramp a lot to minimize "jerk" which can unseat the Ping or other heavy items from the breadboard. But in the same program I will use drive_speed (0,0) for emergency stops. While the new acceleration function is automatically applied to drive_speed, it would require changing the acceleration value for normal speed changes and for e-stops where I don't want a slower response.

Unfortunately, I have to either make a lot of changes to my C programs or either figure out how to use multiple versions of the Libraries or just be incompatible with new users. With BlocklyProp I don't even have a choice since the library in use is always updated so all the deprecated blocks have to be replaced with new - which could also require modifying the program logic. Please don't get me wrong, updates are important, but please try to keep things backwards compatible.

Thanks
Tom

Whit

@twm47099,

Thanks for this post. Let me do a little investigating and get back to you when I know more.

Steph Lindsay

Hi Tom, thanks Whit,

I hear your frustration! I know that the crew tries to minimize function and block deprecation as much as they can. I can't speak to the specifics on the instances you noted, but I gave the developers a heads-up (they are traveling for Educator Courses at the moment). I do know we are working through a set of necessary improvements towards long-term stability. So, hopefully after the next few iterations any such breaking changes would be rare.

As you mentioned, there's a choice with the Simple Libraries but not so much with BlocklyProp. That's where the Cloud-based benefit of always having the latest and greatest versions of everything can introduce a gotcha from time to time. As we are nearing the end of our Beta phase with BlocklyProp, one of my goals is to improve our communication with you the users about changes in the works. There are two new pieces to that.

First, the About BlocklyProp Updates page on the Learn site lists approved changes planned for the next release, as well as candidate changes for future releases.

Second, an occasional message banner on the BlocklyProp UI will alert users to upcoming changes and links back to this page for explanations. This will include planned block deprecations and the reasons behind them.

I hope this will help reduce those unwelcome surprises, and put the improvements in context!

-Steph Lindsay
Product & Docs
Parallax Inc.

MattMatz

Good evening,

Would you mind emailing me a link to the broken program?
I'm at mmatz@parallax.com
We've tried really hard to avoid any hard depreciations like this, and what you suggest is what we try to make the system support. I'm guessing that I missed something when I wrote this block to call the accel function instead of the ramp function, but I might be able to fix it if I can get a better understanding of what happened.

Thanks,
Matt

Whit

Thanks, Stephanie and Matt! You all are the best...

One of the things I love about BlocklyProp is that because it is web-based. It is constantly updated, and can constantly be repaired if something is amiss.

Tom, lets us know how it's going!

twm47099

Matt,
I had already changed the robot one, but this is the fixed one.
blockly.parallax.com/blockly/editor/blocklyc.jsp?project=3931

This is an intermediate version that required a simple change:
blockly.parallax.com/blockly/editor/blocklyc.jsp?project=3943

I also have an Blockly program that demos the EMIC2. I'm not sure if the future change re serial noted on the link Steph posted will cause issues with the way I have used the existing serial blocks. This is the link to that program:
blockly.parallax.com/blockly/editor/blocklyc.jsp?project=3982

This link is to the SimpleIDE C version of my Activity Bot program that uses the ramp function (it was the basis for the Blockly program) and is typical of my use of drive_ramp in a number of other ActivityBot programs that I've written. Most of my programs are written in SimpleIDE.
forums.parallax.com/discussion/comment/1399840/#Comment_1399840

Thanks
Tom

twm47099

When I just looked at my fixed code:
blockly.parallax.com/blockly/editor/blocklyc.jsp?project=3931
I saw that I set the acceleration to 4 where the default is 600. I don't currently have my Bot wired up for that program, but I know 4 worked when I had originally fixed my program by using that block. Since the dropdown for the acceleration block says that 100 is sluggish, I don't think it will work well.

Tom

MattMatz

Okay - I see what happened. Yes, we changed the menu options in the block and had it call acceleration instead or ramping. If I recall, Andy set the new acceleration function to work identically to the ramping function, other than take a different scale of values, so I'm hoping that there isn't any other change in behavior.

If you look at that acceleration function here: https://github.com/parallaxinc/Simple-Libraries/blob/master/Learn/Simple Libraries/Robotics/ActivityBot/libabdrive/setAcceleration.c
It's calling the ramping function - the values are divided by 50 - so a ramp step of 4 ticks means the acceleration should be set to 200 t/s/s

We have on a couple of occasions made changes to menu options like what you experienced, and until the next release, we don't really have a good way to communicate that to customers. The good news is that I don't foresee us making changes like that very much more in the future, and I'll do my best to prevent those changes from being breaking changes.

I've tried to set up the system to automatically adjust blocks so that programs still work, but there have been a few occasions where that wasn't possible, and this was one of them...

I'm sorry that this happened, and thank you for bringing it to our attention.

There are some changes coming to the serial blocks, but knowing what you've done with the emic, I'll actually test the draft changes against your code to try and keep things from going south.

Thank you!
Matt

ASKME

I would like to add that BlocklyProp is still being improved upon.

Ken Gracey

ASKME wrote: »

I would like to add that BlocklyProp is still being improved upon.

Yep, and it will be for many years. The nature of these cloud systems makes improvements quite easy to deploy. We just copy files to the AWS servers and presto! - you're using them! The drawbacks of this you have seen, too, like when we break your code. This shouldn't be happening anymore because we've learned quite a bit since we started this project three years ago.

Ken Gracey