chapel
chapel copied to clipboard
chapel-lang
Update learnChapelInYMinutes on the official site
It looks like the copy of LearnChapelInYMinutes on the official site is out of date with the version we have in the primers directory. Specifically, it still uses constructors when initializers are the norm now.
A user ran into this in our Gitter channel and tried to use constructors as a result
Edit: a PR was merged to resolve this in 2022, but the code has fallen out of date again. It'd be good to investigate if there's a way for them to auto-grab our version or auto-notify when it has become out of date
I would like to work on this issue...I am getting familiar with Chapel and using LearnChapelInYMinutes to get the basics.
Sounds good to me! I think what needs to be done is figuring out how to update the LearnXInYMinutes site (which we don't control)
The site LearnXInYMinutes is open source too, I'll open an issue in their github repo or make a pull request, updating the code.
An interesting question would be whether there's any way to have them automatically refer to / pull our current (or better, currently released) version of the file so that there wouldn't be a need to continually try to keep the two files in sync. This would have the benefit of keeping whatever's on their site consistently tested.
Because LearnXInYMinutes uses markdown while we use .chpl and .rst to build up docs, it seems hard to keep that up to date all the time. I will suggest adding a timestamp on the LearnXInYMinutes version and a link refering to our official page.
Well, the hope is that there will be less backwards compatibility breaking changes going forward
I'm thinking less about breaking changes, and more about making the lesson better over time. I think there's plenty of room to improve it, but if improving it requires jumping through a lot of hoops, it'll raise barriers to doing so (I've avoided improving it for that reason).
It looks like this got resolved when https://github.com/adambard/learnxinyminutes-docs/pull/3877 got merged in 2022
@lydia-duncan / @jabraham17 : It may have been updated since this issue was opened, but unfortunately it's still not in sync with the version in our release. :'(
I'm curious whether anyone has looked into whether the official site has a way of referring to code directly in a repo, like ours, or whether manual updates are required each time.
(Unrelated, but I don't have the heart to open a new issue over this, this week: I'd also be really interested in having someone who's really well-versed in Chapel take a pass over this to see whether it explains the language as we'd like it to be in this modern 2.0 age).
@lydia-duncan : Is the implication of your "Aww" that we should re-open this? Or we could add a new issue about updating the test again and/or creating a way to auto-update or auto-notify when an update is required?
I'd lean towards a new issue including the desire to figure out how to auto-update or auto-notify when an update is required. I think it's reasonable to consider the work tracked in this issue as completed when the initial PR was merged, even though there is still work remaining with the test.
I think it's reasonable to consider the work tracked in this issue as completed when the initial PR was merged, even though there is still work remaining with the test.
I disagree… The OP states that it's out of date and gives a specific f'r'instance of why. But it's still out of date today w.r.t. other concepts and doesn't compile if copy-pasted into ATO (say). So while the synchronization requested in the OP may have been done and the official site's version may have been working at some point in time, it isn't true today / with Chapel 2.0, so the issue doesn't feel resolved like it's resolved today / when it was closed.
Belated thought in case it wasn't clear: I think all that would be required to close this "for real" would be to merge a PR capturing the current state of the test on the site. Now that we're past 2.0, it shouldn't require many correctness changes going forward (though I am noting that it uses unstable features). Creating a rewrite of it that doesn't use unstable features would be a good additional issue to spawn off.