1. Eu 4.2 Help
- Posted by Icy_Viking Nov 10, 2022
- 1275 views
As Greg stated in a previous thread, help is needed to get Euphoria 4.2 out the door. I'd like to make this thread as a TO-DO list if you will. Things that we can do to help speed up the process of getting Eu 4.2 out the door. I'll try to help any way I can. I know Euphoria pretty well. I have decent knowledge of C, so hopefully there are parts or libraries that I can work on.
2. Re: Eu 4.2 Help
- Posted by ChrisB (moderator) Nov 11, 2022
- 1222 views
As per my previous post, I am happy to help, just need to know where to be pointed. If there was a project structure, with reviewers and appointers, that would be immensely helpful to me.
Cheers
Chris
3. Re: Eu 4.2 Help
- Posted by ghaberek (admin) Nov 11, 2022
- 1203 views
As Greg stated in a previous thread, help is needed to get Euphoria 4.2 out the door. I'd like to make this thread as a TO-DO list if you will. Things that we can do to help speed up the process of getting Eu 4.2 out the door. I'll try to help any way I can. I know Euphoria pretty well. I have decent knowledge of C, so hopefully there are parts or libraries that I can work on.
As per my previous post, I am happy to help, just need to know where to be pointed. If there was a project structure, with reviewers and appointers, that would be immensely helpful to me.
I have a running list on the Roadmap42 page but I'll it summarize here. This list is mostly in order of priority, which happens to correlate well with the "approachability" of each task. The further down the list you go, the more you'll need to have a good understanding of how Euphoria is put together and how to make changes to the backend, which has taken me a few years of sporadic testing and tinkering to understand. I know a lot of the documentation needs correcting less for spelling/grammar and more for verbiage, like statements that still imply we're strictly 32-bit. There are a lot of open tickets that are ten years old and assigned to folks who haven't been around in years, most of which can probably be closed. Remaining tickets should be reassigned and addressed if possible before we do a release.
- Audit documentation without bike-shedding about how we build docs
- Audit tickets and close or reassign to active users where required
- Provide feedback/discussion on new feature decisions and design
- Extending the standard library with new features
- Migrating and updating libraries from Euphoria MVC
- Build and test latest code from master branch
- Implementing additional backend features like FFI
- Wrap third-party libraries to bundle with Euphoria
- Update installers and distribution packaging
- Update Makefile to improve build system
- Revisit documentation build/hosting strategy
- Migrate website tickets (after cleanup) to GitHub issues
- Rebuild the website using more modern web development tools
-Greg
4. Re: Eu 4.2 Help
- Posted by ChrisB (moderator) Nov 11, 2022
- 1186 views
As Greg stated in a previous thread, help is needed to get Euphoria 4.2 out the door. I'd like to make this thread as a TO-DO list if you will. Things that we can do to help speed up the process of getting Eu 4.2 out the door. I'll try to help any way I can. I know Euphoria pretty well. I have decent knowledge of C, so hopefully there are parts or libraries that I can work on.
As per my previous post, I am happy to help, just need to know where to be pointed. If there was a project structure, with reviewers and appointers, that would be immensely helpful to me.
I have a running list on the Roadmap42 page but I'll it summarize here. This list is mostly in order of priority, which happens to correlate well with the "approachability" of each task. The further down the list you go, the more you'll need to have a good understanding of how Euphoria is put together and how to make changes to the backend, which has taken me a few years of sporadic testing and tinkering to understand. I know a lot of the documentation needs correcting less for spelling/grammar and more for verbiage, like statements that still imply we're strictly 32-bit. There are a lot of open tickets that are ten years old and assigned to folks who haven't been around in years, most of which can probably be closed. Remaining tickets should be reassigned and addressed if possible before we do a release.
- Audit documentation without bike-shedding about how we build docs
- Audit tickets and close or reassign to active users where required
- Provide feedback/discussion on new feature decisions and design
- Rebuild the website using more modern web development tools
-Greg
What's bike-shedding?
Do I have permission to audit/close/reassign tickets?
How can I edit the docs / manual?
Chris
5. Re: Eu 4.2 Help
- Posted by ghaberek (admin) Nov 11, 2022
- 1202 views
What's bike-shedding?
It's what happened a while ago when I asked for help with the documentation, where instead of actually trying to accomplish the task at hand, we got buried in conversation about what was the "correct" approach to the documentation in general. See Law of triviality.
Do I have permission to audit/close/reassign tickets?
I believe so, yes. I recently created a new Milestone for 4.2.0 so we should set any still-relevant tickets to that. Anything else should be closed and tickets assigned to inactive users should be unassigned. Then we can report back on what's left and re-assign accordingly.
How can I edit the docs / manual?
I think that's what lead to the bike-shedding in the first place. The docs for the standard library are in the comments of each respective include file (e.g. std/cmdline.e) and the rest of the manual is in text files in the docs directory.
So even though it might not require writing code, updating the docs does follows a typical development process. The process is basically: run make htmldoc, read through the docs, edit the source files, and repeat the process. Then commit and push.
I agree it's not great, and it makes for a taller barrier to entry than it should. But anyone who wants to work on improving documentation process is going to face even more challenges trying to get there, so this really is the lesser of two evils.
If you're new to Git, you'll need to learn the basics of that first. If you're not on GitHub you'll need to create an account. Then I can add you to our developers group on GitHub so you can push your changes to the repo.
I created a Euphoria Discord last year which we don't really use much, but it may be better for real-time collaboration especially for troubleshooting and nit-picking things until you're up and running. Just "at" me on there to get my attention.
-Greg
6. Re: Eu 4.2 Help
- Posted by ChrisB (moderator) Nov 22, 2022
- 1085 views
Hi Gregg
What is the github euphoria address, so I can do a pull, and look through the documentation?
Cheers
Chris
edit, it's ok, found it!
7. Re: Eu 4.2 Help
- Posted by ChrisB (moderator) Nov 22, 2022
- 1080 views
So even though it might not require writing code, updating the docs does follows a typical development process. The process is basically: run make htmldoc, read through the docs, edit the source files, and repeat the process. Then commit and push.
Hi Gregg, handholding required. ^ what?
Basically I've got a handful of source and external doc files, and embedded docs, and I want to make a big HTML file. What do I need to run?
Chris
8. Re: Eu 4.2 Help
- Posted by ghaberek (admin) Nov 22, 2022
- 1051 views
Basically I've got a handful of source and external doc files, and embedded docs, and I want to make a big HTML file. What do I need to run?
This should work if you are using a Linux machine, VM, or WSL. You also need install Euphoria 4.1. I have directions on the downloads page.
sudo apt install build-essential git git clone https://github.com/OpenEuphoria/euphoria cd euphoria/source ./configure make htmldoc
Then open build/html/index.html in your browser. If you are using WSL then you can open its root folder in Windows Explorer using the path \\wsl$\Ubuntu (or whatever your WSL instance is named) then you can browse to the directory and open index.html from there.
-Greg